The original implementation of this flag was too naive and all it did
was restricting gems to locally installed versions if there are any
local versions installed.
However, it should be much smarter. For example:
* It should fallback to remote versions if locally installed version
don't satisfy the requirements.
* It should pick locally installed versions even for subdependencies not
yet discovered.
This commit fixes both issues by using a smarter approach similar to how
we resolve prereleases:
* First resolve optimistically using only locally installed gems.
* If any conflicts are found, scan those conflicts, allow remote
versions for the specific gems that run into conflicts, and
re-resolve.
https://github.com/rubygems/rubygems/commit/607a3bf479
Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>
These apparently break compilation on old MacOS toolchains, because the
MachO section name is capped to 16 chars (although, on my MacOS, at
least, the section name just gets truncated). Nevertheless, these serve
no purpose on non-ELF platforms (they're part of the LSB Linux ABI).
[Bug #20677]
This wasn't looking at the right macro name for pac-ret support, so if
Ruby was compiled with pac-ret but NOT BTI, then the ELF note would not
be emitted.
It is expected that reading from command with offset fails by ESPIPE
and the pipe will be closed immediately. While this causes the child
process to terminate by SIGPIPE usually, cmd.exe yields the message
bellow.
```
The process tried to write to a nonexistent pipe.
```
getlogin is only called if USER environment variable is not set,
but if getlogin returns NULL in that case, then do not call
getpwnam, and assume /bin/sh as shell.
Mentioned in comment to bug 20586.
We don't need to build a linked list from the finalizer table and
instead we can just run the finalizers by iterating the ST table.
This also improves the performance at shutdown, for example:
1_000_000.times.map do
o = Object.new
ObjectSpace.define_finalizer(o, proc { })
o
end
Before:
Time (mean ± σ): 1.722 s ± 0.056 s [User: 1.597 s, System: 0.113 s]
Range (min … max): 1.676 s … 1.863 s 10 runs
After:
Time (mean ± σ): 1.538 s ± 0.025 s [User: 1.437 s, System: 0.093 s]
Range (min … max): 1.510 s … 1.586 s 10 runs
Some Ruby apps subclass Logger without running the superclass
constructor, which means that `@level_override` isn't initialized
properly. This can be fixed in some cases, but the gem should maintain
backwards compatibility.
https://github.com/ruby/logger/commit/3246f38328
As @jeremyevans pointed out for commit eb2d8b1:
> Each Tempfile instance has a separate File instance and file descriptor:
>
> t = Tempfile.new
> t.to_i # => 6
> t.dup.to_i => 7
FinalizerManager will keep track of the open File objects for the
particular file and will only unlink the file when all of the File objects
have been closed.
https://github.com/ruby/tempfile/commit/753ab16642
The Closer and Remover finalizers are defined on different objects in
Tempfile. The Closer is defined on the Tempfile object while the Remover
is defined on the finalizer_obj. This means that there is no guarantee
of the finalizer order.
On Windows, we must close the file before removing it because we cannot
remove an open file. But since the order is not guaranteed, the GC may
run the Remover finalizer first, which will fail with an Errno::EACCES
(Permission denied @ apply2files).
This commit changes it so that both the Closer and Remover finalizers
are defined on the finalizer_obj, which guarantees the order that it is
ran.
https://github.com/ruby/tempfile/commit/eb2d8b1175