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.
The `rev && has_commit(rev, "ruby_#{TARGET_VERSION.tr('.','_')}")`
case seems to be used if and only if it's manually specified in the
argument to the done command. It was hard to notice it with the previous
code.
