We were setting the wrong `extension_dir` for git specs stubs
Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)
Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same
https://github.com/rubygems/rubygems/commit/a94acb465b
Previously, Kernel#lambda returned a non-lambda proc when given a
non-literal block and issued a warning under the `:deprecated` category.
With this change, Kernel#lambda will always return a lambda proc, if it
returns without raising.
Due to interactions with block passing optimizations, we previously had
two separate code paths for detecting whether Kernel#lambda got a
literal block. This change allows us to remove one path, the hack done
with rb_control_frame_t::block_code introduced in 85a337f for supporting
situations where Kernel#lambda returned a non-lambda proc.
[Feature #19777]
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
[Bug #19012]
man recvmsg(2) states:
> Return Value
> These calls return the number of bytes received, or -1 if an error occurred.
> The return value will be 0 when the peer has performed an orderly shutdown.
Not too sure how one is supposed to make the difference between a packet of
size 0 and a closed connection.
If a legacy multi remote Gemfile depends transitively on a default gem,
then in standalone mode we'd fail to fetch the proper version from the
source that includes it, since we were adding it to `specs` (instead of
`remote_specs`), which was already including the default version of the
gem, and thus preventing the remote version from "overwriting that" and
being added to the index. We should add it to the `remote_specs` index
directly instead.
https://github.com/rubygems/rubygems/commit/05f4f9dfc0
On legacy Gemfiles with multiple remote sources, where all of them
support the compact index API, we were still falling back to full
indexes.
Fixing this also allows to simplifying the code.
https://github.com/rubygems/rubygems/commit/b1357c8e72
https://github.com/ruby/ruby/actions/runs/5956398507/job/16157091112
This has been extremely flaky on macOS GitHub Actions.
Benoit suggested to quarantine it if it's too problematic (it is) and
there's no reasonable fix in a short time (it already took too long).
So this commit follows the suggestion.
We should remove revert this once rb_cloexec_open() is fixed.
Deprecate Kernel#open and IO support for subprocess creation and
forking. This deprecates subprocess creation and forking in
- Kernel#open
- URI.open
- IO.binread
- IO.foreach
- IO.readlines
- IO.read
- IO.write
This behavior is slated to be removed in Ruby 4.0
[Feature #19630]
{Nil,True,False}Class#singleton_methods always returns [] indicating
that there are no singleton methods defined, so #singleton_method
should be consistent with that.
Fixes [Bug #11064]
[Feature #19755]
Before (in /tmp/test.rb):
```ruby
Object.class_eval("p __FILE__") # => "(eval)"
```
After:
```ruby
Object.class_eval("p __FILE__") # => "(eval at /tmp/test.rb:1)"
```
This makes it much easier to track down generated code in case
the author forgot to provide a filename argument.
Samuel Giddins
Martin Emde
Alan Wu
Benoit Daloze
Hiroshi SHIBATA
Jean Boussier
Imir Kiyamov
David Rodríguez
Nobuyoshi Nakada
Samuel Williams
Takashi Kokubun
Gaurav Khanna
Ngan Pham
Mike Dalessio
Jeremy Evans
Jean Boussier