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

[ruby-core:124888] [Ruby Bug#21927] Prism: misleading error message for forwarding in lambda argument
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21927 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21927: Prism: misleading error message for forwarding in lambda argument https://bugs.ruby-lang.org/issues/21927 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * ruby -v: d256629bf9 * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Even in a forwarding method: ```console $ ruby --parser=prism -e 'def m(...) ->(...){}; end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m(...) ->(...){}; end | ^~~ unexpected ... when the parent method is not forwarding ``` This message is proper for method arguments: ```console $ ruby --parser=prism -e 'def m() p(...); end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m() p(...); end | ^~~ unexpected ... when the parent method is not forwarding ``` The message from parse.y is different; "unexpected ... in lambda argument": ```console $ ruby --parser=parse.y -e 'def m(...) ->(...){}; end' -e:1: unexpected ... in lambda argument def m(...) ->(...){}; end ruby: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 07 Jun '26

07 Jun '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 07 Jun '26

07 Jun '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124474] [Ruby Bug#21831] Prism doesn't count underscores in the fraction part of rational float
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21831 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21831: Prism doesn't count underscores in the fraction part of rational float https://bugs.ruby-lang.org/issues/21831 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Good. ```console $ ruby3.3 -e 'p 0.1_2r.to_f' 0.12 $ ruby3.4 --parser=parse.y -e 'p 0.1_2r.to_f' 0.12 ``` Wrong. ```console $ ruby3.4 -e 'p 0.1_2r.to_f' 0.012 ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125083] [Ruby Misc#21960] Improve #backtrace to not confuse terminals
by svoop (Sven Schwyn) 05 Jun '26

05 Jun '26

Issue #21960 has been reported by svoop (Sven Schwyn). ---------------------------------------- Misc #21960: Improve #backtrace to not confuse terminals https://bugs.ruby-lang.org/issues/21960 * Author: svoop (Sven Schwyn) * Status: Open ---------------------------------------- The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case `/path/to/whatever.rb:8:in`. This is then used as an argument to `open` (on macOS) which will not work due to the `:in` part. There are two ways to improve this: ## Replace the colon with a space Given the existence of `#backtrace_locations` which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the `#backtrace` to look like this: ``` /path/to/whatever.rb:8 in `/' /path/to/whatever.rb:8 in `show' (...) ^^^ space instead of colon ``` ## Add OCS 8 sequences [OCS 8](https://github.com/Alhadis/OSC8-Adoption) are the `<a>` tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:125099] [Ruby Bug#21961] Marshal.load freeze option fail to free linked strings
by byroot (Jean Boussier) 23 May '26

23 May '26

Issue #21961 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21961: Marshal.load freeze option fail to free linked strings https://bugs.ruby-lang.org/issues/21961 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- ```ruby str = "test" arr = [str, str] strings = Marshal.load(Marshal.dump(arr), freeze: true) p strings.map(&:frozen?) # => [true, false] ``` Expected: `[true, true]` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125078] [Ruby Bug#21959] rb_internal_thread_event_hooks_rw_lock is not reinitialized after fork causing deadlocks
by anmarchenko_datadog (Andrey Marchenko) 23 May '26

23 May '26

Issue #21959 has been reported by anmarchenko_datadog (Andrey Marchenko). ---------------------------------------- Bug #21959: rb_internal_thread_event_hooks_rw_lock is not reinitialized after fork causing deadlocks https://bugs.ruby-lang.org/issues/21959 * Author: anmarchenko_datadog (Andrey Marchenko) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby's GVL Instrumentation API uses a read-write lock (rb_internal_thread_event_hooks_rw_lock) to protect the list of thread event hooks: - Read lock — acquired on every GVL transition to iterate and call hook callbacks (rb_thread_execute_hooks) - Write lock — acquired when adding/removing hooks (rb_internal_thread_add_event_hook, rb_internal_thread_remove_event_hook) After fork(), Ruby reinitializes several internal locks (e.g. vm->ractor.sched.lock, timer_th.waiting_lock), but not rb_internal_thread_event_hooks_rw_lock. This wasn't added with the GVL Instrumentation API. The full reproducer is available here: https://github.com/anmarchenko/ruby-locks-fork-bug ## Deadlock sequence 1. Parent process has thread event hooks registered (e.g. by a profiler like dd-trace-rb) 2. Multiple threads run concurrently, causing GVL transitions — each transition acquires a read lock on the rwlock 3. fork() happens while a thread holds the read lock 4. In the child, only the forking thread survives — the thread that held the lock is gone, but the lock state is copied as-is 5. Child tries to add or remove a hook → needs write lock → blocks forever on a lock that will never be released 6. Deadlock ## Impact This affects any Ruby C extension using the GVL Instrumentation API in combination with fork-based servers (Resque, Unicorn, Passenger, etc.). The original report comes from dd-trace-rb's profiler deadlocking Resque workers on Alpine Linux (musl libc): https://github.com/DataDog/dd-trace-rb/issues/4967 -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124887] [Ruby Bug#21926] Thread#value on popen3 wait thread hangs in finalizer
by stevecrozz (Stephen Crosby) 23 May '26

23 May '26

Issue #21926 has been reported by stevecrozz (Stephen Crosby). ---------------------------------------- Bug #21926: Thread#value on popen3 wait thread hangs in finalizer https://bugs.ruby-lang.org/issues/21926 * Author: stevecrozz (Stephen Crosby) * Status: Open * ruby -v: 3.3.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Calling Thread#value on an Open3.popen3 wait thread from a finalizer completes in Ruby 3.2 but hangs in Ruby 3.3+. See repro.rb below. When the Ruby process hangs in these conditions, it no longer responds to signals and it seems to be unable to run any other threads. This affects the schmooze gem (and potentially other code using Open3.popen3 with finalizers), causing test suites to hang intermittently. ``` ruby # repro.rb require 'open3' class ProcessWrapper def initialize @stdin, @stdout, @stderr, @wait_thread = Open3.popen3("cat") ObjectSpace.define_finalizer(self, self.class.make_finalizer(@stdin, @stdout, @stderr, @wait_thread)) end def self.make_finalizer(stdin, stdout, stderr, wait_thread) proc do stdin.close rescue nil stdout.close rescue nil stderr.close rescue nil wait_thread.value # Hangs here in Ruby 3.3+ end end end 100.times { ProcessWrapper.new } GC.stress = true 1000.times { Object.new } puts "done" ``` ## Environment - Linux x86_64 - Tested on Ruby 3.2.7, 3.3.7, 3.4.8 -- https://bugs.ruby-lang.org/

5 5

[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:124286] [Ruby Bug#21789] `IO#flush` doesn't invoke fiber scheduler io_write hook
by noteflakes (Sharon Rosner) 15 May '26

15 May '26

Issue #21789 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #21789: `IO#flush` doesn't invoke fiber scheduler io_write hook https://bugs.ruby-lang.org/issues/21789 * Author: noteflakes (Sharon Rosner) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When calling `IO#flush` or closing an IO with unflushed writes, the flushing is done by calling `rb_io_blocking_region_wait` and eventually doing a `write` system call. When done in a non-blocking fiber with an active fiber scheduler, this will invoke the `#blocking_operation_wait` fiber scheduler hook, which will run the system call in a worker thread, and therefore the flushing bypasses the async I/O capabilities of the fiber scheduler. The proposed fix is to test for the presence of a fiber scheduler in `io_flush_buffer_async` and invoke the `#io_write` fiber scheduler hook with the unflushed part of the IO's write buffer. Associated PR here: https://github.com/ruby/ruby/pull/15609 -- https://bugs.ruby-lang.org/

2 1