| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This reverts commit 87253d047ce35e7836b6f97edbb4f819879a3b25.
Revert "Implement `Process.warmup`"
This reverts commit ba6ccd871442f55080bffd53e33678c0726787d2.
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Feature #18885]
For now, the optimizations performed are:
- Run a major GC
- Compact the heap
- Promote all surviving objects to oldgen
Other optimizations may follow.
|
|
|
|
|
|
| |
to Bundler.
https://github.com/rubygems/rubygems/commit/d768be0c65
|
|
|
|
|
|
| |
Plugins don't use a lockfile, so ignore frozen related settings.
https://github.com/rubygems/rubygems/commit/f17a3bb81f
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dependencies have changed, we'll be re-resolving, and we can't
really know whether the resolution will be valid or invalid for the Ruby
platform, so skip the removal in that case.
The fix worked, but made some other specs fail, and surfaced that the
`@dependencies_changed` attribute was actually being incorrect set when
explicitly unlocking. Fixed that with an early return.
https://github.com/rubygems/rubygems/commit/20d8f5e5d9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unlocking
Bundler is very conservative by default, trying to preserve versions
from the lockfile as possible, and never downgrading them. However, when
it runs into a resolution error, it still tries to find a valid
resolution.
This fallback behavior was too "brute-force" though, completely
unrestricting any gem found in the resolution conflict, and that could
lead to direct dependencies being downgraded in some edge cases.
Instead, unlock things a bit more carefully:
* First try unlocking fully pinned indirect dependencies, but leave a
lower bound requirement in place to prevent downgrades.
* Then try unlocking any fully pinned dependency, also leaving a lower
bound requirement in place.
* Finally completely unrestrict dependencies if nothing else worked.
https://github.com/rubygems/rubygems/commit/7f55ed8302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add tests for pre, move more of the setup into a helper method, and
restructure tests.
There seem to be five considerations for these tests (level, pre, strict,
locked, and whether the current version is a prerelease version, though
the last one overlaps with pre and didn't seem to behave how I expected
under test). Rather than write out the 16 (/32 if the last consideration
is real) combinations, I wrote most with independent tests for each
value. The existing combined tests were maintained (level vs strict)
because these seem the most interrelated.
https://github.com/rubygems/rubygems/commit/74c23a91b2
|
|
|
|
| |
Fixes [Bug #19380]
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is useful for passing directory file descriptors over UNIX
sockets or to child processes to avoid TOCTOU vulnerabilities.
The implementation follows the Dir.chdir code.
This will raise NotImplementedError on platforms not supporting
both fchdir and dirfd.
Implements [Feature #19347]
|
|
|
|
|
|
|
|
|
| |
The documentation states it returns a copy of self with nil value
entries removed. However, the previous behavior was creating a
plain new hash with non-nil values copied into it. This change
aligns the behavior with the documentation.
Fixes [Bug #19113]
|
|
|
|
|
|
|
| |
This was already copied for non-empty hashes. As Hash.ruby2_keywords_hash
copies default values, it should also copy the compare_by_identity flag.
Partially Fixes [Bug #19113]
|
|
|
|
|
|
|
|
| |
It wasn't copied for empty hashes, and Hash.[] doesn't copy the
default value, so copying the compare_by_identity flag does not
make sense.
Partially Fixes [Bug #19113]
|
|
|
|
|
|
|
| |
I've never seen this error in real life, and if it was happening, I
think it's either some server side issue that would need to be fixed or
some transient issue. We should move away from the full index, since
it's slow, so let's stop recommending it.
|
|
|
|
|
|
| |
The debug message suggests retrying using `--full-index`, but the retry
is happening automatically. Just log that we are falling back to the
full index, like we do with other errors.
|
| |
|
| |
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/085d2776d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unrelated git sources directly
Since Bundler 2.4, we will try to checkout any branch specified in the
Gemfile, while until Bundler 2.3 we would directly checkout the locked
revision.
This should not make any difference in most situations, but in some edge
cases, like if the branch specified in the `Gemfile` has been renamed,
but the locked revision still exist, it causes an error now while before
it would update the lockfile without issues.
I debated which behavior was best, since I was not sure. But my
conclusion is that if the situation does not require expiring the
lockfile source in favor of the Gemfile source, we should use the locked
revision directly and proceed happily. So I restored Bundler 2.3
behavior.
I think this is consistent with how yanked gems are handled, for example.
Of course, if explicitly updating the git source itself, or all gems, we
will still get any errors like missing branches related to the git source.
|
|
|
|
|
|
|
|
| |
This was working fine for direct dependencies using
`force_ruby_platform` explicitly through Gemfile, but not for indirect
dependencies. In general, indirect dependencies do not have this
property set, but in truffleruby this is different and the default value
is to have it set.
|
|
|
|
|
|
|
|
|
| |
This should be a very rare edge case, however, it does happen when using
a .dev version of Bundler because in that case, that's the only version
that the resolver considers, and it should not be ignored.
We could've special cased this specifically for Bundler, but I think it
does make sense for every gem.
|
|
|
|
|
| |
Just like gem sources, a "style-only" change, like adding a trailing
slash, should not expire them.
|
|
|
|
|
|
| |
locked
https://github.com/rubygems/rubygems/commit/24d2bf9cb2
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/86b574824d
|
|
|
|
|
|
| |
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/27ed6870ce
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/3841a58095
|
|
|
|
|
|
| |
Nicer :)
https://github.com/rubygems/rubygems/commit/c0ab2893c3
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/3139587be9
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/69aa007679
|
|
|
|
|
|
|
| |
[Bug #19530]
If the initial value isn't one of the special cased types, we directly
jump to the slow path.
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/125f9fece9
|
| |
|
| |
|
|
|
|
|
| |
The compliation-mode of Emacs sets TERM to "dumb" and does not support
coloring.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the --no-install option to `bundle package` is totally
ignored for git sources. This can have very strange effects if you have:
- a git-sourced gem,
- with native extensions,
- whose extconf.rb script depends on another gem,
- which is installed from Rubygems in the gemfile.
In that circumstance, `bundle package --no-install --all` will download
the Rubygems dependencies to `vendor/cache` but NOT install them. It
will also check out the git gems to `vendor/cache` (good), and attempt
to build their native extensions (bad!).
The native extension build will fail because the extconf.rb script crashes,
since the dependency it needs is missing.
I implemented a fix for this in `source/git.rb`, since this is analogous
to what's happening in `source/rubygems.rb`. I do admit though the whole
thing is a little strange though - an "install" method that.... proceeds
to look at a global flag to not install anything.
Add test to confirm cache respects the --no-install flag
https://github.com/rubygems/rubygems/commit/5a77d1c397
Co-authored-by: KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
missing gems
If the original `BUNDLE_GEMFILE` is different from the default, then the
suggestion wouldn't work as is.
Before:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install` to install missing gems.
$ rubygems git:(better-cmd-suggestion) ✗ bundle install
Could not locate Gemfile
```
After:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb` to install missing gems.
$ bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb
Fetching gem metadata from https://rubygems.org/.........
Using ast 2.4.2
Using bundler 2.4.7
Using parser 3.1.2.0
Using rainbow 3.1.1
Using parallel 1.22.1
Using regexp_parser 2.5.0
Using rubocop-ast 1.18.0
Using rexml 3.2.5
Using ruby-progressbar 1.11.0
Using unicode-display_width 2.1.0
Fetching rubocop 1.30.1
Installing rubocop 1.30.1
Using rubocop-performance 1.14.2
Bundle complete! 2 Gemfile dependencies, 12 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ util/rubocop
Inspecting 345 files
.........................................................................................................................................................................................................................................................................................................................................................
345 files inspected, no offenses detected
```
https://github.com/rubygems/rubygems/commit/bf1320d805
|
| |
|
| |
|
|
|
|
|
|
| |
to #windows?. (This is done instead of logging a deprecation warning.)
https://github.com/rubygems/rubygems/commit/b9fcc7c0ab
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/203f3e3802
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d2c56315e2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following up on https://github.com/rubygems/rubygems/pull/6355, which
turned a crash into a nicer error message, this commit auto-heals the
corrupt lockfile instead.
In this particular case (a corrupt Gemfile.lock with missing
dependencies) the LazySpecification will not have accurate dependency
information, we have to materialize the SpecSet to determine there are
missing dependencies. We've already got a way to handle this, via
`SpecSet#incomplete_specs`, but it wasn't quite working for this case
because we'd get to `@incomplete_specs += lookup[name]` and
`lookup[name]` would be empty for the dependency.
With this commit we catch it a bit earlier, marking the parent spec
containing the missing dependency as incomplete.
https://github.com/rubygems/rubygems/commit/486ecb8f20
|
|
|
|
|
|
| |
https://github.com/ruby/ruby/actions/runs/4286361460/jobs/7466545010
http://ci.rvm.jp/results/trunk_gcc9@ruby-sp2-docker/4462424
http://ci.rvm.jp/results/trunk_clang_13@ruby-sp2-docker/4462422
|
| |
|
| |
|
|
|
| |
Also avoid allocations when looking up `Fiber#storage` if not needed.
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/118d28ad27
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/de3b69f1a7
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/2ea2ead1b3
|