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

[ruby-core:124448] [Ruby Bug#21829] test
by h0w1e (howie qin) 07 Jan '26

07 Jan '26

Issue #21829 has been reported by h0w1e (howie qin). ---------------------------------------- Bug #21829: test https://bugs.ruby-lang.org/issues/21829 * Author: h0w1e (howie qin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ---Files-------------------------------- xss_verysmall.xlsx (747 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124447] [Ruby Misc#17376] Reduce number of GitHub Actions
by hsbt (Hiroshi SHIBATA) 07 Jan '26

07 Jan '26

Issue #17376 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed The current job number is 94 each commit and GitHub improved their UI of GitHub Actions. I'm closing this. ---------------------------------------- Misc #17376: Reduce number of GitHub Actions https://bugs.ruby-lang.org/issues/17376#change-115995 * Author: naruse (Yui NARUSE) * Status: Closed * Assignee: shyouhei (Shyouhei Urabe) ---------------------------------------- At this time we have 127 checks for GitHub commits, but unfortunately GitHub UI only shows 100 checks. It sometimes makes we don't see a failed check. Could you reduce number of GitHub actions at least less than 100? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124446] [Ruby Feature#17210] More readable and useful `Set#inspect`
by hsbt (Hiroshi SHIBATA) 07 Jan '26

07 Jan '26

Issue #17210 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed ``` ❯ ruby -ve "puts Set[1,2,3]" ruby 4.1.0dev (2026-01-06T23:05:30Z master b2ed4cdced) +YJIT +MN +PRISM [arm64-darwin25] Set[1, 2, 3] ``` Ruby 4.0 introduced this feature request. ---------------------------------------- Feature #17210: More readable and useful `Set#inspect` https://bugs.ruby-lang.org/issues/17210#change-115994 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: knu (Akinori MUSHA) ---------------------------------------- I would like to change `Set#inspect`/`to_s`: ```ruby # before puts Set[1,2,3] # => "#<Set: {1, 2, 3}>" # after puts Set[1,2,3] # => "Set[1, 2, 3]" ``` This output is shorter, readable, and has the property that it corresponds to Ruby code -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124445] [Ruby Feature#16989] Sets: need ♥️
by hsbt (Hiroshi SHIBATA) 07 Jan '26

07 Jan '26

Issue #16989 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed `Set` is promoted to Core class at Ruby 4.0. ---------------------------------------- Feature #16989: Sets: need ♥️ https://bugs.ruby-lang.org/issues/16989#change-115993 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: knu (Akinori MUSHA) ---------------------------------------- I am opening a series of feature requests on `Set`, all of them based on this usecase. The main usecase I have in mind is my recent experience with `RuboCop`. I noticed a big number of frozen arrays being used only to later call `include?` on them. This is `O(n)` instead of `O(1)`. Trying to convert them to `Set`s causes major compatibility issues, as well as very frustrating situations and some cases that would make them much less efficient. Because of these incompatibilities, `RuboCop` is in the process of using a custom class based on `Array` with optimized `include?` and `===`. `RuboCop` runs multiple checks on Ruby code. Those checks are called cops. `RuboCop` performance is (IMO) pretty bad and some cops currently are in `O(n^2)` where n is the size of the code being inspected. Even given these extremely inefficient cops, optimizing the 100+ such arrays (most of which are quite small btw) gave a 5% speed boost. RuboCop PRs for reference: https://github.com/rubocop-hq/rubocop-ast/pull/29 https://github.com/rubocop-hq/rubocop/pull/8133 My experience tells me that there are many other opportunities to use `Set`s that are missed because `Set`s are not builtin, not known enough and have no shorthand notation. In this issue I'd like to concentrate the discussion on the following request: `Set`s should be core objects, in the same way that `Complex` were not and are now. Some of the upcoming feature requests would be easier (or only possible) to implement were `Set`s builtin. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124442] [Ruby Feature#13683] Add strict Enumerable#single
by headius (Charles Nutter) 07 Jan '26

07 Jan '26

Issue #13683 has been updated by headius (Charles Nutter). zverok (Victor Shepelev) wrote in #note-39: > > How about #one! or similar to indicate it must be one element? > > I think Ruby's core agreement is `!` indicates the methods that change the receiver (`strip`/`strip!`), so unless we plan to introduce Rails-y agreement with it designating "dangerous" method (`save`/`save!`), this wouldn't be appropriate. Ruby also uses it other places, like `exit!` and `kill!`, OpenSSL's `generate_key!`, Date's `new!`. It's also in English a way to emphasize the previous statement... so "one!" meaning "one and only one!". > I also feel weird about "sole" (I rarely see this word used anywhere in APIs or "simplified" engineering English), but so far, considering Matz vetoed `single` and `only`, and there are counter-arguments for `one`, this seems like the strongest contender. I could perhaps be convinced about "solitary" or other accepted terms for "one and only one" but "sole" does not feel right at all. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-115991 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124439] [Ruby Feature#13683] Add strict Enumerable#single
by zverok (Victor Shepelev) 07 Jan '26

07 Jan '26

Issue #13683 has been updated by zverok (Victor Shepelev). > How about #one! or similar to indicate it must be one element? I think Ruby's core agreement is `!` indicates the methods that change the receiver (`strip`/`strip!`), so unless we plan to introduce Rails-y agreement with it designating "dangerous" method (`save`/`save!`), this wouldn't be appropriate. I also feel weird about "sole" (I rarely see this word used anywhere in APIs or "simplified" engineering English), but so far, considering Matz vetoed `single` and `only`, and there are counter-arguments for `one`, this seems like the strongest contender. The idea of a longer, more descriptive name doesn't sit right with me either; that's uncharacteristic for "simple" APIs. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-115988 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

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

07 Jan '26

Issue #6012 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-48: > A "use case" is the ultimate goal that the examples aim to achieve via `Method#source`. 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. 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. For example, some gems might transform the source code of a method as a string, you might argue it's less safe but it's also much simpler than parsing + unparsing and it obviously works well enough for them. > By the way, I tried the `method_source` gem, and I noticed that it includes heredoc content that lies outside the method definition block. I think that's just a side effect of `method_source` currently adding lines until it's valid Ruby source code. In practice I think there are very few heredocs like this for methods, so it probably does not matter for 99.99% cases. Note that the current `method_source` approach is much worse than using the new `source_location`, because it's incorrect for e.g. ```ruby def method end; any code ``` e.g. ```ruby def foo end; def bar end ``` where it would return the entire code for the source of `foo`. This is much more common than heredocs spanning across `end`. For example this is common in tests: ```ruby def some_test some assertions end unless /mswin|mingw/ =~ RUBY_PLATFORM ``` The gem currently return the entire snippet, but with `source_location` it would be correct and stop at `end` > My point is that the "better" return value depends entirely on the final use case. Yes, that's fair but that edge case is very rare. For the final use case of getting an AST, `Prism.node_for(Method)` or `Method#ast` is more direct and works even for that edge case. For the final use case of displaying the method source code it seems nicer to include the heredoc, and OTOH that is somewhat complicated and unintuitive to do from the AST. > > Do you have a counter-example where this wouldn't hold? > > I don't have one at present. However, such a case could arise through future extensions. > For example, @ko1 might add a new TracePoint type in the future, and depending on the type, it might be necessary to distinguish between `StatementsNode` and `CallNode`. #21795 is specifically about call/return TracePoint, so that's not an issue. I don't think anyone would ever want to get a `StatementsNode` from some `#ast` method, that's "invisible" in user code (IOW, it doesn't "consume" characters in the source to exist). So I think for every node that "consumes" characters in the source to exist there is no problem, it's uniquely identified by start/end line/column. > More importantly, CRuby can implement `Prism.node_for` using `node_id` without the risk of future ambiguity. > There is no reason to implement such a heuristic hack that tries to select overlapping nodes based on Ruby object type. IMO using `node_id` is a hack, and my implementation of `Prism.node_for` in https://github.com/ruby/prism/pull/3808 is AFAIK fully correct and portable (does not depend on CRuby internals, can easily be supported by all Ruby implementations through the extended `source_location` from this issue). There is no "heuristic hack", it's the fully correct and deterministic decision in this context. Nobody expects the `StatementsNode` instead of the `CallNode` for `Prism.node_for(Proc)`. That implementation also works even with `--parser=parse.y`, while it wouldn't if it were using `node_id`. This is a good illustration that start/end line/column are more universal and well-defined, unlike `node_id` which is dependent on the parser and order-of-iteration. 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. So I'd be happy if you help me get that issue approved. But there are other use cases for `source_location` to include end line and start/end column as shown in my previous comment, and the current implementation meets them well, except for very rare edge cases where as you say, there is no correct or wrong way. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115987 * 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:124436] [Ruby Feature#13683] Add strict Enumerable#single
by headius (Charles Nutter) 07 Jan '26

07 Jan '26

Issue #13683 has been updated by headius (Charles Nutter). I don't like #sole as the method name but I can't quite explain why. I'd rather have #single or #singleton (The mathematical term for a set of one) or a two word #single_element or #one_only. How about #one! or similar to indicate it **must** be one element? ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-115985 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

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

07 Jan '26

Issue #6012 has been updated by mame (Yusuke Endoh). > A quick search shows some examples which do not use an AST: A "use case" is the ultimate goal that the examples aim to achieve via `Method#source`. By the way, I tried the `method_source` gem, and I noticed that it includes heredoc content that lies outside the method definition block. ```ruby require "method_source" def foo; <<END; end FOO END p method(:foo).source #=> "def foo; <<END; end\nFOO\nEND\n" p method(:foo).source_location #=> ["/tmp/t.rb", 3, 0, 3, 19] ``` On the other hand, the current `source_location` (as shown above) only includes the range of `def ... end`. I am not arguing that `source_location` needs to be fixed. My point is that the "better" return value depends entirely on the final use case. If the goal of `Method#source` is to return a parsable code fragment (I don't know if that is the official goal), then its current behavior might be expected. However, since @eregon seems to want to use `source_location` to identify AST subtrees, `source_location` should not be fine-tuned for one specific use case. I don't think there is a single, perfect "correct" `source_location` that everyone can agree on. It will likely vary depending on the ultimate use case. Instead, I believe users should extract the AST and decide for themselves what location information to obtain. > Do you have a counter-example where this wouldn't hold? I don't have one at present. However, such a case could arise through future extensions. For example, @ko1 might add a new TracePoint type in the future, and depending on the type, it might be necessary to distinguish between `StatementsNode` and `CallNode`. More importantly, CRuby can implement `Prism.node_for` using `node_id` without the risk of future ambiguity. There is no reason to implement such a heuristic hack that tries to select overlapping nodes based on Ruby object type. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115984 * 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:124433] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 07 Jan '26

07 Jan '26

Issue #6012 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-45: > First, I suspect that what many users of `method_source` gem actually need is the AST. Many yes but not all, maybe even only a minority (see below). The fact there is `Method#source` indicates that some usages only want the code, and don't need to parse it. If it was all, there likely wouldn't be `Method#source`, but another method to return the (e.g. parser gem) AST directly then. A quick search shows some examples which do not use an AST: https://github.com/search?q=language%3ARuby+%2F%28method%7Cmeth%29%5C.sourc… ```ruby # spree/spree obj_method.source.squish[/(expect *({|do) *)(.*?)( *(}|end).(not_)*to)/, 3] # evilmartians/terraforming-rails, perfect use case for end_line in source_location # Uses `method_source` to get the source code and the number of lines meth.source_location.last..(meth.source_location.last + meth.source.lines.size) # pry/pry-git final_code = before_code << meth.source.lines.to_a << after_code # Darkmux/cyberspy, seems pry related, makes sense to be able to show the source of a method/block in a REPL new(meth.source, start_line, meth.source_type) # rambler-digital-solutions/rusby, the preprocessor acts on the code String, not an AST Preprocessor.apply(orig_method.source), # tdg5/tco_method code = <<-CODE #{receiver_class} #{receiver.name} #{existing_method.source} end CODE # garmoshka-mo/pry-moves, perfect use case for end_line in source_location end: (source[1] + method.source.count("\n") - 1) # SyborgStudios/overrides_tracker def self.outdented_method_body(method) body = method.source indent = body.match(/^\W+/).to_s # rpanachi/core_ext, perfect use case for end_line in source_location end_line = method.source.count("\n") + start_line - 1 # annkissam/scryglass method_lines = Hexes.capture_io { puts method.source }.split("\n") # callstacking/callstacking-rails, seems like it adds extra code to instrument, no AST, no dependency on parser method_source = method(__method__).super_method.source if settings.analyze_source? # jeromedalbert/rubocop-obsession corrector.replace(method, method.source.sub(method.method_name.to_s, 'perform')) # geni/sweatshop, perfect use case for end_line in source_location end_line = method.source.count("\n") + start_line + 1 # Auralcat/my-dotfiles # Display source code quickly in IRB. def srd(method) method.source.display end ``` and that's only the examples from the first page. In fact a majority of the matches in that first page seem to not use an AST, so I'm not even sure the majority of uses cases need the AST. Finding the `end_line` of a method seems a recurrent need, this is now provided with the extended `source_location`. --- > However, `source_location` is not an appropriate key to look up the AST subtree corresponding to a Ruby object. I believe it is though, with the knowledge of what kind of node we are looking for. For example in `def foo; bar; end`, `bar` in the AST is covered exactly by both a `StatementsNode` and a `CallNode`. If we are using `Thread::Backtrace::Location#ast` we'd want the location of the call to `bar`, so we know we want the `CallNode`, not the `StatementsNode` and there is no ambiguity. I believe the same holds for all 5 methods proposed in #21795. My intuition there is all nodes listed in https://bugs.ruby-lang.org/issues/21795#note-2 cannot have the exact same `source_location` (e.g. we cannot have code with the same starting and ending position that is two of `DefNode`, `LambdaNode`, `ForNode`, `Call*Node`, `Index*Node`, `YieldNode`). Do you have a counter-example where this wouldn't hold? In fact if #21795 is accepted I do plan to implement it in TruffleRuby based on byte offsets in the source, which are equivalent to line+column start/end. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115982 * 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