October 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 28 Oct '25

28 Oct '25

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

6 18

[ruby-core:123538] [Ruby Misc#21647] DevMeeting-2025-11-13
by mame (Yusuke Endoh) 28 Oct '25

28 Oct '25

Issue #21647 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21647: DevMeeting-2025-11-13 https://bugs.ruby-lang.org/issues/21647 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/11/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/11/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 28 Oct '25

28 Oct '25

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

22 76

[ruby-core:123569] [Ruby Bug#21652] Marshal#dump documentation out-of-date/unclear regarding Data class
by ryannevell (Ryan Nevell) 28 Oct '25

28 Oct '25

Issue #21652 has been reported by ryannevell (Ryan Nevell). ---------------------------------------- Bug #21652: Marshal#dump documentation out-of-date/unclear regarding Data class https://bugs.ruby-lang.org/issues/21652 * Author: ryannevell (Ryan Nevell) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- With the introduction of the `Data` class in Ruby 3.2, the `Marshal#dump` documentation is confusing since it claims that "Marshal can’t dump ... an instance of ... Data". It is even cross-linked to the new `Data` class. However, and thankfully, `Marshal#dump` does not have any issues serializing instances of `Data` or objects of the defined `Data` types. This message predates the introduction of the `Data` class, and likely refers to wrapped C data (`T_DATA`), instead. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123560] [Ruby Bug#21651] replacing a string with one backslash with two backslashes
by tdrive (Stanislav Boldaev) 28 Oct '25

28 Oct '25

Issue #21651 has been reported by tdrive (Stanislav Boldaev). ---------------------------------------- Bug #21651: replacing a string with one backslash with two backslashes https://bugs.ruby-lang.org/issues/21651 * Author: tdrive (Stanislav Boldaev) * Status: Open * ruby -v: 3.4.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ruby 2.7.8p225 (2023-03-30 revision 1f4d455848) [x86_64-linux] ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] ``` irb(main):002> "\\".gsub("\\", "\\\\") => "\\" irb(main):003> "\\".gsub("\\", "\\ \\") => "\\ \\" ``` The replacement is happening, as you can see from the version with the space, but why is the result so strange without the space? Similar code works fine in JS: ``` "\\".replace("\\", "\\\\") > '\\\\' ``` How to replace one backslash with two backslashes? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123558] [Ruby Bug#21650] Performance regression: `Rational#floor(ndigits)` extremely slow for huge ndigits in Ruby 3.4 (ok in 3.2)
by koilanetroc (Oleg Tolmashov) 28 Oct '25

28 Oct '25

Issue #21650 has been reported by koilanetroc (Oleg Tolmashov). ---------------------------------------- Bug #21650: Performance regression: `Rational#floor(ndigits)` extremely slow for huge ndigits in Ruby 3.4 (ok in 3.2) https://bugs.ruby-lang.org/issues/21650 * Author: koilanetroc (Oleg Tolmashov) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Summary `Rational#floor(ndigits)` with a very large positive ndigits takes tens of seconds in Ruby 3.4, while it returns essentially instantly in Ruby 3.2. Reproducible on macOS and Linux. Looks like a missing fast‑path for rationals whose decimal expansion terminates. ## Steps to reproduce ```ruby require "benchmark" puts RUBY_DESCRIPTION t = Benchmark.realtime { (2 ** -3).floor(2 ** 31) } puts "elapsed: #{t.round(3)}s" ``` Also reproduces with the explicit rational form: ```ruby Benchmark.realtime { Rational(1, 8).floor(2 ** 31) } ``` ### Results on my machine Ruby 3.2.8: ``` ruby 3.2.8 (2025-03-26 revision 13f495dc2c) [arm64-darwin24] slow_math.rb:4: warning: in a**b, b may be too big elapsed: 0.0s ``` Ruby 3.4.7: ``` ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin24] elapsed: 39.214s ``` ## Actual behavior On Ruby 3.4.x this call takes ~tens of seconds (e.g., ~40s on my machine), consuming CPU. Same on macOS and Linux. ## Expected behavior The method should return quickly (ideally O(1)). -- https://bugs.ruby-lang.org/

2 4

[ruby-core:123506] [Ruby Misc#21646] Propose Luke Gruber as a Ruby committer
by jhawthorn (John Hawthorn) 28 Oct '25

28 Oct '25

Issue #21646 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Misc #21646: Propose Luke Gruber as a Ruby committer https://bugs.ruby-lang.org/issues/21646 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- I'd like to propose adding Luke Gruber (@luke-gru) as a Ruby committer. He's been contributing to CRuby since 2019 fixing a variety of bugs and being active on redmine both filing and fixing issues. For the past few years he's made a lot of improvements to help stabilize Ractors and we've been working together on this for the past several months. A small sample of his work (more from [@luke-gruber and @luke-gru on GitHub](https://github.com/search?q=repo%3Aruby%2Fruby%20is%3Apr%20author%3…) * Fixed a complex lock-ordering issue that caused Ractors to deadlock [ruby/ruby#13682](https://github.com/ruby/ruby/pull/13682) * Optimizing `Regexp#match` to avoid allocations [ruby/ruby#9398](https://github.com/ruby/ruby/pull/9398) * Fixed issues with moving objects to a Ractor [ruby/ruby#9394](https://github.com/ruby/ruby/pull/9394) [ruby/ruby#9996](https://github.com/ruby/ruby/pull/9996) * Fixed a GC+Ractor+tracing bug that crashed on CI [ruby/ruby#14596](https://github.com/ruby/ruby/pull/14596) * Fixed a bug where Mutexes locked by finished Fibers could segv [ruby/ruby#14262](https://github.com/ruby/ruby/pull/14262) * Fixed String#crypt inside Ractors [ruby/ruby#13567](https://github.com/ruby/ruby/pull/13567) It would be helpful to me and to Ruby if he had commit access to merge changes more easily. I would help with onboarding :) -- https://bugs.ruby-lang.org/

7 7

[ruby-core:123279] [Ruby Misc#21609] Propose Stan Lo (@st0012) as a core committer
by tekknolagi (Maxwell Bernstein) 28 Oct '25

28 Oct '25

Issue #21609 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Misc #21609: Propose Stan Lo (@st0012) as a core committer https://bugs.ruby-lang.org/issues/21609 * Author: tekknolagi (Maxwell Bernstein) * Status: Open ---------------------------------------- ## Proposal I'd like to propose Stan Lo (@st0012) as a committer. He's been doing excellent work on ZJIT for the past couple of months, making sure we're compatible with the test suite, analyzing benchmark data, and optimizing the generated code. Especially since he has been contributing to Ruby for years now and knows the community, I think he should be able to merge his own changes. Here is Stan's message: ## Stan Lo's message I have been contributing to Ruby and core Ruby tools since 2021\. My main contributions have been: ### ZJIT Contributions ([60+ PRs](https://github.com/ruby/ruby/pulls?q=is%3Apr+author%3Ast0012+ZJIT+is%3…) - Made ZJIT work with TracePoint ([\#14407](https://github.com/ruby/ruby/pull/14407), [\#14420](https://github.com/ruby/ruby/pull/14420)) - Built infrastructure for annotating builtin functions ([\#14078](https://github.com/ruby/ruby/pull/14078)) - Implemented invalidation for method redefinition ([\#13875](https://github.com/ruby/ruby/pull/13875)), stable constants ([\#13998](https://github.com/ruby/ruby/pull/13998)), single Ractor mode ([\#14121](https://github.com/ruby/ruby/pull/14121)) - Supported compiling instructions: `concatstrings` ([\#14154](https://github.com/ruby/ruby/pull/14154)), `opt_and`/`opt_or` ([\#13830](https://github.com/ruby/ruby/pull/13830)), `invokeblock` ([\#14496](https://github.com/ruby/ruby/pull/14496)), `opt_case_dispatch` ([\#14433](https://github.com/ruby/ruby/pull/14433)) - Expanded test infrastructure to run against all Ruby tests ([\#13950](https://github.com/ruby/ruby/pull/13950)) ### Core Ruby Tools - **IRB** \- [All-time \#1 contributor](https://github.com/ruby/irb/graphs/contributors) and maintainer since 2022 - Implemented major features across Ruby 3.2-3.4: `cd` command, `edit` command, `show_cmds`, pager support, integration with `ruby/debug`…etc. - **RDoc** \- Maintainer since 2024 - Redesigned the default theme for Ruby 3.4+ ([\#1191](https://github.com/ruby/rdoc/pull/1191), [\#1157](https://github.com/ruby/rdoc/pull/1157)) - Created docs.ruby-lang.org with new homepage ([\#12227](https://github.com/ruby/ruby/pull/12227)) and greatly improved standard library page ([\#12404](https://github.com/ruby/ruby/pull/12404)) - **Debug** \- [\#2 contributor with 400+ commits](https://github.com/ruby/debug/graphs/contributors) - IRB integration ([\#1024](https://github.com/ruby/debug/pull/1024)) - `outline` command ([\#173](https://github.com/ruby/debug/pull/173)) - Backtrace filtering ([\#138](https://github.com/ruby/debug/pull/138)) I would like to continue contributing to ZJIT, IRB, RDoc, and other parts of Ruby. Being a committer would make it easier to maintain these critical tools and contribute to ZJIT's ongoing development. -- https://bugs.ruby-lang.org/

10 11

[ruby-core:123549] [Ruby Bug#21649] Ractors can access non-shareable object through singleton classes
by jhawthorn (John Hawthorn) 27 Oct '25

27 Oct '25

Issue #21649 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21649: Ractors can access non-shareable object through singleton classes https://bugs.ruby-lang.org/issues/21649 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- If we send a non-shareable object into a Ractor, it needs to be copied. ``` ❯ ruby -W0 -e 'Ractor.new(p(Object.new)) { |o| p(o) }.join' #<Object:0x00000001240f8cf8> #<Object:0x00000001240f8870> ``` However we're able to instead smuggle it through a singleton class to unsafely get a mutable reference to the same object in both Ractors. ``` ❯ ruby -W0 -e 'Ractor.new(p(Object.new).singleton_class) { |o| p(o.attached_object) }.join' #<Object:0x0000000120768c40> #<Object:0x0000000120768c40> ``` I think we should probably make singleton classes copy the shareability of their attached object. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123546] [Ruby Bug#21648] [prism] ruby crashes for `for * in [10]; end`
by Earlopain (Earlopain _) 27 Oct '25

27 Oct '25

Issue #21648 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21648: [prism] ruby crashes for `for * in [10]; end` https://bugs.ruby-lang.org/issues/21648 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```sh $ ruby -e "for * in [10]; end" -e:1: [BUG] Stack consistency error (sp: 15, bp: 14) ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0008 s:0015 e:000013 BLOCK -e:1 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :each c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0014c0 DUMMY [FINISH] ... ``` `parse.y` handles this ---Files-------------------------------- crash.txt (19.7 KB) -- https://bugs.ruby-lang.org/

1 2