| Age | Commit message (Collapse) | Author |
|---|
|
I want to add new node types to the parser translator, for example `itblock`. The bulk of the work is already done by prism itself. In the `parser`
builder, this would be a 5-line change at most but we don't control that here.
Instead, we can add our own builder and either overwrite the few methods we need,
or just inline the complete builder. I'm not sure yet which would be better.
`rubocop-ast` uses its own builder for `parser`. For this to correctly work, it must explicitly choose to extend the
prism builder and use it, same as it currently chooses to use a different parser when prism is used.
I'd like to enforce that the builder for prism extends its custom one since it will lead to
some pretty weird issues otherwise. But first, I'd like to change `rubocop-ast` to make use of this.
https://github.com/ruby/prism/commit/b080e608a8
|
|
Follow-up to https://github.com/Shopify/ruby-lsp/pull/1849.
This is an extension of `Prism::Translation::Parser` to implement https://github.com/Shopify/ruby-lsp/pull/1849.
It is based on the comments in https://github.com/Shopify/ruby-lsp/pull/1849#pullrequestreview-1966020868,
but also adds a default argument for delegation to `Parser::Base` super class.
Using this API, https://github.com/rubocop/rubocop-ast/pull/359 has been implemented in RuboCop AST.
As detailed in https://github.com/rubocop/rubocop-ast/pull/359, this change is expected to improve performance by 1.3x
for some source code.
Achieving a 1.3x speedup with such this simple modification is a significant improvement for Ruby LSP and its users.
https://github.com/ruby/prism/commit/925725291c
|
|
This message is printed when running `bundle lock --add-platform`. This
command affects the lockfile, not the gemfile, and I think it's better
to use "You are adding" rather than "You added", because the addition is
happening during the current invocation (as opposed to other log
messages that talk about a change made to the Gemfile prior to running
the command).
https://github.com/rubygems/rubygems/commit/aba1e55f5b
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
And make it consistent with platform additions.
https://github.com/rubygems/rubygems/commit/64342ae404
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
not in lockfile
Current it says "you added a new platform to your gemfile", but that's
not actually the case here.
https://github.com/rubygems/rubygems/commit/1e39527a38
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
aren't writable:
- ### Problem
Running `bundle doctor` warn about files that aren't writable.
This makes the output of `bundle doctor` very verbose for something
I believe isn't really an issue.
### Context
Rubygems keeps the files original permission at the time the gem
is packaged.
Many gem maintainers have decided that the permissions of the files
in their bundled would be 0444, this includes amongst others:
minitest, selenium, brakeman...
Any git gems that had a 0444 permissions at some point in its git
history would also be reported (as bundle doctor look in the
`cache/bundler/git/<gem>/object` path).
While it completely make sense to report when files aren't readable,
maybe it's worth questioning the usefulness of reporting files
that can't be written and what problem this causes to the user
(if any).
### Solution
Removed the check for unwritable file.
### Side note
I also tweaked the "No issues ..." message logic as it was doing
the opposite (reporting an issue when there is none and vice versa).
This wasn't caught in tests because as a stub on `Bundler.ui.info`
was missing.
https://github.com/rubygems/rubygems/commit/9a426b9495
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
(https://github.com/ruby/pp/pull/38)
https://github.com/ruby/pp/commit/5b5d483ac2
|
|
https://github.com/ruby/cgi/commit/defbdf9a30
|
|
protected folders
As long as there's nothing new to install and gems are already there.
If not, give a meaningful error about what happened.
This was how things already worked until
https://github.com/rubygems/rubygems/commit/345ec45f5a87, so this commit partially
reverts that change.
https://github.com/rubygems/rubygems/commit/794b0ecb39
|
|
https://github.com/rubygems/rubygems/commit/677e17aa2e
|
|
being created
https://github.com/rubygems/rubygems/commit/f2f2ac9680
|
|
feature now
https://github.com/rubygems/rubygems/commit/b29f8d6a37
|
|
When working with our repository on JRuby locally, I get the following
changes when running `bin/rake setup` in all of our lockfiles
```diff
diff --git a/tool/bundler/dev_gems.rb.lock b/tool/bundler/dev_gems.rb.lock
index https://github.com/rubygems/rubygems/commit/362bf25690d..https://github.com/rubygems/rubygems/commit/74550b2a408 100644
--- a/tool/bundler/dev_gems.rb.lock
+++ b/tool/bundler/dev_gems.rb.lock
@@ -66,6 +66,7 @@ PLATFORMS
java
ruby
universal-java
+ universal-java-22
x64-mingw-ucrt
x86-linux
x86_64-darwin
```
This is inconvenient, so I applied the same strategy we already use on
non JRuby implementations to not add the current platform to the
lockfile if a less specific platform is already there.
https://github.com/rubygems/rubygems/commit/812b9cd1e8
|
|
Unfortunately this requires reverting a previous enhancement of
reinstalling gems if they incorrectly ship with an empty installation
dir.
However, there's no way to distinguish this kind of bad state from a gem
that's empty for real, for example, sorbet-static-and-runtime.
This reverts commit https://github.com/rubygems/rubygems/commit/9720a9b980d2, and adds a
spec to make sure empty gems are not reinstalled every time.
https://github.com/rubygems/rubygems/commit/7c102394af
|
|
There's no reason to call `converge_specs` when adding additional
lower bound requirements to prevent downgrades, and it actually causes
the extra requirements to be missed sometimes.
Loop over the originally locked specs directly, adding the additional
precaution of not adding the requirement if the Gemfile dependency has
changed and it no longer matches the locked spec.
https://github.com/rubygems/rubygems/commit/5154506912
|
|
These don't really hurt, so I'm not sure why I introduced it.
https://github.com/rubygems/rubygems/commit/85b6b405ac
|
|
are incorrect
Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
https://github.com/rubygems/rubygems/commit/b8e55087f0
|
|
https://github.com/rubygems/rubygems/commit/d8c4754d8f
|
|
https://github.com/rubygems/rubygems/commit/516430c3ec
|
|
Bundler does not really have a concept of "development dependencies",
like RubyGems has. Bundler has the more generic concept of "groups".
Under the hood, the `gemspec` DSL will put gemspec development
dependencies under a `:development` Gemfile group, but there's no reason
to instantiate these as development dependencies, they are regular
runtime dependencies, except that they belong in a group named
:development.
By never instantiating development dependencies at all, we avoid having
to introduce hacks to "undo" the type Bundler does not know about, and I
also think the error messages read better.
https://github.com/rubygems/rubygems/commit/9a06fa5bda
|
|
We have a flaky failure where to equal Bundler specs sneak into the same
SpecSet. This seems like a vector where that could happen so trying this
in case it fixes the flaky.
https://github.com/rubygems/rubygems/commit/a33aeb3c4d
|
|
https://github.com/rubygems/rubygems/commit/55af558124
|
|
https://github.com/rubygems/rubygems/commit/33d91de732
|
|
https://github.com/rubygems/rubygems/commit/a3f365bbaa
|
|
And avoid installing any gems.
https://github.com/rubygems/rubygems/commit/c12700c7e4
|
|
Bundler DSL, in favor of using `platform :windows`
This commit is only deprecation and does not change/remove any actual functionality.
https://github.com/rubygems/rubygems/commit/0ca6dc3984
|
|
https://github.com/rubygems/rubygems/commit/de8b3016db
|
|
Fixes [Bug #21117]
https://github.com/ruby/prism/commit/19d4bab5a0
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12740
|
|
gems are available locally
Filtering out remote specs should only apply where there are locally
installed specs. Otherwise they should always be considered.
https://github.com/rubygems/rubygems/commit/118f8389a1
|
|
When Bundler refuses to install in frozen mode, sometimes it would
incorrectly claim that some dependencies have been added to the Gemfile
when that's not really the case. Fix that by making sure
`locked_dependencies` always has all locked dependencies, even when
unlocking,
Additionally, the suggestion to run `bundle install` is also confusing
when unlocking, since `bundle update` is what has been run. So skip that
part as well when unlocking.
https://github.com/rubygems/rubygems/commit/64d84ad7d8
|
|
options
https://github.com/rubygems/rubygems/commit/5b6077a1e8
|
|
Platforms specific gems not compatible with the current Ruby should not
make `bundle cache` fail and should not get removed from the cache since
they still may be useful in other rubies.
https://github.com/rubygems/rubygems/commit/717b43f565
|
|
And make the current `materialize_strictly` private.
https://github.com/rubygems/rubygems/commit/3fc2129147
|
|
We materializing for installation, we already do this, and we
materializing for cache, it does not seem necessary.
https://github.com/rubygems/rubygems/commit/1a983c6cbc
|
|
https://github.com/rubygems/rubygems/commit/32982fcd33
|
|
And rename it to something better.
https://github.com/rubygems/rubygems/commit/321174d1ad
|
|
https://github.com/rubygems/rubygems/commit/c65b8644e6
Co-authored-by: Samuel Giddins <[email protected]>
|
|
I think we need this to silence the following warning when running
`bin/console` with Ruby 3.4
```
./bin/console:10: warning: irb was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add irb to your Gemfile or gemspec to silence this warning.
```
https://github.com/rubygems/rubygems/commit/c46230c856
|
|
https://github.com/rubygems/rubygems/commit/9720a9b980
|
|
The previous wording was too specific, there may be situations when the
gem has actually never installed (so never deleted either).
https://github.com/rubygems/rubygems/commit/e4a0d71fbe
|
|
dependencies
For installed specifications, we can ignore any constraints they may
have, since we know they match the current version of Ruby or otherwise
would not be installed.
For remote specifications, we already resolve optimistically without
metadata and retry force-fetching it if necessary.
If in the future we support resolving against a Ruby version different
that the one being run, we'll probably need to change this but now it's
unnecessary and saves some memory.
### Before
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
### After
Total allocated: 259.89 MB (3134199 objects)
Total retained: 115.05 MB (1283779 objects)
https://github.com/rubygems/rubygems/commit/201c1863fc
|
|
specification classes
https://github.com/rubygems/rubygems/commit/7f921aa46e
|
|
They use less memory that way.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
### After
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
https://github.com/rubygems/rubygems/commit/a4ef9c5f56
|
|
Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 277.48 MB (3384318 objects)
Total retained: 117.53 MB (1338657 objects)
### After
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
https://github.com/rubygems/rubygems/commit/c6dc2966c5
|
|
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
### After
Total allocated: 277.44 MB (3383182 objects)
Total retained: 117.55 MB (1338622 objects)
https://github.com/rubygems/rubygems/commit/2d3d6e5015
|
|
Since not every dependency gets referenced.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 295.01 MB (3624335 objects)
Total retained: 119.31 MB (1364474 objects)
### After
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
https://github.com/rubygems/rubygems/commit/61eee39d81
Co-authored-by: Samuel Giddins <[email protected]>
|
|
Currently evenn if the require actually fails, they suggest that the
file was actually loaded, which is confusing. I reworded them to reduce
this confusion.
|
|
The name "gem" could be confused with RubyGems activation method.
|
|
Most of the stuff is not actually necessary.
|
