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

[ruby-core:115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure
by vo.x (Vit Ondruch) 03 Aug '26

03 Aug '26

Issue #19921 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19921: TestYJIT#test_bug_19316 test failure https://bugs.ruby-lang.org/issues/19921 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master 52709a4862) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing with 52709a4862 on Fedora Rawhide, I observe following failure: ~~~ 94) Failure: TestYJIT#test_bug_19316 [/builddir/build/BUILD/ruby-3.3.0-52709a4862/test/ruby/test_yjit.rb:1126]: Expected no exits, but got {:opt_and=>1} ~~~ -- https://bugs.ruby-lang.org/

6 21

[ruby-core:123776] [Ruby Bug#21682] The result of IO#pos is inconsistent after using IO#ungetc.
by YO4 (Yoshinao Muramatsu) 31 Jul '26

31 Jul '26

Issue #21682 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21682: The result of IO#pos is inconsistent after using IO#ungetc. https://bugs.ruby-lang.org/issues/21682 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In this issue, I propose modifying `IO#ungetc` to never change the file position and explain the reasons for this change. The file location after using IO#ungetc may or may not change. This behavior is not documented. Since there are cases that the file position cannot be modified, I propose to unify the behavior so that the file position is not changed. ## Motivation Ensure file position behavior is independent of I/O setup. Avoid excessive exposure of implementation details. ## Current Details The file position after using IO#ungetc depends on the following conditions: When encoding conversion is not used: It changes. When encoding conversion is used: It does not change. This corresponds internally to whether the ungetc character is stored in the IO object's rbuf or cbuf. When using cbuf, the byte count of a character in cbuf may differ from its byte count in rbuf, making conversion from cbuf byte count to rbuf byte count potentially complex. Furthermore, even if one reverse-converts a character in cbuf to calculate its byte count in rbuf, the practical significance of this calculation is questionable. Therefore, it appears that adjusting the buffered byte count from the actual file position to calculate the file position in Ruby when a character exists in cbuf is not implemented. When stored in rbuf, its byte count can be used to calculate the file position, so the file position moves due to ungetc. ## Problems It seems relatively unknown that the side effects of ungetc can change depending on I/O setup. The Ruby community doesn't seem to discuss avoiding the use of file positions after ungetc. Behavior changing under little-known conditions reduces test coverage and leaves potential bugs. On Windows, files opened in "r" mode perform CRLF conversion but operate without encoding conversion, delegating conversion to the C runtime library (CRT). This is primarily for speed, but it modifies IO state in various places within io.c, reducing readability. It has also caused numerous bugs related to file position. Unfortunately, in Windows, "r" and "rt" are not equivalent depending on whether encoding conversion is used or not. This means the behavior of ungetc cannot be predicted within the context of 'text mode'. I'm working personally on switching to use encoding conversion instead of CRT read(), which means encoding conversion will be used for files opened with "r". This change will alter the behavior of ungetc. This impact occurs because implementation details are being exposed excessively, which is undesirable. ## Changes and Impact IO#ungetc will no longer change the file position. This affects not only IO#pos, but also implicitly impacts the file position when writing after ungetc. TestIO#test_copy_stream_dst_rbuf depends on this behavior. Changing the behavior of IO#ungetbyte is outside the scope of this issue. Changing it caused many tests to fail, but the details have not been investigated. Since IO#ungetbyte changes the file position while IO#ungetc does not, mixing their use is no longer possible. This means that performing ungetbyte after unetc before reading the entire data will cause an exception. /test/ruby/test_io.rb fails due to the above implicit dependency, and /spec/ruby/core/io/ungetc_spec.rb fails due to a test explicitly checking IO#pos. I have no idea about investigating the impact of real-world usage. ## Another approach Do not modify Ruby's behavior. Instead, document that the file position after using IO#ungetc cannot be trusted. Alternatively, it might be possible to issue a warning during specific operations when characters from IO#ungetc remain pending. In these cases, when Windows is switched to use encoding conversion for "r", io_unread() and rb_io_tell() will also take into account the number of bytes in cbuf in addition to rbuf to maintain compatibility. I prefer to minimize code for specific environments, so this is not to my ideal. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:112045] [Ruby master Bug#19378] Windows: Use less syscalls for faster require of big gems
by aidog (Andi Idogawa) 27 Jul '26

27 Jul '26

Issue #19378 has been reported by aidog (Andi Idogawa). ---------------------------------------- Bug #19378: Windows: Use less syscalls for faster require of big gems https://bugs.ruby-lang.org/issues/19378 * Author: aidog (Andi Idogawa) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello 🙂 ## Problem require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby. ## Possible Reason As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times. ## Testfile C:\tmp\speedtest\testrequire.rb: ``` ruby require __dir__ + "/helloworld1.rb" require __dir__ + "/helloworld2.rb" ``` ``` shell ruby --disable-gems C:\tmp\speedtest\testrequire.rb ``` ### Syscalls per File/Directory: 1. CreateFile 2. QueryInformationVolume 3. QueryIdInformation 4. QueryAllInformationFile 5. QueryNameInformationFile 6. QueryNameInformationFile 7. QueryNormalizedNameInformationFile 8. CloseFile ### Files/Directories checked 1. C:\tmp 2. C:\tmp\speedtest 3. C:\tmp\speedtest\helloworld1.rb 4. C:\tmp 5. C:\tmp\speedtest 6. C:\tmp\speedtest\helloworld2.rb For two required files Ruby had to do 8*6 = **48** syscalls. The syscalls orginate from rb_w32_reparse_symlink_p / lstat Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb" Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls. The result for the syscalls don't change in such a short time, so it should be possible to cache it. With require_relative it's twice as many calls. ## Other testcases Same result: ``` ruby File.realpath __dir__ + "/helloworld1.rb" File.realpath __dir__ + "/helloworld2.rb" ``` ``` ruby File.stat __dir__ + "/helloworld1.rb" File.stat __dir__ + "/helloworld2.rb" ``` It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb") ## Request Would it be possible to cache the stat calls when using require? I tried to implement a cache inside the ruby source code, but failed. If not, is there now a way to combine ruby files into one? I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11) ## How to reproduce Ruby versions: At least 3.0+, most likely older ones too. Tested using Ruby Installer 3.1 and 3.2. [Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc… -- https://bugs.ruby-lang.org/

6 9

[ruby-core:124616] [Ruby Bug#21848] GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete
by henrik (Henrik A) 27 Jul '26

27 Jul '26

Issue #21848 has been reported by henrik (Henrik A). ---------------------------------------- Bug #21848: GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete https://bugs.ruby-lang.org/issues/21848 * Author: henrik (Henrik A) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.1 freezes with 100% CPU usage when garbage collection runs during Rails code reloading (hot reload in development). The process becomes unresponsive and requires kill -9 to terminate. Environment: - Ruby: 4.0.1 (Homebrew, ARM64) - Platform: macOS 15.6.1 (Darwin 24.6.0, Apple Silicon) - Rails: 8.x with Puma 7.2.0 - Mode: Development with code reloading enabled Steps to reproduce: 1. Run a Rails application with Puma in development mode (bundle exec rails server -e development -b 0.0.0.0) 2. Make a several code change to trigger hot reload, reload the site in the browser in between 3. Process freezes with ~100% CPU Expected behavior: Code reloads successfully, GC completes normally. Actual behavior: Process freezes indefinitely at 100% CPU. Stack trace from sample shows GC stuck in hash table lookup while freeing VM call info: ``` gc_sweep (in libruby.4.0.dylib) gc_compact_plane gc_sweep_page gc_sweep_plane rb_gc_obj_free_vm_weak_references rb_vm_ci_free st_general_delete find_table_bin_ind vm_ci_hash_cmp <-- stuck here, spinning ``` Full relevant stack (Puma worker thread): ``` Thread: puma srv tp 005 rb_ary_each -> rb_yield -> invoke_block_from_c_bh -> rb_vm_exec -> int_upto -> rb_yield (nested loops) -> vm_search_method_slowpath0 -> rb_vm_search_method_slowpath -> newobj_of -> newobj_cache_miss -> gc_continue -> gc_sweep -> gc_compact_plane -> gc_sweep_page -> gc_sweep_plane -> rb_gc_obj_free_vm_weak_references -> rb_vm_ci_free -> st_general_delete -> find_table_bin_ind -> vm_ci_hash_cmp ``` Workaround: Disabling auto-compaction prevents the freeze: GC.auto_compact = false Analysis: The freeze occurs during GC sweep/compaction when freeing cached VM call info entries (rb_vm_ci_free). This is triggered by code reloading which invalidates method caches. The GC appears to get stuck in an infinite loop or extremely slow operation in find_table_bin_ind while looking up entries in the call info hash table. ---Files-------------------------------- rails_stuck.txt (159 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 25 Jul '26

25 Jul '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 19

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 23 Jul '26

23 Jul '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:115018] [Ruby master Bug#19922] ObjectSpace.dump_all in multiple threads in parallel causes SEGV
by wanabe (_ wanabe) 20 Jul '26

20 Jul '26

Issue #19922 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #19922: ObjectSpace.dump_all in multiple threads in parallel causes SEGV https://bugs.ruby-lang.org/issues/19922 * Author: wanabe (_ wanabe) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `ObjectSpace.dump_all` in multiple threads in parallel causes SEGV. The reproduce code is here: ``` $ ruby -robjspace -e 'def dump; 10.times { ObjectSpace.dump_all } end; Thread.new { dump }; dump' /home/wanabe/.rbenv/versions/master/lib/ruby/3.3.0+0/objspace.rb:100: [BUG] Segmentation fault at 0x0000000000000000 (snip) ``` I attached the full log. I assumed that: - Thread1 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd1 - calls `dump_flush()` - changes current thread due to IO - Thread2 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd2 - calls `dump_flush()` - changes current thread due to IO - Thread1 - gets unexpected `GET_RACTOR()->mfd`: mfd2 ---Files-------------------------------- bug.log (23.1 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:125045] [Ruby Bug#21955] `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page`
by ioquatix (Samuel Williams) 15 Jul '26

15 Jul '26

Issue #21955 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21955: `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page` https://bugs.ruby-lang.org/issues/21955 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a fiber terminates (falls off the end of its block, or raises an unhandled exception) after being reached via `Fiber#transfer`, its machine stack is **not** returned to the fiber pool. The stack is only freed when the `Fiber` object is eventually garbage collected. In production, where GC does not run continuously, terminated fibers accumulate unreleased stacks. Each stack allocation contains a guard page set with `mprotect(PROT_NONE)`, which splits a kernel VMA. On Linux this exhausts the per-process `vm.max_map_count` limit and raises: ``` FiberError: can't set a guard page: Cannot allocate memory ``` The symptom is confusing: the fibers are all dead (`alive? == false`), new fibers cannot be created, but GC has not run. ## Root cause In `cont.c`, `fiber_switch()`, the eager stack release after `fiber_store` returns is guarded by `resuming_fiber`: ```c // cont.c (affected versions) #ifndef COROUTINE_PTHREAD_CONTEXT if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` `resuming_fiber` is only non-`NULL` when the switch was initiated by `Fiber#resume` (which passes `resuming_fiber = fiber`). `Fiber#transfer` passes `resuming_fiber = NULL`, so the condition is never true and the stack is silently leaked until GC. Additionally, `fiber_raise` on a suspended non-yielding (transferred) fiber calls `fiber_transfer_kw`, also passing `resuming_fiber = NULL`, so the same leak occurs when a transferred fiber is terminated by a raised exception. ## Reproduction Set a low map count limit, then run the attached script: ``` sudo bash -c "echo 10000 > /proc/sys/vm/max_map_count" ruby test_fiber_transfer_leak.rb ``` Restore afterwards (`sysctl vm.max_map_count` shows the default, typically 65530). ```ruby GC.disable leaked = [] count = 0 begin 10_000.times do f = Fiber.new { } # terminates immediately leaked << f # hold reference so Fiber object is not GC'd f.transfer # transfer, not resume => stack NOT released (bug) count += 1 puts "[#{count} fibers] all dead: #{leaked.none?(&:alive?)}" if count % 1000 == 0 end puts "No error — fix is applied." rescue FiberError => e puts "FiberError after #{count} fibers: #{e.message}" puts "All terminated (alive?=false): #{leaked.none?(&:alive?)}" ensure GC.enable leaked.clear GC.start end ``` Expected output on **unpatched** Ruby (vm.max_map_count=10000): ``` [1000 fibers] all dead: true [2000 fibers] all dead: true [3000 fibers] all dead: true [4000 fibers] all dead: true FiberError after 4096 fibers: can't set a guard page: Cannot allocate memory All terminated (alive?=false): false ``` Expected output on **patched** Ruby: ``` [1000 fibers] all dead: true ... [10000 fibers] all dead: true No error — fix is applied. ``` ## Fix Drop the `resuming_fiber &&` guard. After `fiber_store` returns we are executing in the caller's context — we are never on `fiber`'s stack — so releasing it is unconditionally safe. `fiber_stack_release` is already idempotent (guarded by `fiber->stack.base == NULL`), so the resume path is unaffected. ```c #ifndef COROUTINE_PTHREAD_CONTEXT if (FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` Pull request with fix: https://github.com/ruby/ruby/pull/16416 -- https://bugs.ruby-lang.org/

4 3

[ruby-core:113743] [Ruby master Feature#19708] Support `attr_reader :foo?`
by AMomchilov (Alexander Momchilov) 13 Jul '26

13 Jul '26

Issue #19708 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #19708: Support `attr_reader :foo?` https://bugs.ruby-lang.org/issues/19708 * Author: AMomchilov (Alexander Momchilov) * Status: Open * Priority: Normal ---------------------------------------- Creating reader methods with `attr_reader` is preferable over defining them by hand, not only because it's more convenient, but also because it hits a fast path in MRI (see `VM_METHOD_TYPE_IVAR`). Since local and instance variables can't end with `?`, you can't use `attr_reader` to define predicate-style methods for boolean values, like: ```ruby class Person attr_reader(:name, :age, :active?) # invalid attribute name `active?' (NameError) def initialize @name = "Bob" @age = 30 @active = true end end ``` It would be nice if `attr_reader` (and friends) could behave like: ```ruby def active? = @active ``` (`attr_writer` and `attr_accessor` couldn't do the same, since `def active?=(new_value)` isn't valid, so they'd probably stick with `def active=(new_value)`) -- https://bugs.ruby-lang.org/

5 7

[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) 11 Jul '26

11 Jul '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 15