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

[ruby-core:127009] [Ruby Misc#22417] DevMeeting-2026-11-12
by mame (Yusuke Endoh) 16 Oct '26

16 Oct '26

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

[ruby-core:121829] [Ruby Feature#21308] Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm
by watson1978 (Shizuo Fujita) 16 Oct '26

16 Oct '26

Issue #21308 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Feature #21308: Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm https://bugs.ruby-lang.org/issues/21308 * Author: watson1978 (Shizuo Fujita) * Status: Open ---------------------------------------- This is a feature request to replace Ruby's `Float#to_s` implementation with a modern high-performance float-to-string conversion algorithm such as Grisu. Currently, `Float#to_s` in Ruby uses the BSD-derived implementation in [missing/dtoa.c](https://github.com/ruby/ruby/blob/master/missing/dtoa.c). Meanwhile, `json` gem has adopted a Grisu-based implementation in [ruby/json#768](https://github.com/ruby/json/pull/768), it has been improve the performance of float-to-string conversion dramatically. It appears to have brought about a 10 times improvement in performance. However, the improvement is limited to the `json` gem. If we can use the same implementation in `Float#to_s`, it will introduce the improvement in all float-to-string conversion cases. (In additional, it would be better if an API could be added that could be called directly from the C extension library, it will reduce the overhead of the call.) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123146] [Ruby Bug#21559] Unicode normalization nfd -> nfc -> nfd is not reversible
by tompng (tomoya ishida) 16 Oct '26

16 Oct '26

Issue #21559 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21559: Unicode normalization nfd -> nfc -> nfd is not reversible https://bugs.ruby-lang.org/issues/21559 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I expect `nfd(nfc(str)) == nfd(str)` but found a string that doesn't. ~~~ruby # Ruby 3.1 - 3.5 str = "s\u{11930}\u{323}\u{11930}\u{307}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ ~~~ruby # ruby 3.5.0dev str = "s\u{1611e}\u{323}\u{1611e}\u{307}\u{1611f}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ -- https://bugs.ruby-lang.org/

5 8

[ruby-core:127140] [Ruby Bug#22450] Jump value attaches block in incorrect place under parse.y
by kddnewton (Kevin Newton) 16 Oct '26

16 Oct '26

Issue #22450 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22450: Jump value attaches block in incorrect place under parse.y https://bugs.ruby-lang.org/issues/22450 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Sorry about this one. The following code: `check 1, if true then return foo + bar do end end` under Prism: ``` -e: warning: argument of top-level return is ignored == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,49)> 0000 putself ( 1)[Li] 0001 putobject_INT2FIX_1_ 0002 adjuststack 2 0004 putself 0005 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0007 putself 0008 send <calldata!mid:bar, argc:0, FCALL>, block in <main> 0011 opt_plus <calldata!mid:+, argc:1, ARGS_SIMPLE>[CcCr] 0013 leave [Re] 0014 putnil 0015 opt_send_without_block <calldata!mid:check, argc:2, FCALL|ARGS_SIMPLE> 0017 leave == disasm: #<ISeq:block in <main>@-e:1 (1,39)-(1,45)> 0000 putnil ( 1)[Bc] 0001 leave [Br] ``` but under parse.y: ``` -e: warning: argument of top-level return is ignored == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,49)> 0000 putself ( 1)[Li] 0001 putobject_INT2FIX_1_ 0002 adjuststack 2 0004 putself 0005 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0007 putself 0008 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0010 send <calldata!mid:+, argc:1>, block in <main> 0013 leave [Re] 0014 putnil 0015 opt_send_without_block <calldata!mid:check, argc:2, FCALL|ARGS_SIMPLE> 0017 leave == disasm: #<ISeq:block in <main>@-e:1 (1,39)-(1,45)> 0000 putnil ( 1)[Bc] 0001 leave [Br] ``` The block is getting attached to the `+` operation. I think the problem with this is that when a block is found after a jump, parse.y blindly attaches the block to whatever it finds in the value position. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126381] [Ruby Feature#22244] `ruby -UU` should set both internal and external, `ruby -E` should print encoding list
by zenspider (Ryan Davis) 16 Oct '26

16 Oct '26

Issue #22244 has been reported by zenspider (Ryan Davis). ---------------------------------------- Feature #22244: `ruby -UU` should set both internal and external, `ruby -E` should print encoding list https://bugs.ruby-lang.org/issues/22244 * Author: zenspider (Ryan Davis) * Status: Open ---------------------------------------- ``` 10004 $ env -u LANG ruby -U -e 'pp [Encoding.default_internal, Encoding.default_external]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] 10005 $ env -u LANG ruby -EUTF-8 -e 'pp [...]' [nil, #<Encoding:UTF-8>] 10006 $ env -u LANG ruby -EUTF-8 -U -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10007 $ env -u LANG ruby -EUTF-8:UTF-8 -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10008 $ env -u LANG ruby -UU -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] ``` I think the option processing of encodings is VERY poorly documented and frustrating to try to use. 1. --help doesn't list -U. (The man page does) 2. --help for -E doesn't provide a means to get a list of available encoding names (same with manpage), leading me to try U, UTF8, UTF_8, before finding UTF-8. `ruby -E` could just print them all out. 3. WHY NOT take UTF8 or UTF_8 (since that's the class name)? 4. Please consider `-UU` to mean `-EUTF-8:UTF-8` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:127137] [Ruby Bug#22449] Out-of-bounds in `Array#sample` when array modified
by nobu (Nobuyoshi Nakada) 16 Oct '26

16 Oct '26

Issue #22449 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22449: Out-of-bounds in `Array#sample` when array modified https://bugs.ruby-lang.org/issues/22449 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Backports required: [GH-18879] and [GH-19047] Also cases where array modified within the `rand` method. [GH-18879]: https://github.com/ruby/ruby/pull/18879 [GH-19047]: https://github.com/ruby/ruby/pull/19047 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127136] [Ruby Bug#22448] Jump value with a command call with a method call chained
by kddnewton (Kevin Newton) 15 Oct '26

15 Oct '26

Issue #22448 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22448: Jump value with a command call with a method call chained https://bugs.ruby-lang.org/issues/22448 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is a little bit odd, found this while fuzzing Prism. Right now, parse.y raises a void value expression error for a method call on a parenthesized jump, as in: ```ruby def m; (return foo 1 do end).bar; end ``` but if you get rid of the parentheses it says it's good to go, and compiles unreachable code: ``` $ ruby --parser=parse.y --dump=insns -e 'def m; return foo 1 do end.bar; end' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,35)> 0000 definemethod :m, m ( 1)[Li] 0003 putobject :m 0005 leave == disasm: #<ISeq:m@-e:1 (1,0)-(1,35)> 0000 putself ( 1)[LiCa] 0001 putobject_INT2FIX_1_ 0002 send <calldata!mid:foo, argc:1, FCALL>, block in m 0005 leave [Re] 0006 putnil 0007 opt_send_without_block <calldata!mid:bar, argc:0, ARGS_SIMPLE> 0009 leave [Re] == disasm: #<ISeq:block in m@-e:1 (1,20)-(1,26)> 0000 putnil ( 1)[Bc] 0001 leave [Br] ``` The parse tree actually attaches the block to the return itself. The same thing happens with break and next, with ., &. and ::, and with arguments on the chained call: ``` $ ruby --parser=parse.y -ce 'loop { break foo 1 do end.bar }' # Syntax OK $ ruby --parser=parse.y -ce 'loop { next foo 1 do end.bar }' # Syntax OK $ ruby --parser=parse.y -ce 'def m; return foo 1 do end&.bar; end' # Syntax OK $ ruby --parser=parse.y -ce 'def m; return foo 1 do end::bar; end' # Syntax OK $ ruby --parser=parse.y -ce 'def m; return foo 1 do end.bar 2; end' # Syntax OK $ ruby --parser=parse.y -ce 'loop { (break foo do end).bar }' # void value expression ``` I think all of these should be void value expressions since they're just compiling dead code. For context, Prism has been parsing those chains within the jump, so they get called before their result is thrown, which is inconsistent. So we could also just do that in parse.y instead. I'm fine with either solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126364] [Ruby Bug#22240] Protect against SEGV caused by native extensions using rb_funcall between rb_protect and rb_jump_tag
by rwstauner (Randy Stauner) 15 Oct '26

15 Oct '26

Issue #22240 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22240: Protect against SEGV caused by native extensions using rb_funcall between rb_protect and rb_jump_tag https://bugs.ruby-lang.org/issues/22240 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- It's possible for native extensions do something like int state = 0; rb_protect(some_func, Qnil, &state); if (state) { rb_funcall(self, rb_intern("handler"), 0); rb_jump_tag(state); } If the ruby code in the rb_funcall has a rescue clause it will clear errinfo. When rb_jump_tag flows to hook_before_rewind with errinfo as Qnil it currently will SEGV. If I add a check to avoid the SEGV, the process then exits silently. If a native extension puts us in this state, the original message is gone. One thing we can do is detect this scenario and fabricate an exception. I have a PR up with a possible solution for this but am looking for feedback on the exception type and message or alternative suggestions for handling. I have reproduced this crash as far back as Ruby 3.3. -- https://bugs.ruby-lang.org/

1 4

[ruby-core:127104] [Ruby Bug#22439] Segfault in `Thread::Backtrace::Location#syntax_tree` (via `Exception#detailed_message` / error_highlight) when called from multiple Ractors
by amalrik (amalrik maia) 15 Oct '26

15 Oct '26

Issue #22439 has been reported by amalrik (amalrik maia). ---------------------------------------- Bug #22439: Segfault in `Thread::Backtrace::Location#syntax_tree` (via `Exception#detailed_message` / error_highlight) when called from multiple Ractors https://bugs.ruby-lang.org/issues/22439 * Author: amalrik (amalrik maia) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-14T14:33:24Z master b709bdb3e3) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Calling `Exception#detailed_message` concurrently from two or more Ractors crashes the VM with `[BUG] Segmentation fault` on 4.1.0-preview1 and current master. The same script works on 4.0.6 and 4.0.7. ### Reproduction No gems are involved; error_highlight is loaded by default. ```ruby n = Integer(ARGV[0] || 2) rs = Array.new(n) do |i| Ractor.new(i) do |id| 500.times do |k| begin raise ArgumentError, "falha #{id}-#{k}" rescue => e e.detailed_message(highlight: false) end end :ok end end p rs.map(&:value) ``` ``` $ ruby repro.rb <internal:ast>:374: [BUG] Segmentation fault at 0x0000000000000030 ``` | Version | Result | | ---------------------------- | ------------------------------------------------------------ | | 4.0.6, 4.0.7 | `[:ok, :ok]` (8/8 runs) | | 4.1.0-preview1 (2d08b5f42f) | segfault in 4/4 runs with 2 Ractors and 8/8 with 8 Ractors; no crash with 1 Ractor | | 4.1.0dev master (b709bdb3e3) | segfault 6/6 | ### Backtrace (master) ``` <internal:ast>:374: [BUG] Segmentation fault at 0x0000000000000030 -- Ruby level backtrace information ---------------------------------------- repro.rb:8:in 'detailed_message' .../lib/ruby/4.1.0+5/error_highlight/core_ext.rb:43:in 'detailed_message' .../lib/ruby/4.1.0+5/error_highlight/core_ext.rb:34:in 'generate_snippet' .../lib/ruby/4.1.0+5/error_highlight/base.rb:57:in 'spot' .../lib/ruby/4.1.0+5/error_highlight/base.rb:77:in 'find_node_from_loc' <internal:ast>:478:in 'syntax_tree' <internal:ast>:374:in 'syntax_tree' -- C level backtrace information ------------------------------------------- rb_vm_bugreport rb_ec_ractor_ptr / rb_current_execution_context / rb_current_ractor_raw / rb_current_ractor vm_ic_update rb_vm_opt_getconstant_path vm_exec_core rb_vm_exec thread_start_func_2 ``` The full output is attached (`crash-output-master.txt`). ### Additional observations 1. **The crash is reachable without error_highlight.** Calling `e.backtrace_locations.first.syntax_tree` inside `rescue` in 2 Ractors gives the same crash and stack. It crashed 1/3 runs on master and 0/3 on preview1, so the `detailed_message` script above is the more reliable reproducer. 2. **Some things that look similar do not crash.** - `caller_locations(0, 1).first.syntax_tree` in 2 Ractors works. - `Ruby::Prism.parse("1 + 1")` in 2 Ractors works. So the problem seems specific to backtrace locations taken from an exception, while the constant cache in `ast.rb` is updated from a non-main Ractor. 3. **With a single Ractor there is no crash, but error_highlight output regresses.** Inside the Ractor, `detailed_message` returns only the message, without the snippet: ```ruby r = Ractor.new do begin nil.upcase rescue => e e.detailed_message(highlight: false) end end puts r.value # 4.0.7: undefined method 'upcase' for nil (NoMethodError)\n\n nil.upcase\n ^^^^^^^ # 4.1: undefined method 'upcase' for nil (NoMethodError) ``` On 4.1 the snippet is still shown in the main Ractor. 4. **This is easy to hit in practice.** Any library that logs exceptions with `detailed_message` from inside Ractors can crash the process. I found it with the `async` gem, whose task-failure logging (via the `console` gem) calls `detailed_message`, running one reactor per Ractor. On 4.0.6 that same setup hangs instead of crashing; I have not diagnosed the 4.0.6 hang. ### Related (but different) issues - #22386: segfault when a Ractor helper thread reports an exception during teardown. It was fixed before preview1, and this still reproduces on preview1 and master. - #21183: error_highlight raising `Ractor::IsolationError` in non-main Ractors (fixed in 2025). ### Environment and context - Linux x86_64 (kernel 7.2, AMD Ryzen 7 5700U, 8C/16T). Also seen on Ubuntu 24.04, AMD EPYC Genoa (KVM). - These scripts come out of a benchmark study comparing threads, Ractors and Fibers on Ruby 4.0 and 4.1. The code, raw results and other Ractor findings (I/O concurrency cap on 4.0.x, socket hangs on 4.0.x) are public at: https://github.com/amalrik/ruby-ractors-study. The reproducers for this issue are in `upstream/ruby-4.1-detailed-message-ractors/` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:127109] [Ruby Feature#22441] Add Ractor#alive?
by jhawthorn (John Hawthorn) 14 Oct '26

14 Oct '26

Issue #22441 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22441: Add Ractor#alive? https://bugs.ruby-lang.org/issues/22441 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- I propose adding `Ractor#alive?` as a non-blocking way to ask whether a Ractor has finished. This matches `Thread#alive?`/`Fiber#alive?`. ``` r = Ractor.new { Ractor.receive } r.alive? #=> true r << :done r.join r.alive? #=> false ``` This is already somewhat visible via `Ractor#inspect`, but that's quite awkward. We use this in the test suite. ``` r = Ractor.new{ sleep 1 } r.inspect #=> "#<Ractor:#3 (irb):4 running>" sleep 2 r.inspect #=> "#<Ractor:#3 (irb):4 terminated>" ``` After fork, other Ractors `alive?` will return false, as with `Thread#alive?`. -- https://bugs.ruby-lang.org/

2 1