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

[ruby-core:122658] [Ruby Feature#21501] Include native filenames in backtraces as sources for native methods
by ivoanjo (Ivo Anjo) 11 Jul '25

11 Jul '25

Issue #21501 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Feature #21501: Include native filenames in backtraces as sources for native methods https://bugs.ruby-lang.org/issues/21501 * Author: ivoanjo (Ivo Anjo) * Status: Open ---------------------------------------- Consider this example: ```ruby require 'bigdecimal' BigDecimal.singleton_class.prepend( Module.new do def save_rounding_mode super end end ) [:example].each do BigDecimal.save_rounding_mode do puts caller sleep 1 end end ``` which Ruby will print as (from 3.4, since https://bugs.ruby-lang.org/issues/19117) ``` native-filenames-example.rb:6:in 'BigDecimal.save_rounding_mode' native-filenames-example.rb:6:in 'save_rounding_mode' native-filenames-example.rb:12:in 'block in <main>' native-filenames-example.rb:11:in 'Array#each' native-filenames-example.rb:11:in '<main>' ``` Having the class names helps, but I think this behavior can still be confusing. Without looking at the code, and understanding that `Array#each` and `BigDecimal.save_rounding_mode` are written in native code, it can be confusing to see them be assigned to `native-filenames-example.rb` in the backtrace. I would like to propose that, whenever possible (see notes below), Ruby shows the name of the native filename where a method was defined. This would result on the backtrace becoming: ``` /rvm/gems/ruby-3.4.4/gems/bigdecimal-3.2.2/lib/bigdecimal.so:0:in 'BigDecimal.save_rounding_mode' native-filenames-example.rb:6:in 'save_rounding_mode' native-filenames-example.rb:12:in 'block in <main>' /rvm/rubies/ruby-3.4.4/lib/libruby.so.3.4:0:in 'Array#each' native-filenames-example.rb:11:in '<main>' ``` or, alternatively, this mechanism could be applied only to extensions, not to libruby/the ruby binary (it's not particularly hard to detect and exclude it): ``` /rvm/gems/ruby-3.4.4/gems/bigdecimal-3.2.2/lib/bigdecimal.so:0:in 'BigDecimal.save_rounding_mode' native-filenames-example.rb:6:in 'save_rounding_mode' native-filenames-example.rb:12:in 'block in <main>' native-filenames-example.rb:11:in 'Array#each' # Don't touch array ;) native-filenames-example.rb:11:in '<main>' ``` This would make it even easier to understand what's coming from where, and I believe it's a great complement to showing the class names. Furthermore, displaying the actual native libraries matches really well with the semantics we get for regular Ruby files: if I were to look on my machine, I would see `/rvm/gems/ruby-3.4.4/gems/bigdecimal-3.2.2/lib/bigdecimal.so` and `/rvm/rubies/ruby-3.4.4/lib/libruby.so.3.4`. And if I moved them, or overrode them, and loaded them from a different path, I would see the difference. (I say this because in the past I've thought about displaying the actual source .c files and lines, but that a) requires debug information; and b) the files often no longer exist in the filesystem; c) is much harder to implement cross-os). --- The extra cool thing is that this is really, really easy to implement! I actually created a [micro gem to show this off](https://github.com/ivoanjo/native-filenames/blob/main/ext/native_filen… as [well as added this as a feature to the Datadog Ruby profiler](https://github.com/DataDog/dd-trace-rb/pull/4745). Other than checking for headers and whatnot, fetching the info can be implemented in 41 lines of C: https://github.com/ivoanjo/native-filenames/blob/main/ext/native_filenames_… and works in Linux, macOS and Windows! The way it works is, we can use the function pointer passed to `rb_define_method`, looking it put using `dladdr` (or some of the other variants shown in the code). Then, given just the function pointer, we can get a path back. It's as simple as that -- it can be added transparently as part of storing the cfunc. And if for some reason the path is not available, we could fall back to the current behavior. I'd be very happy to contribute a PR to make this change, but I decided to start with a proposal first as I realize not everyone may be as excited about this idea as I am ;) -- https://bugs.ruby-lang.org/

5 9

[ruby-core:122618] [Ruby Feature#21459] Add Set C-API
by jeremyevans0 (Jeremy Evans) 11 Jul '25

11 Jul '25

Issue #21459 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21459: Add Set C-API https://bugs.ruby-lang.org/issues/21459 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- I would like to add a minimal C-API for Set: ```c void rb_set_foreach(VALUE set, int (*func)(VALUE element, VALUE arg), VALUE arg); VALUE rb_set_new(void); VALUE rb_set_new_capa(unsigned long capa); bool rb_set_lookup(VALUE set, VALUE element); bool rb_set_add(VALUE set, VALUE element); VALUE rb_set_clear(VALUE set); bool rb_set_delete(VALUE set, VALUE element); size_t rb_set_size(VALUE set); ``` I think this should allow extension libraries to start benefiting from core Set without having to resort to method calls (dangerous in an C extension as they could be redefined to return objects of an unexpected type). I've submitted a pull request for this: https://github.com/ruby/ruby/pull/13735 -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122722] [Ruby Bug#21507] Regexp considers variable repetition quantifiers invalid in lookbehind
by tiago-macedo (Tiago Macedo) 11 Jul '25

11 Jul '25

Issue #21507 has been reported by tiago-macedo (Tiago Macedo). ---------------------------------------- Bug #21507: Regexp considers variable repetition quantifiers invalid in lookbehind https://bugs.ruby-lang.org/issues/21507 * Author: tiago-macedo (Tiago Macedo) * Status: Open * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This is my first bug subscription, please feel free to tell me if I can do anything better. # Description Attempting to use "variable" repetition quantifiers (`?`, `+`,`*`,`{n,}`, ...) inside lookbehind anchors raises a **SyntaxError** (invalid pattern in look-behind), but it's perfectly viable to do it in lookafter anchors. Examples of lookafter working: ```ruby irb(main):100> "axb".split /(?=x)/ => ["a", "xb"] irb(main):101> "axb".split /(?=x?)/ => ["a", "x", "b"] irb(main):102> "axb".split /(?=x+)/ => ["a", "xb"] irb(main):103> "axb".split /(?=x*)/ => ["a", "x", "b"] irb(main):104> "axb".split /(?=x{1,})/ => ["a", "xb"] irb(main):105> "axb".split /(?=x{,1})/ => ["a", "x", "b"] irb(main):106> "axb".split /(?=x{1,2})/ => ["a", "xb"] ``` Examples of lookbehind **working only with non-variable metacharacters**: ```ruby irb(main):107> "axb".split /(?<=x)/ => ["ax", "b"] irb(main):108> "axb".split /(?<=x?)/ /var/lib/gems/3.0.0/gems/irb-1.14.0/exe/irb:9:in `<top (required)>': (irb):108: invalid pattern in look-behind: /(?<=x?)/ (SyntaxError) from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):109> "axb".split /(?<=x*)/ /var/lib/gems/3.0.0/gems/irb-1.14.0/exe/irb:9:in `<top (required)>': (irb):109: invalid pattern in look-behind: /(?<=x*)/ (SyntaxError) from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):110> "axb".split /(?<=x{1,})/ /var/lib/gems/3.0.0/gems/irb-1.14.0/exe/irb:9:in `<top (required)>': (irb):110: invalid pattern in look-behind: /(?<=x{1,})/ (SyntaxError) from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):111> "axb".split /(?<=x{,1})/ /var/lib/gems/3.0.0/gems/irb-1.14.0/exe/irb:9:in `<top (required)>': (irb):111: invalid pattern in look-behind: /(?<=x{,1})/ (SyntaxError) from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):112> "axb".split /(?<=x{1,2})/ /var/lib/gems/3.0.0/gems/irb-1.14.0/exe/irb:9:in `<top (required)>': (irb):112: invalid pattern in look-behind: /(?<=x{1,2})/ (SyntaxError) from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' irb(main):113> "axb".split /(?<=x{1})/ => ["ax", "b"] irb(main):114> "axb".split /(?<=x{1,1})/ => ["ax", "b"] ``` # Note I have searched on the internet and, to my knowledge, this behavior is not intended. (This documentation page on regular expressions)[https://ruby-doc.org/core-3.1.0/doc/regexp_rdoc.html], for example, does not say anything about limitations specific to lookbehinds. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122610] [Ruby Feature#21454] "undefined method 'break' for an instance of Binding"
by vo.x (Vit Ondruch) 10 Jul '25

10 Jul '25

Issue #21454 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #21454: "undefined method 'break' for an instance of Binding" https://bugs.ruby-lang.org/issues/21454 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- Running my code with `rdbg` and using `binding.break`, it is a bit unfortunate that subsequently running the code without `rdbg`, it fails with error such as: ~~~ NoMethodError: undefined method 'break' for an instance of Binding ~~~ Could this method become no-op if the `rdbg` is not loaded? If there was some concern about this, then it could print some helpful warning or what not. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122613] [Ruby Bug#21456] IO.close does not work in a IO::TimeoutError block.
by dE (dE Techno) 10 Jul '25

10 Jul '25

Issue #21456 has been reported by dE (dE Techno). ---------------------------------------- Bug #21456: IO.close does not work in a IO::TimeoutError block. https://bugs.ruby-lang.org/issues/21456 * Author: dE (dE Techno) * Status: Open * ruby -v: ruby 3.2.8 (2025-03-26 revision 13f495dc2c) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Invoking the close method on an IO object based on popen will forcefully close the process (not sure what signal it sends, it's undocumented), however when you handle a IO::TimeoutError exception (which you can get when you set .timeout), the close method fails to end the process. It's going to block until the process naturally terminates. Sample code (linux based) -- execArg = 'echo testwrite; sleep 10' tofuProcess = IO.popen(execArg, 'r') puts 'executed tofu process.' tofuProcess.timeout=5 begin tofuOut = tofuProcess.read rescue IO::TimeoutError puts 'rescue occured' tofuProcess.close puts 'process closed' end -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122506] [Ruby Feature#21435] Kernel#optional as a conditional #then
by Alexander.Senko (Alexander Senko) 10 Jul '25

10 Jul '25

Issue #21435 has been reported by Alexander.Senko (Alexander Senko). ---------------------------------------- Feature #21435: Kernel#optional as a conditional #then https://bugs.ruby-lang.org/issues/21435 * Author: Alexander.Senko (Alexander Senko) * Status: Open ---------------------------------------- When chaining, I need sometimes to apply some changes conditionally, like this: ```ruby @record = Record.find(record_id) .then { it.respond_to?(:decorate) ? it.decorate : it } ``` It would be great to DRY it a bit: ```ruby @record = Record.find(record_id) .optional { it.decorate if it.respond_to? :decorate } ``` Reference implementation: ```ruby # Yields self to the block and returns the result of the block if it’s # truthy, and self otherwise. def optional tap do result = yield(self) or next break result end end ``` The name is discussible. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:122604] [Ruby Bug#21452] ARGS_SPLAT bytecode regression between 3.3 and 3.4
by tekknolagi (Maxwell Bernstein) 10 Jul '25

10 Jul '25

Issue #21452 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Bug #21452: ARGS_SPLAT bytecode regression between 3.3 and 3.4 https://bugs.ruby-lang.org/issues/21452 * Author: tekknolagi (Maxwell Bernstein) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Ruby 3.3, `f(1, 2, *[3, 4])` splats all arguments to the stack and uses `ARGS_SIMPLE`: ``` plum% ruby --version ruby 3.3.2 (2024-05-30 revision e5a195edf6) [arm64-darwin24] plum% ruby --dump=insns -e 'f(1, 2, *[3, 4])' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,16)> 0000 putself ( 1)[Li] 0001 putobject_INT2FIX_1_ 0002 putobject 2 0004 putobject 3 0006 putobject 4 0008 opt_send_without_block <calldata!mid:f, argc:4, FCALL|ARGS_SIMPLE> 0010 leave plum% ``` On Ruby 3.4, the same expression results in creating a new array and using `ARGS_SPLAT`: ``` plum% ruby --version ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] plum% ruby --dump=insns -e 'f(1, 2, *[3, 4])' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,16)> 0000 putself ( 1)[Li] 0001 putobject_INT2FIX_1_ 0002 putobject 2 0004 duparray [3, 4] 0006 opt_send_without_block <calldata!mid:f, argc:3, ARGS_SPLAT|FCALL> 0008 leave plum% ``` I think we should keep the behavior of 3.3. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122612] [Ruby Feature#21455] Add a block argument to Array#join
by leoarnold (Leo Arnold) 10 Jul '25

10 Jul '25

Issue #21455 has been reported by leoarnold (Leo Arnold). ---------------------------------------- Feature #21455: Add a block argument to Array#join https://bugs.ruby-lang.org/issues/21455 * Author: leoarnold (Leo Arnold) * Status: Open ---------------------------------------- I sometimes come across code like this where the `Array#join` at the end can easily be overlooked or stands out like a sore thumb: ```ruby hex_string = string.bytes.map do |byte| format('%02X', byte) end.join(' ') ``` It seems idiomatic and more succinct to pass the block to `Array#join` directly: ```ruby hex_string = string.bytes.join(' ') do |byte| format('%02X', byte) end ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122708] [Ruby Feature#4539] Array#zip_with
by matz (Yukihiro Matsumoto) 10 Jul '25

10 Jul '25

Issue #4539 has been updated by matz (Yukihiro Matsumoto). Status changed from Assigned to Rejected I don't think it's worth adding a new method. Matz. ---------------------------------------- Feature #4539: Array#zip_with https://bugs.ruby-lang.org/issues/4539#change-113985 * Author: citizen428 (Michael Kohl) * Status: Rejected * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Inspired by Haskell's `zipWith` function, I hacked on together for Ruby: ```ruby [1,2,3].zip_with([6,5,4], :+) #=> [7, 7, 7] [1,2,3].zip_with([6,5,4]) { |a,b| 3*a+2*b } #=> [15, 16, 17] ``` So far I only have a Ruby version of it: https://gist.github.com/731702b90757e21cadcb My questions: 1. Would this method be considered a worthwhile addition to `Array`? 2. I've never hacked on the C side of Ruby (read some parts of the source though) and my C is quite rusty. I'd like to change that, would somebody be willing to help me turn this into a proper patch? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122703] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by matz (Yukihiro Matsumoto) 10 Jul '25

10 Jul '25

Issue #17473 has been updated by matz (Yukihiro Matsumoto). Regarding the original proposal, I'd accept making Pathname built-in, considering its wide accepting among the community, especially with Rails. Whether to keep the built-in Pathname in the C implementation or implement it in Ruby is left for future discussion. Matz. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-113980 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0