If a gem is required circular, and there are unresolved specs depending
on it, we may end up in an activation conflict.
The solution is to not try to activate unresolved gems when requiring a
default gem, regardless of it having already been activated or not.
https://github.com/rubygems/rubygems/commit/3b2b8f4e3e
The following conditions must be met:
* A default gem is required.
* A previous require left some gems unresolved, and those dependencies
themselves depend on the default gem.
In this case, rubygems require will first activate the default version
of the gem, then try to activate another unresolved version of the
default gem that conflicts with the first activation.
The solution is, if we are in the middle of requiring a default gem,
skip this step, because we have already activated it successfully.
https://github.com/rubygems/rubygems/commit/8cd5608db5
Co-authored-by: Stan Hu <stanhu@gmail.com>
I've seen this error sometimes but never found it helpful, since the
culprit has never been thread/monitor related, so it just adds noise.
Right now I'm seeing an issue in CI where we seem to be crashing during
ensure and showing a weird backtrace:
```
#<Thread:0x000055821d7a73b8 /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:167 run> terminated with exception (report_on_exception is true):
/home/runner/work/rubygems/rubygems/lib/rubygems/platform.rb:141:in `==': undefined local variable or method `to_a' for false:FalseClass (NameError)
Did you mean? to_s
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `!='
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `require'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:441:in `block in ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `each'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:413:in `ensure_gem_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems/resolver/specification.rb:110:in `download'
from /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:173:in `block (2 levels) in install'
```
Let's get this out of the picture in case that helps clarify the
culprit.
https://github.com/rubygems/rubygems/commit/87ce40b70e
Currently Bundler needs to do cumbersome operations to revert custom
RubyGems require on a `bundler/setup` context. This causes issues when
third party gems also monkeypatch require, since Bundler will also undo
those decorations.
This commit allows it to use the simpler approach of properly telling
RubyGems that it needs to default to built-in require without any extra
magic.
https://github.com/rubygems/rubygems/commit/1df5009e14
Co-authored-by: Xavier Noria <fxn@hashref.com>
Since RDoc does not parse string literals as documents, `eval` the
entire file instead of embedding in a here-document.
On the contrary, as `gem_original_require` alias is an implementation
detail but not for users, it should not be documented.
https://github.com/rubygems/rubygems/commit/cad4cf16cf
jruby-head (which will be JRuby 9.4.0.0) can now properly process
the keywords to Kernel#warn. I cannot think of any capability based
test for this so I constrained it using a version guard. Only JRuby
will ever hit the version guard.
https://github.com/rubygems/rubygems/commit/cd468c7e0f
It's very unlikely to hit this case, but it is possible, as
Thread::Backtrace::Location#path can return nil if the location is
a cfunc with no previous iseq. See location_path in vm_backtrace.c
in Ruby.
https://github.com/rubygems/rubygems/commit/511935645a
* See https://github.com/oracle/truffleruby/issues/2046
* `<internal:` is a common prefix also used by core Ruby files in CRuby.
* test_no_kernel_require_in_*warn_with_uplevel already test this.
* Unfortunately just skipping `<internal:` in the Ruby implementation
is not enough, because RubyGems' #warn would not skip the
`<internal:` require (TruffleRuby defines #require in Ruby),
and the Ruby implementation's #warn would not skip
RubyGems's #require. The #caller_locations(0) look like this:
warnee.rb:1:in `<top (required)>' # where #warn is called
<internal:core> core/kernel.rb:234:in `gem_original_require' # not skipped by RubyGems' warn, skipped by the Ruby impl
rubygems/core_ext/kernel_require.rb:54:in `require' # not skipped by the Ruby impl's warn, what would be shown without this fix
warn.rb:1:in `<main>' # what would be correct
warn.rb is
require "warnee"
warnee.rb is
puts caller_locations(0), nil
warn "oops", uplevel: 1
https://github.com/rubygems/rubygems/commit/7c838f7419
In the cases where the initial manually `-I` path resolution succeeded,
we were passing a full path to the original require effectively skipping
the `$LOADED_FEATURES` cache. With this change, we _only_ do the
resolution when a matching requirable path is found in a default gem. In
that case, we skip activation of the default gem if we detect that the
required file will be picked up for a `-I` path.
https://github.com/rubygems/rubygems/commit/22ad5717c3
