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

[ruby-core:126710] [Ruby Bug#22218] Line TracePoint misses executed loop condition after a guard
by k0kubun (Takashi Kokubun) 14 Sep '26

14 Sep '26

Issue #22218 has been updated by k0kubun (Takashi Kokubun). Backport changed from 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED to 3.3: REQUIRED, 3.4: DONE, 4.0: DONE ruby_4_0 commit:be08f56e6093e3733ccda80b3f3bfcb29c09b66d. ---------------------------------------- Bug #22218: Line TracePoint misses executed loop condition after a guard https://bugs.ruby-lang.org/issues/22218#change-119008 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: DONE, 4.0: DONE ---------------------------------------- `TracePoint.new(:line)` can miss the line event for an executed loop condition when the loop follows a conditional guard. This is related to [Bug #15980](https://bugs.ruby-lang.org/issues/15980), which fixed the same control-flow problem for line coverage. The coverage-specific workaround does not apply to ordinary line TracePoint consumers, so TracePoint and Coverage can still disagree. ## Affected versions This affects Ruby 3.3 and later. The behavior was reproduced on Ruby 3.4.4 and Ruby 4.0.5, both of which report `[1, 3]`. Ruby 3.3.0 through 3.3.11 retain the same coverage-only compiler guard; the source explicitly notes that the TracePoint line event does not occur. Ruby 4.1 development versions are also affected without the proposed patch. ## Reproduction ```ruby source = <<~RUBY raise if 1 == 2 while true break end RUBY lines = [] TracePoint.new(:line) do |trace| lines << trace.lineno if trace.path == "example.rb" end.enable do eval(source, binding, "example.rb") end p lines ``` ### Actual result ```ruby [1, 3] ``` ### Expected result ```ruby [1, 2, 3] ``` The same problem occurs with a non-constant predicate, for example: ```ruby def read return if @finished while chunk = super consume(chunk) end end ``` ## Cause Jump-to-jump peephole optimization retargets the conditional branch past the synthetic jump carrying the line event. As a result, execution reaches the loop body without visiting the event-bearing instruction. ## Proposed Fix The proposed fix is [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122). Ruby already stops this jump-to-jump optimization when line coverage is enabled and the skipped jump has event flags. The patch generalizes that existing guard: it skips this specific retargeting whenever the intermediate jump carries `RUBY_EVENT_LINE` or `RUBY_EVENT_COVERAGE_LINE`, regardless of whether coverage is active. Other jump-to-jump folding remains enabled. The change only retains the event-bearing jump that TracePoint must visit; it does not add trace-edge metadata or require new VM, YJIT, or ZJIT handling. This is the smaller alternative suggested in the discussion of [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825). ### Performance The retained jump costs one additional YARV dispatch when the interpreter traverses an affected edge. Performance-sensitive JIT execution can optimize away the extra control-flow overhead: YJIT emits no machine jump when it can place the target block next, while ZJIT cleans up the jump chain in its control-flow graph. The following results compare Ruby immediately before and after the patch on an Apple M4 Pro. Each result is the median of 9 or 11 samples after 3 warmups: | Targeted benchmark | Baseline | Patched | Change | |---|---:|---:|---:| | Hot affected edge, interpreter | 46.20 M iterations/s | 45.74 M iterations/s | -1.0% | | Minimal guarded reader, interpreter | 30.95 M calls/s | 30.13 M calls/s | -2.7% | | Minimal guarded reader, YJIT | 272.56 M calls/s | 272.56 M calls/s | 0.0% | | Minimal guarded reader, ZJIT | 435.34 M calls/s | 436.89 M calls/s | +0.4% | For a synthetic hot-edge benchmark, two long YJIT runs in opposite order varied between -0.5% and +0.4%, and ZJIT differed by +0.04%. There was therefore no repeatable JIT regression. The interpreter figures are deliberately concentrated worst cases where every iteration or call traverses the affected edge. ## Related work - Previous coverage issue: [Bug #15980](https://bugs.ruby-lang.org/issues/15980) - Earlier edge-metadata approach: [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825) - Selective peephole fix: [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126098] [Ruby Bug#22198] win32: heap overflow in Kernel#system
by mame (Yusuke Endoh) 14 Sep '26

14 Sep '26

Issue #22198 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22198: win32: heap overflow in Kernel#system https://bugs.ruby-lang.org/issues/22198 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: windows * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `system('foo.exe %A')` looks past `%A` for a closing `%`, reading past the end of the string. It does not reproduce normally, but with page heap enabled it faults: ``` PS C:\> gflags /p /enable ruby.exe /full PS C:\> ruby -e "system('x' * 1024 + '.exe %A')" -e:1: [BUG] Segmentation fault ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 l:y b:0001 CFUNC :system c:0002 p:0013 s:0006 e:000005 l:n b:---- EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001620 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'system' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007ffbd55000e4] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007ffbd274c11f] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_vm_bugreport+0x237) [0x00007ffb37262227] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_bug_for_fatal_signal+0x9b) [0x00007ffb37000beb] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_shape_free_all+0xfb5) [0x00007ffb37191985] C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007ffbd2fff2e4] [0x00007ff765e81080] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007ffbd550479f] *snip* ``` PR: https://github.com/ruby/ruby/pull/17929 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126038] [Ruby Bug#22190] Class#subclasses does not include clones of classes that include modules
by shugo (Shugo Maeda) 14 Sep '26

14 Sep '26

Issue #22190 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22190: Class#subclasses does not include clones of classes that include modules https://bugs.ruby-lang.org/issues/22190 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 4.0 * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Class#subclasses` does not return clones of classes that include (or prepend) a module, while clones of classes without modules are returned. This is a regression first released in Ruby 4.0.4. ```ruby module M; end class X; end class C < X include M end class D < X; end clone_c = C.clone clone_d = D.clone p clone_c.superclass #=> X p X.subclasses.include?(C) #=> true p X.subclasses.include?(clone_d) #=> true (D includes no module) p X.subclasses.include?(clone_c) #=> false (expected: true) ``` The same happens with `prepend` instead of `include`. Ruby 4.0.3 and earlier return `true` for all of the above. ## Analysis Since a2531ba293 ("Simplify subclasses list, remove from Box"), `class_associate_super()` maintains subclass lists only for direct T_CLASS -> T_CLASS links: ```c // class.c (master) // Only maintain subclass lists for T_CLASS→T_CLASS relationships. // Include/prepend inserts ICLASSes into the super chain, but T_CLASS // subclass lists should track only the immutable T_CLASS→T_CLASS link. if (RB_TYPE_P(klass, T_CLASS) && RB_TYPE_P(super, T_CLASS)) { ``` For normally created classes this is fine because the T_CLASS -> T_CLASS link is registered at class creation time, before any module is included. However, `rb_mod_init_copy()` builds the clone's superclass chain differently: * When the original has no origin, the clone shares the original's ICLASS chain: `rb_class_set_super(clone, RCLASS_SUPER(orig))` (class.c:983), where `RCLASS_SUPER(orig)` is a T_ICLASS. The condition above is false, so the clone is never added to the real superclass's subclass list. * When the original has an origin (prepend), the tail is connected via `rb_class_set_super(clone_origin, RCLASS_SUPER(orig_origin))` (class.c:1031), where `clone_origin` is a T_ICLASS, so this link is not registered either. Before a2531ba293, subclass entries were reparented onto ICLASSes and the `Class#subclasses` walk descended through non-T_CLASS entries (see `class_descendants_recursive` in 4.0.3), so a clone registered under the shared ICLASS was still found from the superclass. Method lookup and method cache invalidation do not seem to be affected (redefining a method on the superclass after cloning is observed correctly through the clone); the visible breakage is in the reflection API. Other users of the subclass lists may want checking, though (for example the allocator propagation added in 111215de27 also iterates subclass lists). -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126706] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by k0kubun (Takashi Kokubun) 14 Sep '26

14 Sep '26

Issue #11438 has been updated by k0kubun (Takashi Kokubun). Backport changed from 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED to 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ruby_4_0 commit:2ab382bd0a86b0012621ebcfbc8f68e91a432197. ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-119004 * Author: rickerliang (l ly) * Status: Closed * Assignee: windows * ruby -v: 2.2.2 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 14 Sep '26

14 Sep '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126676] [Ruby Bug#22310] parse.y rejects a variable binding that precedes an unrelated alternative pattern
by yuki300 (Yuki Hirota) 14 Sep '26

14 Sep '26

Issue #22310 has been reported by yuki300 (Yuki Hirota). ---------------------------------------- Bug #22310: parse.y rejects a variable binding that precedes an unrelated alternative pattern https://bugs.ruby-lang.org/issues/22310 * Author: yuki300 (Yuki Hirota) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `parse.y` rejects patterns in which a variable binding appears *before* an alternative pattern, even when the alternative itself binds nothing. Prism accepts the same code. Is this intended? ## Reproduction ```ruby # ok.rb case [:a, 1] in [ :a | :b, x ] end # ng.rb case [1, :a] in [ x, :a | :b ] end ``` ``` $ ruby --parser=parse.y -c ok.rb Syntax OK $ ruby --parser=parse.y -c ng.rb ng.rb:2: alternative pattern after variable capture (SyntaxError) $ ruby --parser=prism -c ng.rb Syntax OK ``` The two patterns are semantically identical; only the order of the array elements differs. Both files run without error under the default parser. ## Other forms rejected by parse.y (all accepted by Prism) ```ruby in { a: String => t, b: Integer | String } # binding, then alternative in { a: String => t, b: { c: Integer | String } } # alternative nested deeper in [ one, "a" | "b" => two ] # form reported in rails/bootsnap issue 539 in { access_token: String => token, expires_in: (Integer | String) => expires_in } # form shipped in the anthropic gem ``` Reversing the order makes them pass: ```ruby in { b: Integer | String, a: String => t } # Syntax OK ``` For contrast, a binding *inside* the alternation is rejected by both parsers on 4.0.4, as expected: ```ruby in [ x, :a | y ] # variable capture in alternative pattern (parse.y and Prism) ``` ## Why this looks unintended `:a | :b` and `Integer | String` bind no variables, so the documented restriction -- "Binding to variables currently does NOT work for alternative patterns joined with `|`" -- is not violated. Nothing can be left unbound. The check in `p_alt` tests `p->ctxt.capture_in_pattern`, which is set by any binding anywhere in the same `in` clause, not only by a binding on the left-hand side of the `|`: ```c p_alt : p_alt[left] '|'[alt] { p->ctxt.in_alt_pattern = 1; } p_expr_basic[right] { if (p->ctxt.capture_in_pattern) { yyerror1(&@alt, "alternative pattern after variable capture"); } ``` Prism instead visits the left-hand node when it reaches the `|` (`parse_pattern_alternation_error` in prism.c), so sibling bindings are not affected. The check was introduced in https://github.com/ruby/ruby/commit/f4b6a5191ceb0ed0cd7a3e3c8bab24cc0dd15736 ([Feature #21572]). The discussion in #21572 and in the dev meeting (https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeeting-2025-10…) only covers bindings *inside* an alternation, and `test/ruby/test_pattern_matching.rb` only asserts the passing order (`in [ :a | :b, x]`). The `p_alt` rule is unchanged on current master. ## Impact Not visible under the default parser. However, `RubyVM::InstructionSequence.compile_file` was routed to parse.y until [Bug #22023] was fixed, so bootsnap (which uses it to build its bytecode cache) made gems fail to load on Ruby 4.0.1-4.0.3 while `ruby foo.rb` worked. That path is fixed in 4.0.4 and worked around in bootsnap 1.24.2, but the parse.y check itself remains. ## Prior sightings The same rejection has been observed before and was each time attributed to the `compile_file` routing bug ([Bug #22023]): - https://github.com/rails/bootsnap/issues/539 (cause identified as https://github.com/ruby/ruby/pull/16463, later backported as #22023) - https://github.com/ruby/irb/issues/1212 ("in Ruby `4.0.2` `parse.y` has a bug, but the important part here is that this is using `parse.y`") - https://github.com/anthropics/anthropic-sdk-ruby/pull/192, whose author noticed that swapping the hash-pattern key order avoids the error As far as I can find, whether the parse.y check itself is correct has not been raised. ## Environment ``` ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] # rejects with --parser=parse.y ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] # same; also via compile_file ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin25] # parse.y accepts all of the above ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126699] [Ruby Bug#22314] parse.y does not check **rest bindings in patterns (duplicate / alternation)
by yuki300 (Yuki Hiro) 14 Sep '26

14 Sep '26

Issue #22314 has been reported by yuki300 (Yuki Hiro). ---------------------------------------- Bug #22314: parse.y does not check **rest bindings in patterns (duplicate / alternation) https://bugs.ruby-lang.org/issues/22314 * Author: yuki300 (Yuki Hiro) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `p_kwrest` is the only binding rule in patterns that does not go through `error_duplicate_pattern_variable`. `p_variable`, `p_rest` and the `{a:}` shorthand in `p_kw` all call it before `assignable`; for `**rest` the name is handed straight to `assignable` in `new_hash_pattern_tail`. So `**rest` is never registered in `pvtbl`, never checked against `in_alt_pattern`, and never sets `capture_in_pattern`. ## Duplicate binding case { a: 1, b: 2 } in { a: x, **x } then p x end $ ruby --parser=parse.y dup.rb {b: 2} # accepted and runs; x is the rest hash $ ruby --parser=prism dup.rb dup.rb:2: duplicated variable name (SyntaxError) `in a, a` and `in a, {a:}` are rejected by parse.y as expected; only `**rest` slips through. This is not a 4.0 regression: parse.y in 3.4.9 also accepts it, and Prism 3.4.9 already rejects it. ## Binding inside an alternative pattern case 1 in 1 | { a: 1, **rest } end $ ruby --parser=parse.y -c alt.rb Syntax OK $ ruby --parser=prism -c alt.rb alt.rb:2: variable capture in alternative pattern (SyntaxError) $ ruby --parser=parse.y alt.rb # compile.c still catches it at run time alt.rb:2: illegal variable in alternative pattern (rest) `*rest` in the same position is rejected at parse time by both parsers. This form only diverges since 4.0, where https://bugs.ruby-lang.org/issues/21572 moved the check to parse time; in 3.4.9 both parsers accept it under `-c` and reject it at compile time. ## Fix Call `error_duplicate_pattern_variable` in `p_kwrest`, as `p_rest` does. One line plus tests: https://github.com/ruby/ruby/pull/18831 It should land after the fix for https://bugs.ruby-lang.org/issues/22310 (https://github.com/ruby/ruby/pull/18830) on its own, making `**rest` set `capture_in_pattern` would newly reject an unrelated sibling alternation such as `in [ { **rest }, 1 | 2 ]` under the current `p_alt` check. With that fix applied first, both parsers agree on every form I tried. Since this turns code parse.y has accepted at least since 3.4 into a SyntaxError, I am not requesting a backport. ## Environment ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] # rejects with --parser=prism only ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin25] # duplicate case: same divergence -- https://bugs.ruby-lang.org/

1 0

[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) 14 Sep '26

14 Sep '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 2

[ruby-core:117750] [Ruby master Bug#20464] Redundant returns are unreachable in coverage
by kddnewton (Kevin Newton) 14 Sep '26

14 Sep '26

Issue #20464 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20464: Redundant returns are unreachable in coverage https://bugs.ruby-lang.org/issues/20464 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- With the following code: ```ruby def meth_return(a) return if a return end ``` If you run coverage on it, it's not possible for it to hit line 3, because there isn't a line event, because the return node was eliminated from the AST before it was compiled. There is a `putnil` instruction, so it's possible for us to attach a line event for it, but the compiler doesn't today. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:126573] [Ruby Bug#22294] Parsing a long && / || chain is quadratic
by make_now_just (Hiroya Fujinami) 14 Sep '26

14 Sep '26

Issue #22294 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Bug #22294: Parsing a long && / || chain is quadratic https://bugs.ruby-lang.org/issues/22294 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Target version: 4.0 * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Parsing a long chain of short-circuit logical operators (`&&`, `||`, `and`, `or`) takes time that is quadratic in the chain's length. It affects both parsers, parse.y and Prism. ## Reproduction ```ruby require "prism" def bench(label) puts label [2000, 4000, 8000, 16000].each do |n| src = "a" + " && a" * n started = Process.clock_gettime(Process::CLOCK_MONOTONIC) yield src elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - started puts format(" n=%-6d %8.1f ms", n, elapsed * 1000) end end bench("parse.y") { |src| RubyVM::AbstractSyntaxTree.parse(src) } bench("Prism") { |src| Prism.parse(src) } ``` Output on ruby 4.0.4 (arm64-darwin); the time roughly quadruples each time the length doubles: ``` parse.y n=2000 5.7 ms n=4000 22.9 ms n=8000 82.4 ms n=16000 277.0 ms Prism n=2000 4.9 ms n=4000 24.0 ms n=8000 98.5 ms n=16000 368.9 ms ``` `||` / `and` / `or` behave the same. Method chains (`a.b.c...`) and arithmetic (`a + a + ...`) are linear; only the short-circuit logical operators are affected. ## Cause - **parse.y** `logop()`: flattens the left-associative chain into a right-leaning tree, finding the insertion point by walking the whole right branch on every operator (O(n) per operator). - **Prism** `pm_check_value_expression()`: the check descends the left branch of the and/or node (O(n) per operator). ## Note Compiling such chains has a similar issue in the peephole optimizer, which is independent of this parsing issue. -- https://bugs.ruby-lang.org/

1 2