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

[ruby-core:124394] [Ruby Bug#21815] Backport
by nobu (Nobuyoshi Nakada) 12 Jan '26

12 Jan '26

Issue #21815 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21815: Backport https://bugs.ruby-lang.org/issues/21815 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- [GH-15737] [GH-15737]: https://github.com/ruby/ruby/pull/15737 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124485] [Ruby Bug#21824] performance regression in regexp matching after update to 4.0
by mackuba (Kuba Suder) 12 Jan '26

12 Jan '26

Issue #21824 has been updated by mackuba (Kuba Suder). Hey - see the two links to the git repo on tangled.org in the bug description, it includes a test script. ---------------------------------------- Bug #21824: performance regression in regexp matching after update to 4.0 https://bugs.ruby-lang.org/issues/21824#change-116037 * Author: mackuba (Kuba Suder) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TLDR: a change in the regexp algorithm in regcomp.c merged around October was supposed to speed up the matching, but it seems it has slowed it down more in practice. === I'm running a service written in Ruby which serves some number of Bluesky feeds. As part of this service, I have a process that connects to a websocket API (w/ EventMachine), reads from it all new posts made on the network in real time (on the order of ~100 posts per second on average lately), and passes each post through a #post_matches? method in about 20 feed objects, each of which has a number of regexps configured (most have around 20-30, but one has a few hundred, probably something like 900 regexps in total). If a given post's text (up to 300 unicode characters) matches any of the regexps of the given feed (and/or matches some additional conditions), it's added to this feed in the database. I often use a slightly older version of this project with a fixed pre-downloaded chunk of the posts stream, with ~100k random but real posts in one large binary file, as a benchmark on different versions of Ruby. So I ran it again on 4.0 after it was released a week ago, and I got this: https://bsky.app/profile/mackuba.eu/post/3mb2quhdoqs23 The numbers are the calculated speed of processing, in events per second, after going through the whole sample of 100k events and a full set of feeds. So there was a 5-6% slowdown on Ruby 4.0 vs. Ruby 3.4 (with or without YJIT), putting it below any version of Ruby since 3.0. I started profiling which specific parts of the code got slower, and I narrowed it down to regexp matching (the full loop also does e.g. decoding of data from a binary format from the file). I made a demo project reproducing this here (note, linking to a slightly earlier commit): https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/63e208de944debdc0a6…. There are 940 posts here in the sample and 17 regexps, and running 1000 loops takes 7 seconds on Ruby 3.4, but 13.5s on 4.0 (so almost 2x longer). Then, I started digging into the details to see if some specific posts or specific regexps cause the slowdown. It turned out that most of the 17 regexps, if tested alone, work about the same on 3.4 & 4.0, but two work around 4x slower: /\bslackware\b/i and /\bkde plasma\b/i. (This seems to be not only about the length of the regexp, but also specific characters, because e.g. /\blongstring\b/i does not trigger this effect.) It also seems that this only happens if the searched string contains non-ASCII characters. An updated, more minimal version of the demo is here: https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/d9e145c1e9f39fca6dd…. One regexp and one string. With a million loops, it takes 0.75s on Ruby 3.4, but 2.7s on Ruby 4.0. (No change on latest master, ruby 4.1.0dev (2026-01-05T17:18:47Z master 7e81bf5c0c), i.e. it's still much slower than on 3.4.) If the few non-ASCII characters (apostrophe, ndash, ellipsis, TM) are removed from the string, the slowdown goes away. Finally, with some help from Codex I tried to track down which specific change between 3.4 and 4.0 caused this slowdown. It turned out to be this commit: https://github.com/ruby/ruby/commit/981ee02c7c664f19b983662d618d5e6bd87d1739, authored in November 2017 (!), but merged around 31st October this year. It says it "fixes performance problem with /k/i and /s/i". I'm not familiar with these string search algorithms so I'm not able to evaluate this in detail or say how this could be fixed, but from the description I'm assuming that it improves performance in some cases of text/regexp, but apparently degrades it in some others like mine. Since in my main test of a practical scenario which matches ~100k posts against ~900 regexps, as well as the earlier demo which matches 940 posts against 17 regexps, the updated version in 4.0 is slower (5% and 47% slower, respectively), my guess is that the net result will generally be negative, i.e. that this change committed in October makes more cases slower than it makes faster. But like I said, I don't know enough about regexp algorithms to analyze this deeper, I can only report my results. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124482] [Ruby Bug#21824] performance regression in regexp matching after update to 4.0
by nobu (Nobuyoshi Nakada) 12 Jan '26

12 Jan '26

Issue #21824 has been updated by nobu (Nobuyoshi Nakada). Could you share how you measured the performance? ---------------------------------------- Bug #21824: performance regression in regexp matching after update to 4.0 https://bugs.ruby-lang.org/issues/21824#change-116032 * Author: mackuba (Kuba Suder) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TLDR: a change in the regexp algorithm in regcomp.c merged around October was supposed to speed up the matching, but it seems it has slowed it down more in practice. === I'm running a service written in Ruby which serves some number of Bluesky feeds. As part of this service, I have a process that connects to a websocket API (w/ EventMachine), reads from it all new posts made on the network in real time (on the order of ~100 posts per second on average lately), and passes each post through a #post_matches? method in about 20 feed objects, each of which has a number of regexps configured (most have around 20-30, but one has a few hundred, probably something like 900 regexps in total). If a given post's text (up to 300 unicode characters) matches any of the regexps of the given feed (and/or matches some additional conditions), it's added to this feed in the database. I often use a slightly older version of this project with a fixed pre-downloaded chunk of the posts stream, with ~100k random but real posts in one large binary file, as a benchmark on different versions of Ruby. So I ran it again on 4.0 after it was released a week ago, and I got this: https://bsky.app/profile/mackuba.eu/post/3mb2quhdoqs23 The numbers are the calculated speed of processing, in events per second, after going through the whole sample of 100k events and a full set of feeds. So there was a 5-6% slowdown on Ruby 4.0 vs. Ruby 3.4 (with or without YJIT), putting it below any version of Ruby since 3.0. I started profiling which specific parts of the code got slower, and I narrowed it down to regexp matching (the full loop also does e.g. decoding of data from a binary format from the file). I made a demo project reproducing this here (note, linking to a slightly earlier commit): https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/63e208de944debdc0a6…. There are 940 posts here in the sample and 17 regexps, and running 1000 loops takes 7 seconds on Ruby 3.4, but 13.5s on 4.0 (so almost 2x longer). Then, I started digging into the details to see if some specific posts or specific regexps cause the slowdown. It turned out that most of the 17 regexps, if tested alone, work about the same on 3.4 & 4.0, but two work around 4x slower: /\bslackware\b/i and /\bkde plasma\b/i. (This seems to be not only about the length of the regexp, but also specific characters, because e.g. /\blongstring\b/i does not trigger this effect.) It also seems that this only happens if the searched string contains non-ASCII characters. An updated, more minimal version of the demo is here: https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/d9e145c1e9f39fca6dd…. One regexp and one string. With a million loops, it takes 0.75s on Ruby 3.4, but 2.7s on Ruby 4.0. (No change on latest master, ruby 4.1.0dev (2026-01-05T17:18:47Z master 7e81bf5c0c), i.e. it's still much slower than on 3.4.) If the few non-ASCII characters (apostrophe, ndash, ellipsis, TM) are removed from the string, the slowdown goes away. Finally, with some help from Codex I tried to track down which specific change between 3.4 and 4.0 caused this slowdown. It turned out to be this commit: https://github.com/ruby/ruby/commit/981ee02c7c664f19b983662d618d5e6bd87d1739, authored in November 2017 (!), but merged around 31st October this year. It says it "fixes performance problem with /k/i and /s/i". I'm not familiar with these string search algorithms so I'm not able to evaluate this in detail or say how this could be fixed, but from the description I'm assuming that it improves performance in some cases of text/regexp, but apparently degrades it in some others like mine. Since in my main test of a practical scenario which matches ~100k posts against ~900 regexps, as well as the earlier demo which matches 940 posts against 17 regexps, the updated version in 4.0 is slower (5% and 47% slower, respectively), my guess is that the net result will generally be negative, i.e. that this change committed in October makes more cases slower than it makes faster. But like I said, I don't know enough about regexp algorithms to analyze this deeper, I can only report my results. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124173] [Ruby Misc#21777] DevMeeting-2026-01-14
by mame (Yusuke Endoh) 10 Jan '26

10 Jan '26

Issue #21777 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21777: DevMeeting-2026-01-14 https://bugs.ruby-lang.org/issues/21777 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/01/14 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 2026/01/11. 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/

4 9

[ruby-core:124469] [Ruby Feature#16848] Allow callables in $LOAD_PATH
by fxn (Xavier Noria) 09 Jan '26

09 Jan '26

Issue #16848 has been updated by fxn (Xavier Noria). BTW, the contract could be to return a file handle (which could be a StringIO) or `nil`. ---------------------------------------- Feature #16848: Allow callables in $LOAD_PATH https://bugs.ruby-lang.org/issues/16848#change-116020 * Author: byroot (Jean Boussier) * Status: Feedback ---------------------------------------- Make it easier to implement `$LOAD_PATH` caching, and speed up application boot time. I benchmarked it on Redmine's master using bootsnap with only the optimization enabled: ```ruby if ENV['CACHE_LOAD_PATH'] require 'bootsnap' Bootsnap.setup( cache_dir: 'tmp/cache', development_mode: false, load_path_cache: true, autoload_paths_cache: true, disable_trace: false, compile_cache_iseq: true, compile_cache_yaml: false, ) end ``` ``` $ RAILS_ENV=production time bin/rails runner 'p 1' 2.66 real 1.99 user 0.66 sys $ RAILS_ENV=production time bin/rails runner 'p 1' 2.71 real 1.97 user 0.66 sys $ CACHE_LOAD_PATH=1 RAILS_ENV=production time bin/rails runner 'p 1' 1.41 real 1.12 user 0.28 sys $ CACHE_LOAD_PATH=1 RAILS_ENV=production time bin/rails runner 'p 1' 1.41 real 1.12 user 0.28 sys ``` That's twice for a relatively small application. And the performance improvement is not linear; the larger the application, the larger the improvement. ### How it works `require` has `O($LOAD_PATH.size)` performance. The more gems you add to your `Gemfile`, the larger `$LOAD_PATH` becomes. `require "foo.rb"` will try to open the file in each of the `$LOAD_PATH` entries. And since more gems usually also means more `require` calls, loading Ruby code may take up to quadratic performance loss. To improve this, Bootsnap pre-computes a map of all the files in your `$LOAD_PATH`, and uses it to convert relative paths into absolute paths so that Ruby skips the `$LOAD_PATH` traversal. ```ruby $LOAD_PATH = $w(/gems/foo/lib /gems/bar/lib) BOOTSNAP_CACHE = { "bar.rb" => "/gems/bar/lib/bar.rb", } ``` This resolves file lookup by a single hash lookup, and reduces boot performance from roughly `O($LOAD_PATH.size * number_of_files_to_require)` to `O(number_of_files_to_require)`. This optimization is also used in [Gel](https://github.com/gel-rb/gel), a Rubygems/Bundler replacement. ### Trade offs Every time `$LOAD_PATH` is modified, the cache must become invalidated. While this is complex to do for Bootsnap, it would be fairly easy if it is implemented inside Ruby. More importantly, you have to invalidate the cache whenever you add or delete a file to/from one of the `$LOAD_PATH` members; otherwise, if you shadow or unshadow another file farther in the `$LOAD_PATH`, Bootsnap will load a wrong file. For instance, if `require "foo.rb"` initially resolves to `/some/gem/foo.rb`, and you create `lib/foo.rb`, you'll need to flush Bootsnap cache. That latter is trickier, and Bootsnap has decided that it is rare enough to cause actual problems, and so far that holds. But that is not a trade off Ruby can make. However that's probably a tradeoff Rubygems/Bundler can make. While it's common to edit your gems to debug something, it's really uncommon to add or remove files inside them. So in theory Rubygems/Bundler could compute a map of all files in a gem that can be required after it installs it. Then when you activate it, you merge it together with the other activated gems. ### Proposal This could be reasonably easy to implement if `$LOAD_PATH` accepted callables in addition to paths. Something like this: ```ruby $LOAD_PATH = [ 'my_app/lib', BundlerOrRubygems.method(:lookup), ] ``` The contract would be that `BundlerOrRubygems.lookup("some_relative/path.rb")` would return either an absolute path or `nil`. With such API, it would be easy to cache absolute paths only for gems and the stdlib, and preserve the current cache-less behavior for the application specific load paths, which are usually much less numerous. It would also allow frameworks such as Rails to implement the same caching for application paths when running in an environment where the source files are immutable (typically production). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124468] [Ruby Feature#16848] Allow callables in $LOAD_PATH
by fxn (Xavier Noria) 09 Jan '26

09 Jan '26

Issue #16848 has been updated by fxn (Xavier Noria). Hey, just saw this ticket. I wanted to share as a curiosity that Perl has this: You can store coderefs in `@INC`. That gives you plenty of flexibility. For example, the Perl Archive Toolkit provides a way to ship projects in one single .par file. Similar idea to .jar files in Java. PAR injects code in `@INC` to perform file lookups inside the .par files. ---------------------------------------- Feature #16848: Allow callables in $LOAD_PATH https://bugs.ruby-lang.org/issues/16848#change-116019 * Author: byroot (Jean Boussier) * Status: Feedback ---------------------------------------- Make it easier to implement `$LOAD_PATH` caching, and speed up application boot time. I benchmarked it on Redmine's master using bootsnap with only the optimization enabled: ```ruby if ENV['CACHE_LOAD_PATH'] require 'bootsnap' Bootsnap.setup( cache_dir: 'tmp/cache', development_mode: false, load_path_cache: true, autoload_paths_cache: true, disable_trace: false, compile_cache_iseq: true, compile_cache_yaml: false, ) end ``` ``` $ RAILS_ENV=production time bin/rails runner 'p 1' 2.66 real 1.99 user 0.66 sys $ RAILS_ENV=production time bin/rails runner 'p 1' 2.71 real 1.97 user 0.66 sys $ CACHE_LOAD_PATH=1 RAILS_ENV=production time bin/rails runner 'p 1' 1.41 real 1.12 user 0.28 sys $ CACHE_LOAD_PATH=1 RAILS_ENV=production time bin/rails runner 'p 1' 1.41 real 1.12 user 0.28 sys ``` That's twice for a relatively small application. And the performance improvement is not linear; the larger the application, the larger the improvement. ### How it works `require` has `O($LOAD_PATH.size)` performance. The more gems you add to your `Gemfile`, the larger `$LOAD_PATH` becomes. `require "foo.rb"` will try to open the file in each of the `$LOAD_PATH` entries. And since more gems usually also means more `require` calls, loading Ruby code may take up to quadratic performance loss. To improve this, Bootsnap pre-computes a map of all the files in your `$LOAD_PATH`, and uses it to convert relative paths into absolute paths so that Ruby skips the `$LOAD_PATH` traversal. ```ruby $LOAD_PATH = $w(/gems/foo/lib /gems/bar/lib) BOOTSNAP_CACHE = { "bar.rb" => "/gems/bar/lib/bar.rb", } ``` This resolves file lookup by a single hash lookup, and reduces boot performance from roughly `O($LOAD_PATH.size * number_of_files_to_require)` to `O(number_of_files_to_require)`. This optimization is also used in [Gel](https://github.com/gel-rb/gel), a Rubygems/Bundler replacement. ### Trade offs Every time `$LOAD_PATH` is modified, the cache must become invalidated. While this is complex to do for Bootsnap, it would be fairly easy if it is implemented inside Ruby. More importantly, you have to invalidate the cache whenever you add or delete a file to/from one of the `$LOAD_PATH` members; otherwise, if you shadow or unshadow another file farther in the `$LOAD_PATH`, Bootsnap will load a wrong file. For instance, if `require "foo.rb"` initially resolves to `/some/gem/foo.rb`, and you create `lib/foo.rb`, you'll need to flush Bootsnap cache. That latter is trickier, and Bootsnap has decided that it is rare enough to cause actual problems, and so far that holds. But that is not a trade off Ruby can make. However that's probably a tradeoff Rubygems/Bundler can make. While it's common to edit your gems to debug something, it's really uncommon to add or remove files inside them. So in theory Rubygems/Bundler could compute a map of all files in a gem that can be required after it installs it. Then when you activate it, you merge it together with the other activated gems. ### Proposal This could be reasonably easy to implement if `$LOAD_PATH` accepted callables in addition to paths. Something like this: ```ruby $LOAD_PATH = [ 'my_app/lib', BundlerOrRubygems.method(:lookup), ] ``` The contract would be that `BundlerOrRubygems.lookup("some_relative/path.rb")` would return either an absolute path or `nil`. With such API, it would be easy to cache absolute paths only for gems and the stdlib, and preserve the current cache-less behavior for the application specific load paths, which are usually much less numerous. It would also allow frameworks such as Rails to implement the same caching for application paths when running in an environment where the source files are immutable (typically production). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124465] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 09 Jan '26

09 Jan '26

Issue #6012 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-50: > Also, Ruby's grammar will certainly continue to change, and I have no doubt that the instances of overlapping Nodes, beyond just `StatementsNode` and `CallNode`, can increase accordingly. Maybe, but this does not matter for this feature. A {Method,UnboundMethod,Proc}#source_location will remain the same regardless of the number of overlapping Nodes. There are many use cases and ultimate purposes that are treating the source of a method/block as a string to e.g. print the source of the method/block, or inject extra code in it. I believe those are valid, even if they don't work in some weird edge case (heredoc across end). Requiring e.g. parsing + unparsing for every code transformation/instrumentation is too heavy, many use cases don't need that. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116016 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124464] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 09 Jan '26

09 Jan '26

Issue #6012 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-50: > "I don't know exactly what users are using the `method_source` gem for, but since it's used so much, we should provide equivalent functionality as a built-in feature" > > This argument can hardly persuade anyone... However, let’s assume we proceed with that logic. In that case, `source_location` would have to follow the behavior of the `method_source` gem exactly, without questioning its validity (including heredocs and the glitch-like behavior you pointed out). Since we do not know the user's ultimate purpose, there is a possibility that those glitch-like behaviors happen to be exactly what satisfies the user. > > Is that really what you want? Of course there is nuance there. I think the high usage of that gem means that some functionality there is found useful by many. I think looking a bit further than the number of usages to what the usages look like I did in https://bugs.ruby-lang.org/issues/6012#note-47 is good. I think knowing the exact ultimate purpose of each usage is unnecessary and would require way too much work, and that this grouping of some ultimate purposes is enough: > The above snippets show examples of source transformation, instrumentation of code by adding extra code in the method body, displaying the source code of a method to the user, and other use cases which would need more time to find out. Also the analysis above showing e.g. having `end_line` is a recurrent need. That is I believe enough to justify the extended `source_location`, and the fact #21795 doesn't address some of these usages (or would it be a roundabout/inefficient way to get that information). Separately, the fact this has been asked 14 years ago and lots of people want it (in this and related issues), and that there seems to be no significant downside to it is IMO enough. Also, I find it weird that you question (a lot) the need for it now, when it has already been approved a year ago: https://bugs.ruby-lang.org/issues/6012#note-25 And approved again in https://github.com/ruby/ruby/pull/15580#issuecomment-3691058342. The change has been in master for a year, no compatibility concern has been raised, so why be so worried now when it was the same a year ago? ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116015 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124460] [Ruby Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 08 Jan '26

08 Jan '26

Issue #6012 has been updated by mame (Yusuke Endoh). Eregon (Benoit Daloze) wrote in #note-49: > In any case I don't think it's our place to judge whether each usage is "valid" or "correct" or not, it's definitely useful functionality since it's used so much. "I don't know exactly what users are using the `method_source` gem for, but since it's used so much, we should provide equivalent functionality as a built-in feature" This argument can hardly persuade anyone... However, let’s assume we proceed with that logic. In that case, `source_location` would have to follow the behavior of the `method_source` gem exactly, without questioning its validity (including heredocs and the glitch-like behavior you pointed out). Since we do not know the user's ultimate purpose, there is a possibility that those glitch-like behaviors happen to be exactly what satisfies the user. Is that really what you want? > Nobody expects the `StatementsNode` instead of the `CallNode` for `Prism.node_for(Proc)`. To give an extreme example, suppose we implement a TracePoint like `:ast_node_enter` that fires every time the interpreter evaluates each Prism node (as like a tree-walking interpreter). In that scenario, `Prism.node_for(TracePoint)` would need to distinguish between a `StatementsNode` and a `CallNode`. Also, Ruby's grammar will certainly continue to change, and I have no doubt that the instances of overlapping Nodes, beyond just `StatementsNode` and `CallNode`, can increase accordingly. > I do agree with you that for final use case of getting a Prism AST, #21795 would be more direct and safer (e.g. can check hash of the file). > And there it's totally fine to use `node_id` internally on CRuby, as it remains an implementation detail not exposed to the user. I agree with this. While #21795 seems like a heavy task with many issues to resolve, I think it is a sound approach in the sense that it is better to hide the implementation details of how to map Ruby objects to AST nodes. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116011 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122552] [Ruby Feature#21442] Make tsort to bundled gems
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #21442 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21442: Make tsort to bundled gems https://bugs.ruby-lang.org/issues/21442 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- In last year, I gave up to make `tsort` to bundled gems because `set` depends `tsort`. https://github.com/ruby/set/blob/29a253d2259e8d6d9b313dec8418ec5ed0caab08/l… Fortunately, `set` is now core class. So, there is no library depends on `tsort` in ruby repository. I propose to make `tsort` to bundled gems at the next release(not Ruby 3.5/4.0, for 4.0(?)/4.1) -- https://bugs.ruby-lang.org/

1 3