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

[ruby-core:121592] [Ruby Bug#21256] `it` value is wrapped in an array when that doesn't happen with numbered parameter
by Earlopain (Earlopain _) 18 Jul '25

18 Jul '25

Issue #21256 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21256: `it` value is wrapped in an array when that doesn't happen with numbered parameter https://bugs.ruby-lang.org/issues/21256 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have the following script: ```rb require "bundler/inline" gemfile do source "https://rubygems.org" gem "rspec-core", "3.13.3" gem "rspec-expectations", "3.13.3" end require "rspec/autorun" require "rspec/expectations" RSpec::Matchers.define :example do chain(:foo) { pp _1 } chain(:bar) { pp it } end RSpec.describe "demo" do it do example.foo(1) example.bar(2) end end ``` It calls two methods were the only difference is that one accesses the argument with `_1`, the other with `it`. It prints the following: ``` 1 [2] ``` So, `it` for some reason wraps it in an array. I appologise for the reproduction script, it uses `rspec` and the amount of metaprogramming it uses makes it impossible for me to reduce this further. When running with `parser=parse.y`, the expected output is returned (just `2`, no array). I also tested against current ruby-dev and it also happens there. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:122812] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by hsbt (Hiroshi SHIBATA) 18 Jul '25

18 Jul '25

Issue #17473 has been updated by hsbt (Hiroshi SHIBATA). Eregon (Benoit Daloze) wrote in #note-26: > That PR is actually easy to review as explained in its description, it restores pathname.rb as it used to be and includes all changes to pathname.rb since then, see https://github.com/ruby/pathname/pull/53/files/3736eab91f783cb087f873b99c25…. > IOW, it only adds code in pathname.rb and removes code in pathname.c, and then has separate commits for all other changes. > Making multiple smaller PRs does not make sense, especially since the Ruby code is just the one from before the migration to C. Please separate the small PRs. I want to reduce the side effect like https://github.com/ruby/ruby/pull/13906. And if you have another issue or proposal, please file new issue. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114099 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * 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

[ruby-core:122734] [Ruby Bug#21511] Use-after-free of the execution context after the fiber object carrying it is freed in GC
by tuonigou (tianyang sun) 17 Jul '25

17 Jul '25

Issue #21511 has been reported by tuonigou (tianyang sun). ---------------------------------------- Bug #21511: Use-after-free of the execution context after the fiber object carrying it is freed in GC https://bugs.ruby-lang.org/issues/21511 * Author: tuonigou (tianyang sun) * Status: Open * ruby -v: ruby 3.4.1 (2025-06-13 revision de8de51182) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In bootstraptest/test_thread.rb, ``` ruby assert_equal 'ok', %{ File.write("zzz_t1.rb", <<-END) begin Thread.new { fork { GC.start } }.join pid, status = Process.wait2 $result = status.success? ? :ok : :ng rescue NotImplementedError $result = :ok end END require "./zzz_t1.rb" $result } ``` ``` shell # in build/ make btest BTESTS="file_containing_above.rb" # or ruby --disable=gems "../bootstraptest/runner.rb" --ruby="./miniruby -I../lib -I. -I.ext/common -r./x86_64-linux-fake --disable-gems" file_containing_above.rb ``` Suppose **thread 1** called the `Thread.new` and created **thread 2** The forked process by thread 2 that initiates GC with `GC.start` would sweep the fiber object embedded in `RTypedData` in the `gc_sweep_rest()` stage of sweep in `fiber_free()`. That fiber object contains the execution context of thread 1, `rb_execution_context_t saved_ec` field of `cont`. Since the fiber object is freed, the allocated area pointed by it should be invalid, including the embedded struct for ec, but after thread 2 joins, thread 1 still uses the ec in rb_current_thread(), causing a use after free. -- https://bugs.ruby-lang.org/

3 9

[ruby-core:122623] [Ruby Bug#21460] Pattern matching crash: unexpected `PM_CALL_NODE`
by bendrissou (Bachir Bendrissou) 16 Jul '25

16 Jul '25

Issue #21460 has been reported by bendrissou (Bachir Bendrissou). ---------------------------------------- Bug #21460: Pattern matching crash: unexpected `PM_CALL_NODE` https://bugs.ruby-lang.org/issues/21460 * Author: bendrissou (Bachir Bendrissou) * Status: Open * ruby -v: ruby 3.5.0dev (2025-06-11 commit 970813d982) +PRISM * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, Pattern matching crashes when using an arithmetic expression like `-1**2` in a hash pattern. Ruby attempts to process the expression as a PM_CALL_NODE, which results in a compiler crash rather than a syntax or match error. ### Input ``` foo => -1**2 ``` ### Output ``` input.rb: [BUG] Unexpected node type in pattern matching expression: PM_CALL_NODE ruby 3.5.0dev (2025-06-11T18:07:43Z master 970813d982) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000720 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /lib/x86_64-linux-gnu/libasan.so.5(__interceptor_backtrace+0x40) [0x7f0716ea0d40] ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4022 /home/program/build/ruby(rb_print_backtrace+0x11) [0x55d00b05dda9] ../vm_dump.c:843 /home/program/build/ruby(rb_vm_bugreport) ../vm_dump.c:1175 /home/program/build/ruby(rb_bug_without_die_internal+0xc5) [0x55d00a720b21] ../error.c:1097 /home/program/build/ruby(rb_bug) ../error.c:1115 /home/program/build/ruby(pm_compile_pattern+0x3e76) [0x55d00aee1b46] ../prism_compile.c:3171 /home/program/build/ruby(ADD_ELEM+0x0) [0x55d00aeb2793] ../prism_compile.c:8125 /home/program/build/ruby(pm_compile_match_required_node) ../prism_compile.c:8130 /home/program/build/ruby(pm_compile_node) ../prism_compile.c:9847 /home/program/build/ruby(pm_compile_node+0x529d) [0x55d00aea7bdd] ../prism_compile.c:10330 /home/program/build/ruby(pm_compile_scope_node+0x3f42) [0x55d00aeff382] ../prism_compile.c:7012 /home/program/build/ruby(pm_compile_node+0x1b50) [0x55d00aea4490] ../prism_compile.c:10201 /home/program/build/ruby(APPEND_LIST+0x0) [0x55d00af062a4] ../prism_compile.c:10502 /home/program/build/ruby(pm_iseq_compile_node) ../prism_compile.c:10506 /home/program/build/ruby(pm_iseq_new_with_opt_try+0x3e) [0x55d00a840c5e] ../iseq.c:1050 /home/program/build/ruby(rb_protect+0x30f) [0x55d00a7343ff] ../eval.c:1059 /home/program/build/ruby(pm_iseq_new_with_opt+0x482) [0x55d00a84ec12] ../iseq.c:1103 /home/program/build/ruby(pm_iseq_new_main+0xbc) [0x55d00a84f2ac] ../iseq.c:951 /home/program/build/ruby(process_options+0x2d32) [0x55d00a9eeb12] ../ruby.c:2641 /home/program/build/ruby(ruby_process_options+0x3f0) [0x55d00a9f1290] ../ruby.c:3199 /home/program/build/ruby(ruby_options+0x2a7) [0x55d00a731407] ../eval.c:117 /home/program/build/ruby(rb_main+0x19) [0x55d00a7227ff] ../main.c:42 /home/program/build/ruby(main) ../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f07169ec083] /home/program/build/ruby(_start) [0x55d00a723dce] -- Other runtime information ----------------------------------------------- * Loaded script: input.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 set.rb Aborted ``` ### Environment Ruby version: ruby 3.5.0dev (2025-06-11 commit 970813d982) +PRISM Platform: x86_64-linux Built from source Parser backend: Prism (default) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122796] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by Eregon (Benoit Daloze) 16 Jul '25

16 Jul '25

Issue #17473 has been updated by Eregon (Benoit Daloze). hsbt (Hiroshi SHIBATA) wrote in #note-24: > >I have merged https://github.com/ruby/pathname/pull/53, it is clearly better for the maintenance of the gem at least. > > I reverted that. Please don't merge without consensus. At least, no one strongly against migrate C to Ruby in Dev Meetings. > > The transition from C to Ruby should be done gradually, in reviewable chunks. That PR is actually easy to review as explained in its description, it restores pathname.rb as it used to be and includes all changes to pathname.rb since then, see https://github.com/ruby/pathname/pull/53/files/3736eab91f783cb087f873b99c25…. IOW, it only adds code in pathname.rb and removes code in pathname.c, and then has separate commits for all other changes. Making multiple smaller PRs does not make sense, especially since the Ruby code is just the one from before the migration to C. I remade the PR as https://github.com/ruby/pathname/pull/57, please review it and share your concerns there. What is the plan for the code in the gem and the code in core? Will they be sync'd, how? From what I have seen changes in core have been done seemingly without caring about the gem, so it seemed the intention was to not sync but effectively fork? We also cannot make the gem empty in general as the gem needs to keep working on Ruby 3.4 and older at least. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114077 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * 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

[ruby-core:122795] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by Eregon (Benoit Daloze) 16 Jul '25

16 Jul '25

Issue #17473 has been updated by Eregon (Benoit Daloze). Dan0042 (Daniel DeLorme) wrote in #note-23: > I don't understand this at all. What's the problem with having `require "fileutils"` inside #mkpath ? Those dependencies are part of the stdlib anyway, so it's not like they could be missing. Is it for some reason forbidden to call `require` in a method of a core class? I had the exact same thought, this seems the obvious solution. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114076 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * 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

[ruby-core:122345] [Ruby Feature#21386] Introduce `Enumerable#join_map`
by matheusrich (Matheus Richard) 16 Jul '25

16 Jul '25

Issue #21386 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21386: Introduce `Enumerable#join_map` https://bugs.ruby-lang.org/issues/21386 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ### Problem The pattern `.map { ... }.join(sep)` is extremely common in Ruby codebases: ```ruby users.map(&:name).join(", ") ``` It’s expressive but repetitive (both logically and computationally). This pattern allocates an intermediate array and does two passes over the collection. Real-world usage is widespread: - [Open source Ruby projects using this pattern](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5… - [Within Rails](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5E%… - [Within Ruby itself](https://github.com/search?q=lang%3Aruby+%2F%5C.map%5Cs*%5C%7B%5B%5E… ### Proposal Just like `filter_map` exists to collapse a common `map + compact`, this proposal introduces `Enumerable#join_map`, which maps and joins in a single pass. ```ruby users.join_map(", ", &:name) ``` A Ruby implementation could look like this: ```ruby module Enumerable def join_map(sep = "") return "" unless block_given? str = +"" first = true each do |item| str << sep unless first str << yield(item).to_s first = false end str end end ``` The name `join_map` follows the precedent of `filter_map`, emphasizing the final operation (`join`) over the intermediate (`map`). ### Prior Art Some other languages have similar functionality, but with different names or implementations: #### Elixir Elixir has this via [the `Enum.map_join/3` function](https://hexdocs.pm/elixir/1.12/Enum.html#map_join/3): ```elixir Enum.map_join([1, 2, 3], &(&1 * 2)) "246" Enum.map_join([1, 2, 3], " = ", &(&1 * 2)) "2 = 4 = 6" ``` #### Crystal Crystal, on the other hand, [uses `Enumerable#join` with a block](https://crystal-lang.org/api/1.16.3/Enumerable.html#join%28separator…: ```crystal [1, 2, 3].join(", ") { |i| -i } # => "-1, -2, -3" ``` #### Kotlin Kotlin has a similar [function called `joinToString`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/join-to-string.html) that can take a transformation function: ```kotlin val chars = charArrayOf('a', 'b', 'c') println(chars.joinToString() { it.uppercaseChar().toString() }) // A, B, C ``` -- https://bugs.ruby-lang.org/

9 11

[ruby-core:122793] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by hsbt (Hiroshi SHIBATA) 16 Jul '25

16 Jul '25

Issue #17473 has been updated by hsbt (Hiroshi SHIBATA). >I have merged https://github.com/ruby/pathname/pull/53, it is clearly better for the maintenance of the gem at least. I reverted that. Please don't merge without consensus. At least, no one strongly against migrate C to Ruby in Dev Meetings. The transition from C to Ruby should be done gradually, in reviewable chunks. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114074 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * 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

[ruby-core:122791] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by Dan0042 (Daniel DeLorme) 16 Jul '25

16 Jul '25

Issue #17473 has been updated by Dan0042 (Daniel DeLorme). > * akr: To use the following four methods, require "pathname" is needed for a while > * find, mkpath, rmtree, mktmpdir > * rationale: they require other libraries (find gem, fileutils, tmpdir) > * in future, they (except mktmpdir) should be rewritten in pure C (or rbinc) without dependency to find and fileutils I don't understand this at all. What's the problem with having `require "fileutils"` inside #mkpath ? Those dependencies are part of the stdlib anyway, so it's not like they could be missing. Is it for some reason forbidden to call `require` in a method of a core class? ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114072 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * 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

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

8 27