Although `pend` in test-unit gem expects the block does not pass if it
is given, our `pend` should ignore the block silently as same as it
just skips the test with no message by default. Add an unused
parameter, to suppress the warning for the block to be ignored.
Some packaging systems that include support for running tests,
such as OpenBSD's, do not allow outbound network connections
during testing for security reasons. EACCES is the error raised by
OpenBSD in this case.
Profiling of `JSON.dump` shows a significant amount of time spent
in `rb_enc_str_asciionly_p`, in large part because it fetches the
encoding.
It can be made twice as fast in this scenario by first checking the
coderange and only falling back to fetching the encoding if the
coderange is unknown.
Additionally we can skip fetching the encoding for the common
popular encodings.
On OSX, String#rindex is slow due to the lack of `memrchr`.
The fallback implementation finds a match by instead doing
a `memcmp` on every single character in the search string
looking for a substring match.
For OSX hosts, this changeset introduces a simple `memrchr`
implementation, `rb_memrchr`, that can be used instead. An
example benchmark below demonstrates an 8000 char long
search string with a 10 char substring near the end.
```
ruby-master | substring near the end | osx
UTF-8
user system total real
index 0.000111 0.000000 0.000111 ( 0.000110)
rindex 0.000446 0.000005 0.000451 ( 0.000454)
```
```
ruby-patched | substring near the end | osx
UTF-8
user system total real
index 0.000112 0.000000 0.000112 ( 0.000111)
rindex 0.000057 0.000001 0.000058 ( 0.000057)
```
It is loaded by `Fetcher` so in most case it's fine.
But if using `bundler/inline` and a gem need to be fetched,
`securerandom` will be loaded and cause a conflict.
Can be reproduced with:
```ruby
require 'bundler/inline'
gemfile do
source 'https://rubygems.org'
gem 'graphql', '~> 2.0'
gem 'graphql-client', '~> 0.18'
end
require 'json'
require 'graphql/client'
require 'graphql/client/http'
```
Ref: https://github.com/rails/rails/pull/52473#issuecomment-2284667451
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
The default version of securerandom (0.2.2) gets activated by RubyGems,
but does not match Rails requirements (>= 0.3), leading to an error like
this:
```
$ gem exec rails new repro
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:2246:in `raise_if_conflicts': Unable to activate activesupport-7.2.1, because securerandom-0.2.2 conflicts with securerandom (>= 0.3) (Gem::ConflictError)
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1383:in `activate'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1421:in `block in activate_dependencies'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `each'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `activate_dependencies'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1385:in `activate'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `block in gem'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `synchronize'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:193:in `activate!'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:73:in `execute'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:326:in `invoke_with_build_args'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:255:in `invoke_command'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:194:in `process_args'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:152:in `run'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:56:in `run'
from /Users/deivid/code/rubygems/rubygems/exe/gem:12:in `<main>'
```
Vendoring our own securerandom fixes the issue since that way we avoid
activating the gem internally.
`set_parser_s_value` does nothing in parser therefore no need to
create string object in parser `set_yylval_node`.
# Object allocation
Run `ruby benchmarks/lobsters/benchmark.rb` with the patch
```diff
diff --git a/benchmarks/lobsters/benchmark.rb b/benchmarks/lobsters/benchmark.rb
index 240c50c..6cdd0ac 100644
--- a/benchmarks/lobsters/benchmark.rb
+++ b/benchmarks/lobsters/benchmark.rb
@@ -7,6 +7,8 @@ Dir.chdir __dir__
use_gemfile
require_relative 'config/environment'
+printf "allocated_after_load=%d\n", GC.stat(:total_allocated_objects)
+exit
require_relative "route_generator"
# For an in-mem DB, we need to load all data on every boot
```
## Before
```
ruby 3.4.0dev (2024-08-31T18:30:25Z master d6fc8f3d57) [arm64-darwin21]
...
allocated_after_load=2143519
```
## After
```
ruby 3.4.0dev (2024-09-01T00:40:04Z fix_bugs_20695 d1bae52f75) [arm64-darwin21]
...
allocated_after_load=1579662
```
## Ruby 3.3.0 for reference
```
ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin21]
...
allocated_after_load=1732702
```
It's possible for a GC to run between the calls of GC.latest_gc_info,
which would cause the test to fail. We can disable GC so that GC only
triggers manually.
Since `Gem.open_file` no longer locks the target file and is same as
`File.open` now, simply `Gem.read_binary` should read in binary mode.
Also the body of `Gem.write_binary` is same as `File.binwrite`.
https://github.com/rubygems/rubygems/commit/44df9045df
Ruby ships with empty directories for default gems. If Ruby
installations has unsafe world-writable permissions, we will complain
when about to install a gem that happens to be also a default gem,
because we'll start by removing the previous install folder and that's
supposed to be insecure due to too loose permissions.
However, if the folder is empty, we don't actually need to remove
anything, so we can skip the whole thing, avoiding the errors.
https://github.com/rubygems/rubygems/commit/2f3cd8ac4e
It's to avoid the stucking "Windows result" job.
It seems only the files included in the list of the pull-request - path-ignore,
GitHub Actions "Windows result" permanently waits for the jobs that don't exist.
Hiroshi SHIBATA
git
Nobuyoshi Nakada
ydah
Jeremy Evans
Peter Zhu
Durable Programming Team
Kevin Newton
tomoya ishida
Mari Imaizumi
Jean Boussier
zverok
Takashi Kokubun
Zack Deveau
Étienne Barrié
David Rodríguez
yui-knk
Burdette Lamar
Jun Aruga