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

[ruby-core:124848] [Ruby Bug#21917] Unable to build 4.0.1 on AIX 7.2
by mhashizume (Michael Hashizume) 16 Mar '26

16 Mar '26

Issue #21917 has been reported by mhashizume (Michael Hashizume). ---------------------------------------- Bug #21917: Unable to build 4.0.1 on AIX 7.2 https://bugs.ruby-lang.org/issues/21917 * Author: mhashizume (Michael Hashizume) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm attempting to build Ruby 4.0.1 on AIX 7.2. We have had successful builds of previous versions of Ruby on this platform, but are starting to see an issue when using miniruby to build Ruby: ``` shell ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./powerpc64-aix7.2.0.0-fake ./tool/rbinstall.rb --make="gmake" --dest-dir="" --extout=".ext" --ext-build-dir="./ext" --mflags="-j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --make-flags=" -j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --data-mode=0644 --prog-mode=0755 --installed-list .installed.list --mantype="man" --install=all --exclude=doc /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImplementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` I'm not sure where the NotImplementedError is coming from, and when looking at the `truss` output from miniruby, I see a ENOTTY when miniruby attempts to load monitor.so: ```shell accessx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0, 0) = 0 statx("/", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFA680, 176, 011) = 0 __ksetjmp(0x0000000110019F88, 0x09000000026845A8, 2, 0x000000011001A1D8, 0x0FFFFFFFFFFFB790, 0x0000000022242202, 0x000000011011A658, 0x09000 00000260348) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFB800, 176, 0) = 0 kioctl(2, 22528, 0x0000000000000000, 0x0000000000000000) Err#25 ENOTTY /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImpl ementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` monitor.so is present in the path that miniruby is looking for it. Any pointers on where to start debugging this further or what changes in more recent versions of Ruby could have caused this would be greatly appreciated. Thank you! -- https://bugs.ruby-lang.org/

3 4

[ruby-core:124443] [Ruby Bug#21828] An incorrect warning message related to `benchmark` is shown when using `benchmark-ips`
by y-yagi (Yuji Yaginuma) 16 Mar '26

16 Mar '26

Issue #21828 has been reported by y-yagi (Yuji Yaginuma). ---------------------------------------- Bug #21828: An incorrect warning message related to `benchmark` is shown when using `benchmark-ips` https://bugs.ruby-lang.org/issues/21828 * Author: y-yagi (Yuji Yaginuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Descrition When using `benchmark-ips` gem with Ruby 4.0.0, the warning related to `benchmark` gem is shown. ## Step to reproduce ```ruby # Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "benchmark-ips" ``` ```ruby # script.rb require "benchmark/ips" ``` ```text $ bundle exec ruby -v script.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] script.rb:1: warning: benchmark/ips is found in benchmark, which is not part of the default gems since Ruby 4.0.0. You can add benchmark to your Gemfile or gemspec to fix this error. ``` ## Expected behavior The warning for `benchmark` isn't shown when using `benchmark-ips`. -- https://bugs.ruby-lang.org/

4 13

[ruby-core:116589] [Ruby master Misc#20238] Use prism for mk_builtin_loader.rb
by kddnewton (Kevin Newton) 13 Mar '26

13 Mar '26

Issue #20238 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20238: Use prism for mk_builtin_loader.rb https://bugs.ruby-lang.org/issues/20238 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose that we use prism for mk_builtin_loader.rb. Right now the Ruby syntax that you can use in builtin classes is restricted to the base Ruby version (2.7). This means you can't use a lot of the nicer syntax that Ruby has shipped in the last couple of years. If we switch to using prism to parse the builtin files instead of using ripper, then we can always use the latest version of Ruby syntax. A pull request for this is here: https://github.com/kddnewton/ruby/pull/65. The approach for the PR is taken from how RJIT bindgen works. -- https://bugs.ruby-lang.org/

6 22

[ruby-core:123871] [Ruby Feature#21700] `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful
by trinistr (Alexander Bulancov) 11 Mar '26

11 Mar '26

Issue #21700 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Feature #21700: `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful https://bugs.ruby-lang.org/issues/21700 * Author: trinistr (Alexander Bulancov) * Status: Open ---------------------------------------- *This was supposed to be a bug report, but it turned into a feature request halfway through.* `IO::Buffer.map` supports `size` and `offset` arguments to localize buffer to a specific part of mapped file. While `size` works fine, specifying `offset` as anything but 0 is a recipe for disaster. 1. It is practically undocumented. This is it currently: "Optional size and offset of mapping can be specified." While `size` can be whatever user desires, `offset` can only be set to specific values. It was *very* surprising when I started testing it, as I expected it to behave similar to size and offset of a slice. Which values are allowed? That's the next point. 2. Possible values for `offset` are highly platform-dependent. - On Linux it must be a multiple of page size. (https://www.man7.org/linux/man-pages/man2/mmap.2.html) - On macOS it can be any value? manpage doesn't specify exactly. (https://developer.apple.com/library/archive/documentation/System/Conceptual… (I looked at the manpage on a mac, seems to be the same.)) - On Windows it must be a multiple of some value that *isn't* page size and page size doesn't work here. StackOverflow says it's 64 kB, but that didn't work for me. (See dwFileOffsetLow in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…) - On other systems? Who knows. 3. On macOS, a buffer successfully created with an offset crashes on read. I don't know why, it's exactly the same file, size and offset that works on Ubuntu, and the read is bounded. 4. Currently, offset doesn't change the buffer's size if unspecified, leading to crashes. I will be making a PR addressing this but still. 5. All of this makes offset unpractical to test, leading to all kinds of problems. So the problem is: this argument is a very low-level detail that requires significant knowledge of all platforms your code may be ever deployed to, even if strictly Ruby is used (no C API), with unexpectedly high footgun potential. I understand that IO::Buffer is a lower-level class, but this seems too much. I propose to make `offset` argument into a convenience for users, allowing any reasonable value (i.e inside the file). Behind the scenes, we can use the native offset for efficieny, on platforms where it works well, but the user API would be decoupled from this. However, I'm not particularly familiar with Ruby internals, so I can't tell how viable this is. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124804] [Ruby Bug#21876] Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts
by nbeyer＠gmail.com (Nathan Beyer) 09 Mar '26

09 Mar '26

Issue #21876 has been reported by nbeyer(a)gmail.com (Nathan Beyer). ---------------------------------------- Bug #21876: Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts https://bugs.ruby-lang.org/issues/21876 * Author: nbeyer(a)gmail.com (Nathan Beyer) * Status: Open * ruby -v: ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On macOS, `Addrinfo.getaddrinfo(host, service, Socket::AF_UNSPEC, Socket::SOCK_STREAM)` can deadlock in forked child processes when the host has no AAAA (IPv6) DNS records and the parent process previously resolved the same host. This happened to me when using an HTTP library to acquire an OAuth access token in a Rails initializer and then the process was forked, then a separate call was made to the same host in the forked process. ## Environment - macOS (tested on arm64-darwin24 and arm64-darwin25, Apple Silicon) - Ruby 3.4.7, 3.4.8 - The issue is probabilistic — frequency varies by environment but is highly reproducible under sustained DNS activity ## Reproduction Minimal example: ```ruby require "socket" require "timeout" # Parent resolves an IPv4-only host (no AAAA records) Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) pid = fork do begin Timeout.timeout(5) do Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) end puts "Child: OK" rescue Timeout::Error puts "Child: DEADLOCK — getaddrinfo hung for 5s" end end Process.waitpid(pid) ``` The issue is probabilistic — a single invocation may or may not deadlock. The attached script runs 50 trials each for several variants to demonstrate the pattern. Deadlock may not happen on the first run, but if you run it several times, you should see at least a single deadlock in Test 2, if not deadlock of all results in Test 1 and Test 2. See attachment - ruby_getaddrinfo_fork_bug.rb Typical output: ``` Test 1 (single IPv4-only host): 20/20 deadlocked Test 2 (multi-host warmup): 20/20 deadlocked Test 3 (dual-stack host control): 0/20 deadlocked Test 4 (AF_INET workaround): 0/20 deadlocked ``` ## Context The deadlock occurs when ALL of these conditions hold: 1. **macOS** (not observed on Linux) 2. Parent called `getaddrinfo(host, AF_UNSPEC)` for a host with **no AAAA (IPv6) records** 3. Child calls `getaddrinfo` for the **same host** with `AF_UNSPEC` **Not affected:** - Hosts **with** AAAA records (dual-stack) — e.g., `www.google.com`, `rubygems.org` - Using `Socket::AF_INET` instead of `Socket::AF_UNSPEC` - Hosts the parent never resolved | Host | AAAA records | Child deadlocks? | |------|-------------|-----------------| | httpbin.org | None | **Yes** | | www.github.com | None | **Yes** | | api.github.com | None | **Yes** | | stackoverflow.com | None | **Yes** | | www.google.com | Yes | No | | rubygems.org | Yes | No | | example.com | Yes | No | | www.cloudflare.com | Yes | No | ## Potential Root Cause As I understand it, on macOS, `getaddrinfo` communicates with the `mDNSResponder` system daemon via Mach IPC ports. When `getaddrinfo(AF_UNSPEC)` queries a host with no AAAA records, the negative AAAA result appears to be cached via Mach port state. After `fork()`, the child process inherits the address space (including references to this cached state) but does **not** inherit the Mach port connections to `mDNSResponder`. When the child calls `getaddrinfo` for the same host, it encounters the stale cache entry and deadlocks trying to communicate over the invalidated Mach port. Hosts with positive AAAA results are not affected, presumably because their cache entries do not require re-contacting `mDNSResponder` in the same code path. ## Feature #20590 Ruby 3.4's fork safety improvements (Feature #20590) added a read-write lock around `getaddrinfo` to prevent `fork()` while a `getaddrinfo` call is actively running. However, this does not address the issue reported here — the problem is not about forking *during* a `getaddrinfo` call, but about stale mDNSResponder Mach port state that is inherited by the child process *after* `getaddrinfo` has completed in the parent. ---Files-------------------------------- ruby_getaddrinfo_fork_bug.rb (5.36 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123992] [Ruby Bug#21760] Ruby::Box: a couple of require-related problems
by zverok (Victor Shepelev) 09 Mar '26

09 Mar '26

Issue #21760 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21760: Ruby::Box: a couple of require-related problems https://bugs.ruby-lang.org/issues/21760 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: 4.0.0dev (2025-12-03T05:16:03Z master 4762f429f4) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am not sure whether all the problems have the same nature, but putting them together for now. **1. Enabling box breaks `gem`+`require`** Minimal reproducible example: `test.rb`: ```ruby gem 'faraday', '= 2.14.0' require 'faraday' p Faraday::VERSION ``` (Note that there is no explicit use of `Ruby::Box`) Running it with and without `RUBY_BOX`: ```sh $ ruby test.rb "2.14.0" $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' ``` (sic, the error is printed twice) **2. requiring the same gem from `Box`-loaded file and the main file** `box.rb`: ```ruby require 'faraday' p "In a box: #{Faraday::VERSION}" ``` `main.rb` ```ruby b = Ruby::Box.new b.load('box.rb') require 'faraday' ``` ```sh $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. "In a box: 2.14.0" main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' ``` **3. `Box#require` seem to not be aware of gems** In the example above, we see that Box-loaded file can require a gem. This also works: ```ruby b = Ruby::Box.new b.eval(<<~RUBY) require "faraday" p Faraday::VERSION RUBY ``` (prints "2.14.0" as expected) But this doesn't: ```ruby b = Ruby::Box.new b.require('faraday') ``` ```sh $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. test.rb:3:in 'Ruby::Box#require': cannot load such file -- faraday (LoadError) from test.rb:3:in '<main>' ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124741] [Ruby Bug#21873] `UnboundMethod#==` returns false for methods obtained via extend + unbind
by mdalessio (Mike Dalessio) 07 Mar '26

07 Mar '26

Issue #21873 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #21873: `UnboundMethod#==` returns false for methods obtained via extend + unbind https://bugs.ruby-lang.org/issues/21873 * Author: mdalessio (Mike Dalessio) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description `UnboundMethod#==` returns `false` when comparing a module's instance method against the same method obtained via `Method#unbind` on a class that includes or extends that module, despite having the same owner and source location. ```ruby module MyMethods def hello = "hello" end class Base extend MyMethods end from_module = MyMethods.instance_method(:hello) from_unbind = Base.method(:hello).unbind p from_module.owner == from_unbind.owner #=> true p from_module.source_location == from_unbind.source_location #=> true p from_module.inspect == from_unbind.inspect #=> true p from_module == from_unbind #=> false (expected true) ``` ## Diagnosis `method_eq` compares method entries using `method_entry_defined_class`. For methods mixed in via `include`/`extend`, the "defined class" will be an ICLASS and not the original class/module. In the example above, `method_eq` is comparing a module's ICLASS entry against the module, and that will always be false. Related: #18798 (fixed by @ko1 in 59e389af). -- https://bugs.ruby-lang.org/

6 6

[ruby-core:124673] [Ruby Bug#21860] Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup`
by byroot (Jean Boussier) 06 Mar '26

06 Mar '26

Issue #21860 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21860: Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup` https://bugs.ruby-lang.org/issues/21860 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We recently observed some deadlocked processes. These got deadlock during child initialization right after `Process.fork`. Based on the `gdb` session, the child is deadlocked in `threadptr_interrupt_exec_cleanup`, which suggest `th->interrupt_lock` was locked by another thread in the parent, and wasn't reinitialized in the children before calling `threadptr_interrupt_exec_cleanup`. ```c (gdb) bt 20 #0 0x0000ffff855a09c0 in __lll_lock_wait () from /lib64/libc.so.6 #1 0x0000ffff855a6d60 in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/libc.so.6 #2 0x0000aaaaaeec04c8 [PAC] in rb_native_mutex_lock (lock=<optimized out>) at /ruby-3.4.4/thread_pthread.c:116 #3 threadptr_interrupt_exec_cleanup (th=<optimized out>) at thread.c:6052 #4 thread_cleanup_func_before_exec (th_ptr=0xffff35803000) at thread.c:514 #5 thread_cleanup_func (atfork=1, th_ptr=0xffff35803000) at thread.c:524 #6 terminate_atfork_i (current_th=0xffff84e1e000, th=0xffff35803000) at thread.c:4769 #7 rb_thread_atfork_internal (atfork=<optimized out>, th=0xffff84e1e000) at thread.c:4736 #8 rb_thread_atfork () at thread.c:4779 #9 0x0000aaaaaee110fc [PAC] in after_fork_ruby (pid=0) at process.c:1693 #10 rb_fork_ruby (status=status@entry=0x0) at process.c:4253 #11 0x0000aaaaaee11154 [PAC] in proc_fork_pid () at process.c:4266 #12 rb_proc__fork (_obj=<optimized out>) at process.c:4313 #13 0x0000aaaaaeefeb7c [PAC] in vm_call_cfunc_with_frame_ (stack_bottom=0xffff84e7a1c8, argv=0xffff84e7a1d0, argc=0, calling=<optimized out>, reg_cfp=0xffff84f79150, ec=0xffff84e31050) at /ruby-3.4.4/vm_insnhelper.c:3794 #14 vm_call_cfunc_with_frame (ec=0xffff84e31050, reg_cfp=0xffff84f79150, calling=<optimized out>) at /ruby-3.4.4/vm_insnhelper.c:3840 #15 0x0000aaaaaef1aa44 [PAC] in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /ruby-3.4.4/vm_callinfo.h:415 #16 vm_exec_core (ec=0xffff84e31050) at /ruby-3.4.4/insns.def:1063 #17 0x0000aaaaaef0aa58 [PAC] in rb_vm_exec (ec=ec@entry=0xffff84e31050) at vm.c:2595 #18 0x0000aaaaaef0fe48 [PAC] in vm_call0_body (ec=ec@entry=0xffff84e31050, calling=calling@entry=0xffffea5a1e78, argv=argv@entry=0x0) at /ruby-3.4.4/vm_eval.c:225 #19 0x0000aaaaaef136e8 in vm_call0_cc (kw_splat=0, cc=0xfffeee654508, argv=<optimized out>, argc=0, id=27393, recv=281472906794680, ec=0xffff84e31050) at /ruby-3.4.4/vm_eval.c:101 ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124699] [Ruby Bug#21866] Backport Fix for integer overflow checks in enumerator
by rwstauner (Randy Stauner) 06 Mar '26

06 Mar '26

Issue #21866 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #21866: Backport Fix for integer overflow checks in enumerator https://bugs.ruby-lang.org/issues/21866 * Author: rwstauner (Randy Stauner) * Status: Open * Assignee: rwstauner (Randy Stauner) * Target version: 4.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- I would like to backport this PR https://github.com/ruby/ruby/pull/15829 that has already merged to master. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 06 Mar '26

06 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2