May 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125562] [Ruby Bug#22078] mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4
by hsbt (Hiroshi SHIBATA) 21 May '26

21 May '26

Issue #22078 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22078: mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4 https://bugs.ruby-lang.org/issues/22078 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: DONTNEED ---------------------------------------- On mswin builds, `win32/Makefile.sub` builds `XCFLAGS` without `XINCFLAGS`, so the include path written by `configure.bat --with-opt-dir=...` never reaches `cl.exe` and `#include <gmp.h>` cannot be resolved. `master` and `ruby_4_0` are fixed by https://github.com/ruby/ruby/commit/13c64a8a20, but neither `ruby_3_4` nor `ruby_3_3` has it. How it surfaces differs between the two: - `ruby_3_4`: `win32/setup.mak` auto-enables GMP whenever gmp is present, so the build tries to use it and fails on the missing `gmp.h`. - `ruby_3_3`: `win32/setup.mak` only enables GMP when `--with-gmp` is explicitly passed. Without the flag the build passes but GMP is never used; with the flag, it fails the same way as 3.4. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125466] [Ruby Bug#22064] GC compaction breaks compare-by-identity sets
by peterzhu2118 (Peter Zhu) 21 May '26

21 May '26

Issue #22064 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #22064: GC compaction breaks compare-by-identity sets https://bugs.ruby-lang.org/issues/22064 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/16923 Compare-by-identity sets use the address for hashing, so we must pin it so the object does not move in GC compaction. Objects in a compare-by-identity set is not currently pinned, causing the set to be broken if the object is moved. For example: ```ruby set = Set.new.compare_by_identity o = Object.new set.add(o) puts set.include?(o) GC.verify_compaction_references(expand_heap: true, toward: :empty) puts set.include?(o) ``` It should output true twice, but it outputs true and false. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125518] [Ruby Bug#22072] [BUG] should have cvar cache entry
by rmosolgo (Robert Mosolgo) 21 May '26

21 May '26

Issue #22072 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #22072: [BUG] should have cvar cache entry https://bugs.ruby-lang.org/issues/22072 * Author: rmosolgo (Robert Mosolgo) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! I have a CI build for my project that runs on Ruby 4.0.4, and it has recently started _sometimes_ segfaulting with this error: "". I have seen failures in two different spots: - In the middle of tests: ``` /home/runner/work/graphql-ruby/graphql-ruby/vendor/bundle/ruby/4.0.0/gems/liquid-4.0.4/lib/liquid/strainer.rb:43: [BUG] should have cvar cache entry ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] ``` https://github.com/rmosolgo/graphql-ruby/actions/runs/25750012675/job/75623… - At the very beginning of the suite: ``` # Running tests with run options --seed 45415: /home/runner/work/graphql-ruby/graphql-ruby/spec/graphql/dataloader_spec.rb:1515: warning: Scheduler should implement #fiber_interrupt /home/runner/work/graphql-ruby/graphql-ruby/spec/graphql/schema/ractor_shareable_spec.rb:54: warning: Ractor API is experimental and may change in future versions of Ruby. /home/runner/work/graphql-ruby/graphql-ruby/vendor/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/generators.rb:27: [BUG] should have cvar cache entry ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] ``` https://github.com/rmosolgo/graphql-ruby/actions/runs/25922299759/job/76194… I have attached the full crash messages to this issue. I don't have any guesses what to do next with these errors, but I thought I'd report them in case they're helpful. I'm happy to debug with my project if there's anything I can do to help. For now, I can get it to pass by re-running the build. Thanks! Robert ---Files-------------------------------- dump1.txt (15.9 KB) dump2.txt (78.3 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125553] [Ruby Bug#22076] defined? returns nil for protected methods defined in a module even when callable
by sampokuokkanen (Sampo Kuokkanen) 21 May '26

21 May '26

Issue #22076 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22076: defined? returns nil for protected methods defined in a module even when callable https://bugs.ruby-lang.org/issues/22076 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Filing this to confirm whether defined? should return "method" here (matching the call check), or whether the current nil behavior is intentional. ### Summary `defined?` returns `nil` for a protected method defined in a module, even when the same call succeeds. For a protected method defined in a class, `defined?` and the call agree. ### Reproduction ~~~ruby module Mix def secret; 42; end protected :secret end class A; include Mix; end class B include Mix def call_it(other) = other.secret def defined_it(other) = defined?(other.secret) end p B.new.call_it(A.new) # => 42 p B.new.defined_it(A.new) # => nil (expected "method") ~~~ The class-defined version returns `"method"` for the same shape: ~~~ruby class Base def secret; 42; end protected :secret end class A < Base; end class B < Base def defined_it(other) = defined?(other.secret) end p B.new.defined_it(A.new) # => "method" ~~~ ### Fix Use `rb_callable_method_entry_with_refinements` and the existing `vm_defined_class_for_protected_call` helper. Patch with test: (will update soon) ## Environment - MacOS Tahoe 26.2 - Ruby master (HEAD) - ruby 4.0.1 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125546] [Ruby Bug#22075] heap-use-after-free in `rb_vm_ci_lookup` under parallel Ractors
by zonuexe (Kenta USAMI) 21 May '26

21 May '26

Issue #22075 has been reported by zonuexe (Kenta USAMI). ---------------------------------------- Bug #22075: heap-use-after-free in `rb_vm_ci_lookup` under parallel Ractors https://bugs.ruby-lang.org/issues/22075 * Author: zonuexe (Kenta USAMI) * Status: Open * ruby -v: 4.0.5 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Environment - `ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [aarch64-linux]` - Also reproduced on `ruby 4.0.4 ... [x86_64-linux]`. ## Summary Under a parallel Ractor pool, a GC sweep on one Ractor frees a `T_DATA` object while `rb_vm_ci_lookup` on another Ractor reads that freed heap memory. Pure-Ruby code triggers it; the VM crashes (SIGSEGV). ## Reproduction No minimal script isolated yet. Reproduced with the `rigor` project at tag `v0.1.7` (https://github.com/rigortype/rigor/tree/v0.1.7) 1. Build Ruby + native gems with AddressSanitizer: ``` ./configure --disable-yjit \ cflags="-fsanitize=address -fno-sanitize-address-use-after-scope -g -O1" \ cppflags="-fsanitize=address" LDFLAGS="-fsanitize=address" ``` 2. Run a spec that drives a 2-worker Ractor pool: ``` ASAN_OPTIONS="detect_leaks=0 detect_stack_use_after_return=0 halt_on_error=0" \ RIGOR_INCLUDE_RACTOR_POOL=1 \ bundle exec rspec spec/rigor/analysis/runner_pool_spec.rb ``` CI failure: https://github.com/rigortype/rigor/actions/runs/26123249293/job/76830355801 ## Expected Pure-Ruby code on a Ractor pool runs to completion or raises a Ruby exception. It does not corrupt the heap. ## Actual SIGSEGV (≈70% of runs without a sanitizer; crash site varies). AddressSanitizer (Ruby 4.0.5, aarch64-linux, 3 Ractors): ``` ERROR: AddressSanitizer: heap-use-after-free READ of size 4 rb_vm_ci_lookup vm_method.c:699 vm_ci_new_ vm_callinfo.h:219 vm_ci_new_runtime_ vm_callinfo.h:240 vm_search_super_method vm_insnhelper.c:5152 (a Ruby `super` call) freed by: rb_gc_impl_free gc/default/default.c:8279 rb_data_free gc.c:1205 rb_gc_obj_free gc.c:1351 gc_sweep_plane gc/default/default.c:3510 previously allocated by: rb_data_typed_object_zalloc gc.c:1131 rbs_new_location2 (rbs gem C extension) SUMMARY: AddressSanitizer: heap-use-after-free vm_method.c:699 in rb_vm_ci_lookup ``` The same line also surfaces as `heap-buffer-overflow`. Original CI `[BUG]` (Ruby 4.0.4, x86_64-linux), same path: ``` [BUG] Segmentation fault vm_ci_hash <- rb_st_update <- rb_vm_ci_lookup (vm_method.c:712) <- vm_ci_new_runtime_ <- vm_search_super_method Total ractor count: 5 ``` ## Notes - ThreadSanitizer reports nothing — it cannot follow the M:N scheduler. - Both ASAN stacks show `thread T0` because the M:N scheduler multiplexes Ractors onto native threads; the run uses 3 Ractors. - The free path is a plain GC sweep (`gc_sweep_plane` → `rb_data_free`), no finalizer. ## Related issues - #21200 — parallel Ractor spurious segfault/hang; root cause unidentified. Possibly the same class of bug. - #21204 — same class of heap corruption, but scoped to MMTk GC. This report reproduces it on the **default GC**. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125555] [Ruby Bug#22077] Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour
by jerome.paul＠gmail.com (Jerome Paul) 21 May '26

21 May '26

Issue #22077 has been reported by jerome.paul(a)gmail.com (Jerome Paul). ---------------------------------------- Bug #22077: Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour https://bugs.ruby-lang.org/issues/22077 * Author: jerome.paul(a)gmail.com (Jerome Paul) * Status: Open * ruby -v: 3.4.x * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless => "please stop" irb(main):003> ``` ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless (irb):1:in 'Object#endless': surprise (RuntimeError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Kernel#load' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Gem.activate_and_load_bin_path' from /home/jerome/.rbenv/versions/4.0.3/bin/irb:25:in '<main>' (irb):1:in 'Object#endless': undefined method '*' for nil (NoMethodError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'Kernel#eval' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'IRB::WorkSpace#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:591:in 'IRB::Context#evaluate_expression' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:557:in 'IRB::Context#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:202:in 'block (2 levels) in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:521:in 'IRB::Irb#signal_status' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:194:in 'block in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:281:in 'block in IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'Kernel#loop' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:193:in 'IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:174:in 'block in IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'Kernel#catch' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:54:in 'IRB.start' ... 4 levels... ``` `ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux]` shows the same behaviour as 4.0.3. Being honest I don't think endless methods should allow for endless rescues! So the behaviour since at least 3.4.3 is IMO close to correct however instead of a runtime error I would expect a SyntaxError. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125551] [Ruby Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 20 May '26

20 May '26

Issue #16012 has been updated by Eregon (Benoit Daloze). That's great! ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-117376 * Author: MSP-Greg (Greg L) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124594] [Ruby Bug#21844] Inconsistent ArgumentError message for Data::define.new
by jnchito (Junichi Ito) 20 May '26

20 May '26

Issue #21844 has been reported by jnchito (Junichi Ito). ---------------------------------------- Bug #21844: Inconsistent ArgumentError message for Data::define.new https://bugs.ruby-lang.org/issues/21844 * Author: jnchito (Junichi Ito) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The code below shows `Data::define.new` treats symbol and string keys equivalently: ``` ruby C = Data.define(:a, :b) C.new(a: 1, b: 1) #=> #<data C a=1, b=1> C.new('a' => 1, 'b' => 1) #=> #<data C a=1, b=1> ``` But it acts differently when detecting missing keywords: ```ruby C.new(a: 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) C.new('a' => 1) #=> 'Data#initialize': missing keywords: :a, :b (ArgumentError) ``` I feel it should work like this: ```ruby C.new('a' => 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) ``` I created a PR to fix it: https://github.com/ruby/ruby/pull/15910 -- https://bugs.ruby-lang.org/

6 14

[ruby-core:125547] [Ruby Feature#16012] Add a (small) test-install suite?
by hsbt (Hiroshi SHIBATA) 20 May '26

20 May '26

Issue #16012 has been updated by hsbt (Hiroshi SHIBATA). I migrated snapshot package tests from ruby/actions to ruby/ruby repository. Now we test `make install` every pull reqeust with Linux, macOS and Windows. https://github.com/ruby/ruby/blob/master/.github/workflows/tarball-ubuntu.y… ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-117371 * Author: MSP-Greg (Greg L) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125428] [Ruby Bug#22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope
by jeremyevans0 (Jeremy Evans) 20 May '26

20 May '26

Issue #22058 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22058: {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope https://bugs.ruby-lang.org/issues/22058 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found that Method#super_method and InstanceMethod#super_method do not work correctly in some cases for refined methods. At the least, there is a definite bug, which is that #super_method inside a scope with a refinement activated for the method results in a loop over the refined methods. I'm not sure if the semantics for #super_method for refined methods were ever discussed. Other than the bug regarding the loop over the refinement, the currently semantics seem to be: * While handling additional refined methods for the same class as the current method, #super_method will consider the refinements active at the point the method was created * For ancestors, #super_method will consider the refinements active in the scope calling #super_method These semantics seem questionable. My guess is they are not the result of intentional design, but due purely to implementation details. I see two possibilities: 1. Keep the current behavior, where results depend on refinements activated in the caller's namespace. In this case, I recommend that we not have different handling when there are other refinements for the same class as the current method should. If refinements are not in scope, #super_method should not return them. We should also consider whether #super_method should error if the receiver is a refinement method for a refinement not activated in the caller's scope. 2. Change #super_method so that it depends on the refinements activated in the namespace it was created in, for ancestors as well as for the current class. This would make #super_method return the same result no matter where it was called. I think option 2 makes more sense, but it requires that Method/InstanceMethod objects for refined methods keep a reference to the scope in which they were created. A related minor bug I found during this research is the #inspect output for #super_method results for refined methods also does not use the same format, indicating there is something internally different. Here's example code showing these issues, with commented output below: ```ruby class B def b = 16 end class A < B def b = 8 + super end module M1 refine(A){def b = 1 + super} end module M2 refine(A){def b = 2 + super} end module M3 refine(A){def b = 4 + super} end module M4 refine(B){def b = 4 + super} end I = A.new.method(:b) C = A.instance_method(:b) module N0 using M1 using M3 I = A.new.method(:b) C = A.instance_method(:b) end module N using M1 using M2 using M3 using M4 I = A.new.method(:b) C = A.instance_method(:b) puts "", "Inside module using all refinements using method created using all refinements:" p I i = I 6.times do i = i.super_method p i end puts p C c = C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using some refinements:" p N0::I i = N0::I 6.times do i = i.super_method p i end puts p N0::C c = N0::C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using no refinements:" p ::I i = ::I 6.times do break unless i = i.super_method p i end puts p ::C c = ::C 6.times do break unless c = c.super_method p c end end module N0 using M1 using M3 puts "", "Inside module using some refinements using method created using all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end end puts "", "Top level using method created with all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with some refinements:" p N0::I i = N0::I 6.times do break unless i = i.super_method p i end puts p N0::C c = N0::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with no refinements:" p I i = I 6.times do break unless i = i.super_method p i end puts p C c = C 6.times do break unless c = c.super_method p c end ``` First, the bug. This shows a loop among active refinements. After going through M3, M2, and M1, it loops back to M3. This also shows weird #inspect output, with #super_method not showing the main class. ``` Inside module using all refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> ``` This shows the dynamic scoping of the #super_method. At time of call, only M3 and M1 are in scope. You see in the first loop, only M3 and M1 are used, but subsequent loops use M3, M2, and M1. ``` Inside module using all refinements using method created using some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> ``` This shows a case where the Method was created with no refinements activated. Refinements for superclasses that are active in the current scope are still picked up: ``` Inside module using all refinements using method created using no refinements: #<Method: A#b() t/t43.rb:30> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> ``` More evidence for dynamic scoping. This is the opposite of the second example, where the first loop has M3, M2, and M1, and subsequent loops have M3 and M1. ``` Inside module using some refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> ``` This shows the behavior when no refinements are activated in the current scope. It still includes refinements for the same class as the current method, but no refinements for superclasses. Also, note that there is no longer a loop, because there are no refinements activated: ``` Top level using method created with all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This shows that only the refinements were activated at the point the method was created are included. ``` Top level using method created with some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This output doesn't show any problems, it shows that if refinements were not activated when the method was created, and are not activated when #super_method is called, that #super_method ignores refinements, which is what you would expect. ``` Top level using method created with no refinements: #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` -- https://bugs.ruby-lang.org/

4 13