- ruby-core - ml.ruby-lang.org

[ruby-core:125497] [Ruby Bug#22070] `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc
by AMomchilov (Alexander Momchilov) 16 May '26

16 May '26

Issue #22070 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Bug #22070: `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc https://bugs.ruby-lang.org/issues/22070 * Author: AMomchilov (Alexander Momchilov) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading the `label` of a `Thread::Backtrace::Location` (directly or indirectly via e.g. `to_s`) segfauls if called from within `Thread.each_caller_location(1, 1) { it.label }`. Reading the `lineno` or `path` seems to not cause any problems, perhaps by coincidence. ## Minimal repro ```sh ruby -e 'tap { Thread.each_caller_location(1, 1) { it.label } }' # 🧨 Boom ``` ## More cases <details><summary><code>repro.rb</code></summary> ```ruby # All four conditions must hold; varying any one makes the crash go away: # # 1. The yielded location is inspected via a `cme`-reading method # (`label`, `base_label`, `to_s`, `inspect`). # * The `iseq`-based methods (`path`, `absolute_path`, `lineno`) seem to survive by accident. # 2. `start` is exactly 1. # 3. `length` is exactly 1. # * Ranges that compute to length=1 (`1..1`, `1...2`) crash # * e.g. `1..3` (length=3) does not. # 4. The caller is inside a C-method frame (`tap`, `Array#each`, `instance_exec`, `eval`, ...). # * Top-level and plain Ruby methods are safe. $ruby = begin require "rbconfig" RbConfig.ruby rescue LoadError ENV["_"] || "ruby" end def check(label, code) out = IO.popen([$ruby, "-e", code, err: [:child, :out]], &:read) crashed = !$?.success? || out.include?("[BUG]") printf " %-7s %s\n", (crashed ? "CRASH" : "OK"), label end puts "== Which Location method is accessed (start=1, length=1, from tap{}) ==" check("it.path", "tap { Thread.each_caller_location(1, 1) { it.path } }") check("it.absolute_path", "tap { Thread.each_caller_location(1, 1) { it.absolute_path } }") check("it.lineno", "tap { Thread.each_caller_location(1, 1) { it.lineno } }") check("it.label", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("it.base_label", "tap { Thread.each_caller_location(1, 1) { it.base_label } }") check("it.to_s", "tap { Thread.each_caller_location(1, 1) { it.to_s } }") check("it.inspect", "tap { Thread.each_caller_location(1, 1) { it.inspect } }") puts "== Vary `start` (length=1, .label, from tap{}) ==" check("start=0", "tap { Thread.each_caller_location(0, 1) { it.label } }") check("start=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("start=2", "tap { Thread.each_caller_location(2, 1) { it.label } }") check("start=3", "tap { Thread.each_caller_location(3, 1) { it.label } }") puts "== Vary `length` (start=1, .label, from tap{}) ==" check("length=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("length=2", "tap { Thread.each_caller_location(1, 2) { it.label } }") check("length=3", "tap { Thread.each_caller_location(1, 3) { it.label } }") check("length=4", "tap { Thread.each_caller_location(1, 4) { it.label } }") puts "== Range forms equivalent to (start=1, length=1) ==" check("(1, 1)", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("(1..1)", "tap { Thread.each_caller_location(1..1) { it.label } }") check("(1...2)", "tap { Thread.each_caller_location(1...2) { it.label } }") check("(1..2)", "tap { Thread.each_caller_location(1..2) { it.label } }") puts "== Caller context (start=1, length=1, .label) ==" check("top-level", 'Thread.each_caller_location(1, 1) { it.label }') check("tap { ... }", 'tap { Thread.each_caller_location(1, 1) { it.label } }') check("[1].each { ... }", '[1].each { Thread.each_caller_location(1, 1) { it.label } }') check("instance_exec", 'instance_exec { Thread.each_caller_location(1, 1) { it.label } }') check("eval '...'", %{eval 'Thread.each_caller_location(1, 1) { it.label }'}) check("def m; ...; end; m", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; m') check("tap { m }", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; tap { m }') puts puts "Ruby: #{RUBY_DESCRIPTION}" ``` </details> -- https://bugs.ruby-lang.org/

5 6

[ruby-core:125492] [Ruby Bug#22069] Backport openssl 3.2.4/3.3.3/4.0.2
by rhenium (Kazuki Yamaguchi) 16 May '26

16 May '26

Issue #22069 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22069: Backport openssl 3.2.4/3.3.3/4.0.2 https://bugs.ruby-lang.org/issues/22069 * Author: rhenium (Kazuki Yamaguchi) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The main change is OpenSSL 4.0 support. OpenSSL 4.0 was released on 2026-04-14 with several incompatible changes, and the default gems currently included in Ruby 3.3.11/3.4.9/4.0.4 do not compile against it. Although this can be considered more of a feature rather than a bug fix, I believe this would still be useful to backport. Branch maintainers, what do you think? I've created GitHub PRs for each stable branch: - ruby_3_3 (v3.2.2 -> v3.2.4) https://github.com/ruby/ruby/pull/16945 - ruby_3_4 (v3.3.1 -> v3.3.3) https://github.com/ruby/ruby/pull/16946 - ruby_4_0 (v4.0.0 -> v4.0.2) https://github.com/ruby/ruby/pull/16947 -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125430] [Ruby Bug#22059] make -j problem in dtrace build
by wiz (Thomas Klausner) 15 May '26

15 May '26

Issue #22059 has been reported by wiz (Thomas Klausner). ---------------------------------------- Bug #22059: make -j problem in dtrace build https://bugs.ruby-lang.org/issues/22059 * Author: wiz (Thomas Klausner) * Status: Open * ruby -v: 4.0.3 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When building ruby 4.0.3 on NetBSD (from pkgsrc) in a parallel build (make -j16), I sometimes see build problems like this: ``` processing probes in object files dtrace: target object (probes.o) already exists. Please remove the target dtrace: object and rebuild all the source objects if you wish to run the DTrace dtrace: linking process again linking miniruby ld: probes.o: warning: relocation against `$dtrace1391839.rb_str_resurrect' in read-only section `.SUNW_dof' ld: array.o: in function `empty_ary_alloc': /tmp/lang/ruby40/work/ruby-4.0.3/array.c:716:(.text+0x14e0): undefined reference to `__dtraceenabled_ruby___array__create' ld: /tmp/lang/ruby40/work/ruby-4.0.3/array.c:716:(.text+0x1541): undefined reference to `__dtrace_ruby___array__create' ... ``` (longer log attached) I think the problem is (something like) this: In template/Makefile.in, probes.stamp is: ``` probes.stamp: $(DTRACE_REBUILD_OBJS) $(Q) if test -f $@ -o -f probes.$(OBJEXT); then \ $(RM) $(DTRACE_REBUILD_OBJS) $@; \ $(ECHO0) "rebuilding objects which were modified by \"dtrace -G\""; \ $(MAKE) $(DTRACE_REBUILD_OBJS); \ fi $(Q) touch $@ ``` where DTRACE_REBUILD_OBJS includes probes.o. So if probes.stamp (for example, because probes.o should be built when dtrace is enabled) is triggered, it _deletes_ probes.o and then runs make to generate it. At the same time, e.g. miniruby might be built in another make job. miniruby, in common.mk, depends on ``` miniruby$(EXEEXT): config.status $(NORMALMAINOBJ) $(MINIOBJS) $(COMMONOBJS) $(ARCHFILE) ``` COMMONOBJS, in the same file, includes $(DTRACE_OBJ), which is set to probes.o by configure: ``` build/Makefile:DTRACE_OBJ = probes.$(OBJEXT) ``` so this might also trigger a (re)build of probes.o, and in some cases this breaks the build. libruby also has a dependency chain that includes probes.o (it links OBJS which includes EXPORTOBJS which includes COMMONOBJS). ---Files-------------------------------- install.log (19.1 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 15 May '26

15 May '26

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125339] [Ruby Feature#22012] Data class should respond to #dig
by kolbrich (Kevin Olbrich) 14 May '26

14 May '26

Issue #22012 has been reported by kolbrich (Kevin Olbrich). ---------------------------------------- Feature #22012: Data class should respond to #dig https://bugs.ruby-lang.org/issues/22012 * Author: kolbrich (Kevin Olbrich) * Status: Open ---------------------------------------- `Data`s cousin, `Struct` already responds to `#dig`. `Data` objects can show up in deeply nested objects as well, and the semantics of this should be nearly identical to `Struct#dig` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125311] [Ruby Bug#22007] Inconsistent type checking on rescue
by zenspider (Ryan Davis) 14 May '26

14 May '26

Issue #22007 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #22007: Inconsistent type checking on rescue https://bugs.ruby-lang.org/issues/22007 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- this works fine (but I don't think it should): ```ruby begin raise "nope" rescue RuntimeError, /why am I allowed?/, "or me?" => e # yay end ``` whereas this version shows a type error, which seems right: ```ruby begin begin raise "nope" rescue /why am I NOT allowed/, "if I was allowed before?" => e p e end rescue TypeError => te p te end ``` I think all the args on rescue should be checked to be `Module` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:125467] [Ruby Bug#22065] `make rdoc` fails with `invalid byte sequence in US-ASCII` on Ruby 4.0.4 under C locale
by hsbt (Hiroshi SHIBATA) 13 May '26

13 May '26

Issue #22065 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22065: `make rdoc` fails with `invalid byte sequence in US-ASCII` on Ruby 4.0.4 under C locale https://bugs.ruby-lang.org/issues/22065 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- Building Ruby 4.0.4 in an environment where `Encoding.default_external` is `US-ASCII` (e.g. a Docker container with `LC_ALL=C`) fails while documenting `object.c`: ``` (ArgumentError) invalid byte sequence in US-ASCII .bundle/gems/rdoc-7.0.3/lib/rdoc/parser/c.rb:575:in 'String#scan' from .../parser/c.rb:600:in 'RDoc::Parser::C#find_body' from .../parser/c.rb:1025:in 'RDoc::Parser::C#handle_method' ``` https://github.com/ruby/all-ruby/actions/runs/25707463525/job/75480556963#s… 4.0.3 is not affected. The trigger is [`2b22593ac1`](https://github.com/ruby/ruby/commit/2b22593ac1) (backport of master [`a2531ba293`](https://github.com/ruby/ruby/commit/a2531ba293)), which introduced two U+2192 `→` characters in `class.c` comments. RDoc couldn't parse that. `master` branch is unaffected because the RDoc-side bug was fixed in [ruby/rdoc#1657](https://github.com/ruby/rdoc/pull/1657) (commit [`911b122a`](https://github.com/ruby/rdoc/commit/911b122a)) and pulled into Ruby master via [`3f75e99961`](https://github.com/ruby/ruby/commit/3f75e99961). The bump was not backported to `ruby_4_0`, which still ships RDoc 7.0.3. Workaround: build with `LC_ALL=C.UTF-8` or use `--disable-install-doc` option. Four resolutions are under discussion with @k0kubun 1. replace `→` with `->` in `class.c` and backport it. 2. bump the bundled RDoc to 7.2.0 in Ruby 4.0.5 3. Release RDoc 7.0.4 containing [`911b122a`](https://github.com/ruby/rdoc/commit/911b122a) and then bump in Ruby 4.0.5 4. Treat the C locale or build option as a user-side configuration issue and document the workaround. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117434] [Ruby master Bug#20409] Missing reporting some invalid breaks
by kddnewton (Kevin Newton) 13 May '26

13 May '26

Issue #20409 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20409: Missing reporting some invalid breaks https://bugs.ruby-lang.org/issues/20409 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

4 12

[ruby-core:125184] [Ruby Feature#21981] Remove CREF rewriting for methods on cloned classes/modules
by jhawthorn (John Hawthorn) 13 May '26

13 May '26

Issue #21981 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #21981: Remove CREF rewriting for methods on cloned classes/modules https://bugs.ruby-lang.org/issues/21981 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- When a class or module is cloned, Ruby currently rewrites the CREF (constant reference) chain of each copied method so that it points at the new class instead of the original. I don't think this should happen, and methods on a cloned class should retain their original lexical scope. This behaviour was introduced in Ruby 1.9 to fix [Bug #7107], which was reporting that a constant in the original class wasn't available. I think it was done this way because of Ruby's implementation at that time rather than a design choice. This had further changes and fixes in [Bug #10885], [Bug #15877] which were crashes or inconsistencies (stale cache). I'd like us to revisit the design of this behaviour so that it's more intuitive and consistent. ``` ruby class C A = 1 def a; A; end end D = C.clone D.const_set(:A, 2) p C.new.a # => 1 p D.new.a # => 2, but I think it should be 1 ``` In most all other cases in Ruby, methods keep their original lexical scope for constant references: inheritance, mixins, `define_method(..., klass.instance_method(...))`, etc. Cloning a class should behave the same. I think cloning a class is fairly rare, and setting constants on the cloned class more so, but this could be a compatibility issue. This affects `@@class_variables` as well as `CONSTANTS`. FWIW, truffleruby doesn't seem to have this behaviour (which makes sense, part of why I want to remove it is that it's awkward for JIT compiling 😅). https://github.com/ruby/ruby/pull/16651 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125417] [Ruby Bug#22057] test-bundler failed
by tikkss (Tsutomu Katsube) 12 May '26

12 May '26

Issue #22057 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #22057: test-bundler failed https://bugs.ruby-lang.org/issues/22057 * Author: tikkss (Tsutomu Katsube) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T21:56:31Z master 4b6040ca3e) +PRISM [x86_64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- test-bundler failed just one example (./spec/bundler/bundler/cli_common_spec.rb:7). However, test-bundler-parallel is successful. I think this is happening because while test-bundler includes the `--disable-gems` option, it is not specified in the command that launches rspec when running via turbo_tests (Please see comparison of test commands section). Steps to reproduce --- ```console $ git clone git@github.com:ruby/ruby.git $ cd ruby $ ./autogen.sh $ mkdir build && cd build $ mkdir ~/.rubies $ ../configure --prefix="${HOME}/.rubies/ruby-master" $ make $ make test-bundler BUNDLER_SPECS=bundler/cli_common_spec.rb ``` Expected result --- A spec is successful. Actual result --- Failed a spec as follows: ```console $ make test-bundler BUNDLER_SPECS=bundler/cli_common_spec.rb BASERUBY = /Users/zzz/.rbenv/shims/ruby --disable=gems CC = clang -std=gnu23 LD = ld LDSHARED = clang -std=gnu23 -dynamiclib CFLAGS = -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wshorten-64-to-32 -Wundef -pipe XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -DPRISM_XALLOCATOR -I. -I.ext/include/x86_64-darwin24 -I.ext/include -I../include -I.. -I../prism -I../enc/unicode/17.0.0 -Dmodular_gc_dir= CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT DLDFLAGS = -Wl,-undefined,dynamic_lookup -fstack-protector-strong -Wl,-pie -framework CoreFoundation SOLIBS = -lgmp -ldl -lobjc -lpthread LANG = en_US.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --cfg feature="stats_allocator" -g -C lto=thin -C opt-level=3 -C overflow-checks=on --edition=2021 '--out-dir=/tmp/ruby/build/target/release/' '../yjit/src/lib.rs' ZJIT_RUSTC_ARGS = --crate-name=zjit --crate-type=staticlib --cfg feature="stats_allocator" -g -C lto=thin -C opt-level=3 -C overflow-checks=on --edition=2024 '--out-dir=/tmp/ruby/build/target/release/' '../zjit/src/lib.rs' Apple clang version 17.0.0 (clang-1700.6.4.2) Target: x86_64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin generating enc.mk making srcs under enc make[1]: Nothing to be done for `srcs'. generating transdb.h transdb.h unchanged generating makefiles ext/configure-ext.mk ext/configure-ext.mk updated generating makefile exts.mk exts.mk unchanged make[2]: `ruby' is up to date. make[1]: Nothing to be done for `note'. making enc make[1]: Nothing to be done for `enc'. making trans make[1]: Nothing to be done for `trans'. making encs make[1]: Nothing to be done for `encs'. ./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems -C .. -Ilib -r./tool/lib/bundle_env.rb \ spec/bin/bundle install --quiet --gemfile=tool/bundler/dev_gems.rb ./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems \ -r./x86_64-darwin24-fake \ -r../tool/lib/_tmpdir \ -I../spec/bundler -I../spec/lib \ -e "Dir.chdir(ARGV.shift); load('spec/bin/rspec')" \ -s -- -no-report-tmpdir -- ".." \ -r spec_helper -r formatter_overrides spec/bundler/bundler/cli_common_spec.rb Run options: exclude {mri_only: false, man: false, truffleruby_only: true, jruby_only: true, readline: false, permissions: false, no_color_tty: false, ruby_repo: true, git: "2.54.0", rubygems: "4.1.0.dev", realworld: true} F Failures: 1) Bundler::CLI::Common gem_not_found_message should suggest alternate gem names Failure/Error: expect(message).to match("Did you mean 'rails'?") expected "Could not find gem 'ralis'." to match "Did you mean 'rails'?" # ./spec/bundler/bundler/cli_common_spec.rb:11:in 'block (3 levels) in <top (required)>' # ./spec/bundler/spec_helper.rb:164:in 'block (4 levels) in <top (required)>' # ./spec/bundler/spec_helper.rb:164:in 'block (3 levels) in <top (required)>' # ./spec/bundler/support/helpers.rb:414:in 'block in Spec::Helpers#with_gem_path_as' # ./spec/bundler/support/helpers.rb:428:in 'Spec::Helpers#without_env_side_effects' # ./spec/bundler/support/helpers.rb:409:in 'Spec::Helpers#with_gem_path_as' # ./spec/bundler/spec_helper.rb:163:in 'block (2 levels) in <top (required)>' # ./spec/bundler/support/rubygems_ext.rb:132:in 'Kernel#load' # ./spec/bundler/support/rubygems_ext.rb:132:in 'Spec::Rubygems#gem_load_and_activate' # ./spec/bundler/support/rubygems_ext.rb:16:in 'Spec::Rubygems#gem_load' # -e:1:in 'Kernel#load' # -e:1:in '<main>' Finished in 1 minute 9.5 seconds (files took 0.20881 seconds to load) 1 example, 1 failure Failed examples: rspec ./spec/bundler/bundler/cli_common_spec.rb:7 # Bundler::CLI::Common gem_not_found_message should suggest alternate gem names make: *** [yes-test-bundler] Error 1 ``` Comparison of test commands --- test-bundler: ```console ./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems \ -r./x86_64-darwin24-fake \ -r../tool/lib/_tmpdir \ -I../spec/bundler -I../spec/lib \ -e "Dir.chdir(ARGV.shift); load('spec/bin/rspec')" \ -s -- -no-report-tmpdir -- ".." \ -r spec_helper -r formatter_overrides spec/bundler/bundler/cli_common_spec.rb ``` test-bundler-parallel: ```console ./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems \ -r./x86_64-darwin24-fake \ -r../tool/lib/_tmpdir \ -I../spec/bundler \ -e "ruby = ENV['RUBY']" \ -e "ARGV[-1] = File.expand_path(ARGV[-1])" \ -e "ENV['RSPEC_EXECUTABLE'] = ruby + ARGV.shift" \ -e "load ARGV.shift" \ -s -- -no-report-tmpdir -- \ " -C .. -Ispec/bundler -Ispec/lib .bundle/bin/rspec -r spec_helper" \ ../spec/bin/parallel_rspec -r formatter_overrides \ --runtime-log ../tmp/parallel_runtime_rspec.log ../spec/bundler/bundler/cli_common_spec.rb ``` See also --- * https://docs.ruby-lang.org/en/master/contributing/building_ruby_md.html * https://docs.ruby-lang.org/en/master/contributing/testing_ruby_md.html -- https://bugs.ruby-lang.org/

1 1