Previously `(2..).cover?("2"..)` was false, but
`(..2).cover?(.."2")` was true. This changes it so both are false,
treating beginless ranges the same as endless ranges in regards to
type checks.
This also adds documentation to #cover? to describe behavior with
beginless and endless ranges, testing each documentation example,
which is how this bug was found.
Fixes [Bug #18155]
It was being explicitly required from `Gem::Specification` but also a
strange autoload was set for it at `Gem::Version`. The autoload was non
standard because it should've been done in the `Gem` module, not in
`Gem::Specification`, since that's where the constant is expected to get
defined. Doing this might get deprecated in the future, and it was not
being effective anyways due to the explicit require.
Unify everything with an `autoload` at the right place.
https://github.com/rubygems/rubygems/commit/174ea3e24c
THREAD_MODEL is exported already, so this matches that. Exporting this
is simpler than inspecting configure_args and arch and matching that up
with a specific configure.ac.
Fix GH-5976
In the event that we are crashing due to a corrupt Ruby stack, we might
re-enter rb_vm_bugreport() due to failed assertions in
rb_backtrace_print_as_bugreport() or SDR(). In these cases we were
printing the bug report ad infinitum with unbounded recusion.
I seem to run into this every once in a while and the amount of log it
prints out is pretty distracting. On CI environments it makes the log
output unnecessarily big. Let's fix this.
Ref: https://bugs.ruby-lang.org/issues/18339
Design:
- This tries to minimize the overhead when no hook is registered.
It should only incur an extra unsynchronized boolean check.
- The hook list is protected with a read-write lock as to cause
contention when some hooks are registered.
- The hooks MUST be thread safe, and MUST NOT call into Ruby as they
are executed outside the GVL.
- It's simply a noop on Windows.
API:
```
rb_internal_thread_event_hook_t * rb_internal_thread_add_event_hook(rb_internal_thread_event_callback callback, rb_event_flag_t internal_event, void *user_data);
bool rb_internal_thread_remove_event_hook(rb_internal_thread_event_hook_t * hook);
```
You can subscribe to 3 events:
- READY: called right before attempting to acquire the GVL
- RESUMED: called right after successfully acquiring the GVL
- SUSPENDED: called right after releasing the GVL.
The hooks MUST be threadsafe, as they are executed outside of the GVL, they also MUST NOT call any Ruby API.
Prior to this commit, `bundle add GEM_NAME` updated the lockfile,
but `bundle remove GEM_NAME` left GEM_NAME in the lockfile.
By invalidating the cached `Bundle.definition`, the existing code
handles that without a problem.
https://github.com/rubygems/rubygems/commit/aa0794d6a9
The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.
Fix the accessor to properly update the underlying full specification.
https://github.com/rubygems/rubygems/commit/efa41babfa
This change was never covered with a spec, and we have recently covered
the case of partially deleted gems with specs and it works fine
(installation is "auto-healed").
https://github.com/rubygems/rubygems/commit/6e66ee4235
This issue was not detected because when all traces of old YAML parser
and emitter `Syck` were removed, this null-type.gemspec.rz marshalled
gemspec was updated to no longer load `YAML::Syck::PrivateType` but load
`Psych::PrivateType` instead.
However, realworld old marshalled gemspecs still use the
`YAML::PrivateType` constant, so this commit replaces the gemspec to be
the real pry-0.4.7 marshalled gemspec, so that it catches this issue.
https://github.com/rubygems/rubygems/commit/51b330b8d2
This test is making sure that RubyGems is able to load old marshalled
gemspecs that include a field loading `YAML::PrivateType` instances in
the `rubyforge_project` field instead of `nil` due to a bug in old YAML
emitters.
At some point, the `rubyforge_project` field was removed and this test
was updated to just check another field. However, in the realworld other
fields do not have this issue and the marshalled gemspec we use for
testing still has this issue in the field reserved for the
`rubyforge_project` field. So I think updating the test to check other
field was not correct.
Instead, since the `rubyforge_project` field is now ignored, we no
longer need to worry about any conversion in this field. The only thing
we care about is that the marshal loading still works (which requires
that the constant is at least defined).
So this commit updates the test to make this more clear.
https://github.com/rubygems/rubygems/commit/cddfacf6d4
This old bug used to affect the `rubyforge_project` field in serialized
gemspecs. However, this field has been removed and it's no longer
present in marshaled loaded gemspecs.
So, while the constant is still present in these marshalled gemspecs and
we still need to make sure it exists, we no longer need to clean it up
from the loaded data.
https://github.com/rubygems/rubygems/commit/09df18e522
Generally this warning is skipped for gemspec development dependencies.
I think because it's common to override them in the Gemfile to change
the source, for example.
But the order of conditions was not correct and the warning was still
being printed in one case.
https://github.com/rubygems/rubygems/commit/da9d1d6a3f
This alternative really uses only the Gemfile, and can never end up
being absurd, because it will never be suggested when there's no
lockfile, and it suggests deleting the lockfile.
https://github.com/rubygems/rubygems/commit/5d154dd50e
Noah Gibbs
Jeremy Evans
Burdette Lamar
git
Alexander Ilyin
Nobuyoshi Nakada
David Rodríguez
Hiroshi SHIBATA
Pavel Rosický
Yusuke Endoh
Kazuhiro NISHIYAMA
nick evans
Alan Wu
Jean Boussier
Kouhei Yanagita
Ellen Marie Dash