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

[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) 10 Jul '25

10 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:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 10 Jul '25

10 Jul '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/

20 73

[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:122552] [Ruby Feature#21442] Make tsort to bundled gems
by hsbt (Hiroshi SHIBATA) 10 Jul '25

10 Jul '25

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 2