After reading [this blog
post](https://blog.rubygems.org/2011/08/31/shaving-the-yaml-yak.html),
published almost 10 years ago already, my understanding is that this
problem could come up in two ways:
* Rubygems.org serving corrupted gemspecs". As far as I understand this
was fixed in rubygems.org a lot time ago, since
https://github.com/rubygems/rubygems.org/pull/331.
* Clients having a ten years old gemspec cache with some of these bad
gemspecs. In this case, there's no easy solution but I think ten years
is enough and rebuilding the cache should do the trick.
So, I think it's time we remove this.
https://github.com/rubygems/rubygems/commit/afcb15d556
A fresh `gem install` might not reproduce the exact `bundle install`
environment that originally caused the error. It also makes it harder
for the user to troubleshoot the error since she needs to run a separate
command.
Instead, show the original error and backtrace directly.
https://github.com/rubygems/rubygems/commit/49c2abfec6
To mimic built-in rubygems behaviour, only thing that should be
approximated is the lockfile version. Other alternatives like
`BUNDLER_VERSION` should be respected exactly.
https://github.com/rubygems/rubygems/commit/dbd667d4bc
Ruby 1.9.2 removed "." from LOAD_PATH for robustness and security reasons.
This code was introduced by 56fc830e19 commit
to helping users understand the issue and had a guard condition to include the message for `RUBY_VERSION >= "1.9"`.
However, the guard condition was removed as part of the "Ruby version leftover" cleanup by
8c9cf76e41
Ruby 1.9 development was ended a long time ago and this message is not useful anymore.
https://github.com/rubygems/rubygems/commit/a23609b15a
The existing interrupt handling using `SharedHelpers.trap` fails when the previous
handler for a signal is not callable (for example, when it is the string "DEFAULT").
Instead, we now handle interrupts by aborting the process when worker threads are
running, and restore the previous handler after worker threads are finished.
Fixes#4764.
https://github.com/rubygems/rubygems/commit/b9f455d487
When looking for libraries to load with a feature name without
extension, `.rb` files are given priority. However, since the
feature index arrays were not in that order of priority, but in
the order in which they were loaded, a lower priority extension
library might be returned. In that case, the `.rb` file had to be
searched for again from the `$LOAD_PATH`, resulting in poor
performance.
This fixes https://bugs.ruby-lang.org/issues/18038. The provided
reproduction showed that this happens in heredocs with double
interpolation. In this case `DSTR` was getting returned but needs to be
convered to a `EVSTR` which is what is returned by the function. There
may be an additional bug here that we weren't able to produce. It seems
odd that `STR` returns `DSTR` while everything else should return
`EVSTR` since the function is `new_evstr`.
[Bug #18038][ruby-core:104597]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>