`ac_abs_builddir` can be empty when the build is top-level (not
subdirs, and Ruby is usually the case). In such case, the MINIRUBY is
expanded to `$RUBY -I -r'$(arch)-fake'`, which interprets `-r$(arch)-fake`
as an argument to `-I` option. This led to:
- Not loading the fake config file
- Then not setting `CROSS_COMPILING` constant during extmk.rb execution
- Then misusing cross-compiled `./miniruby` instead of baseruby to generate
files used in exts.
This commit fixes the issue by handling the empty `ac_abs_builddir` case
properly.
This commit changes the external GC to be loaded with the `--gc-library`
command line argument instead of the RUBY_GC_LIBRARY_PATH environment
variable because @nobu pointed out that loading binaries using environment
variables can pose a security risk.
When the registerred unblock function is called, it should retry
the cancelled blocking function if possible after checkints.
For example, `SIGCHLD` can cancel this method, but it should not
raise any exception if there is no trap handlers.
The following is repro-code:
```ruby
require 'socket'
PN = 10_000
1000000.times{
p _1
PN.times{
fork{
sleep rand(0.3)
}
}
i = 0
while i<PN
cpid = Process.wait -1, Process::WNOHANG
if cpid
# p [i, cpid]
i += 1
end
begin
TCPServer.new(nil, 0).close
rescue
p $!
exit!
end
end
}
```
combination with `send` method (optimized) or `method_missing`
and forwarding send (`...`) needs to respect given
`rb_forwarding_call_data`. Otherwize it causes critical error
such as SEGV.
If $HOME isn't a valid directory, these specs fail, but I think it
is better to skip in this case, as it does not indicate a bug.
This fixes specs when run in the OpenBSD port, which sets $HOME
to an invalid directory to ensure that software's build system
is not accidentally relying on it.
ruby/ruby measures test coverage of C code, but the `#line` directive
generated by prism points to a file that does not exist, so coverage is
not taken properly.
This changeset specifies the location of the source files as a relative
path in terms of ruby/ruby repo.
https://github.com/ruby/prism/commit/1a2626be27
RFC9562 was released almost two weeks ago, so we can replace the "draft"
UUIDv7 URL with the final RFC URL too. RFC9562 obsoletes RFC4122, so I
replaced its link as well.
https://github.com/ruby/securerandom/commit/1e41c3d2cb
When locked only to RUBY, and some locked spec does not meet locked
dependencies, Bundler would remove the only locked platform and end up
creating a lockfile with empty sections.
We can't rely on our criteria to remove invalid platforms if locked
specs are not valid in the first place.
https://github.com/rubygems/rubygems/commit/1dba05cf53
Calling `remote!` or `cached!` on the source was expiring local specs
for now reason. It's unnecessary to override these methods for path
sources since they only deal with local specifications.
https://github.com/rubygems/rubygems/commit/aa93b196a2
If RUBY is the only platform in the lockfile, we were skipping adding
the local platform to the list of resolution platforms. This generally
works anyways, because we had some code to still add it if the RUBY
platform is not valid for the set of locked gems.
However, sometimes it can happen that "RUBY" is valid for the current
set of locked gems, but when adding a new dependency, it becomes
invalid. For example, when adding sorbet to a Gemfile, that will
introduce `sorbet-static` as an indirect dependency which does not have
a generic "RUBY" variant. This will cause resolution to take a long time
continuously backtracking trying to find solutions that don't introduce
`sorbet-static` as a dependency and will eventually fail.
Instead, we can always add the local platform to the set of resolution
platforms before resolving, and remove it as necessary after resolution
so that we lock the correct set of platforms.
https://github.com/rubygems/rubygems/commit/6ed1fe6050
* The string search parser was more memory efficient but
in some cases, much slower. Reverting until a better
solution is found.
* Handle the situation where the line might be blank (Artifactory bug)
https://github.com/rubygems/rubygems/commit/222d38737d
With --repeat-count=2, timing-related test seems to fail frequently.
I'm not sure of the cause, but I want to reduce the errors by setting
RUBY_TEST_TIMEOUT_SCALE.
[Bug #20585]
This was changed in 36a06efdd9f0604093dccbaf96d4e2cb17874dc8 because
`String.new(1024)` would end up allocating `1025` bytes, but the problem
with this change is that the caller may be trying to right size a String.
So instead, we should just better document the behavior of `capacity:`.