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

[ruby-core:122600] [Ruby Bug#21451] Ractor.make_shareable(->{}, copy: true) raises unhelpful error
by tenderlovemaking (Aaron Patterson) 27 Jun '25

27 Jun '25

Issue #21451 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21451: Ractor.make_shareable(->{}, copy: true) raises unhelpful error https://bugs.ruby-lang.org/issues/21451 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` > ruby -e'Ractor.make_shareable(->{}, copy:true)' <internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError) from -e:1:in '<main>' ``` This error isn't very helpful and I think we can improve it. The exception happens when we call `rb_obj_clone` on the lambda. I've made a patch to improve the error message so it's like this: ``` > ./miniruby -e'Ractor.make_shareable(->{}, copy:true)' -e:1:in 'Ractor.make_shareable': cannot copy #<Proc:0x000000011f311a80 -e:1 (lambda)> (Ractor::IsolationError) from -e:1:in '<main>' -e:1:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError) from -e:1:in '<main>' ``` The patch is here: https://github.com/ruby/ruby/pull/13703 -- https://bugs.ruby-lang.org/

2 4

[ruby-core:122609] [Ruby Bug#21453] Missing rbs and rdbg binstubs - all OS's
by MSP-Greg (Greg L) 26 Jun '25

26 Jun '25

Issue #21453 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21453: Missing rbs and rdbg binstubs - all OS's https://bugs.ruby-lang.org/issues/21453 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: ruby 3.5.0dev (2025-06-26T17:18:14Z :detached: 3d5619c8b1) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As of three hours ago, see: https://github.com/ruby/ruby-dev-builder/actions/runs/15910357126/job/44875… Note that `typeprof` and `test-unit` need to be added to the CI test in ruby-dev-builder. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122242] [Ruby Feature#21365] Add `Namespace#eval`
by tenderlovemaking (Aaron Patterson) 25 Jun '25

25 Jun '25

Issue #21365 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21365: Add `Namespace#eval` https://bugs.ruby-lang.org/issues/21365 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- I would like a way to eval code on to a `Namespace` object. Could we add an eval method that _doesn't_ take a binding object? Writing a new file every time I want to test Namespaces is too cumbersome. Thanks! -- https://bugs.ruby-lang.org/

6 11

[ruby-core:122597] Your account has been set to expire
by Administrator ml.ruby-lang.org 25 Jun '25

25 Jun '25

1 0

[ruby-core:122214] [Ruby Bug#21355] `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days
by hsbt (Hiroshi SHIBATA) 24 Jun '25

24 Jun '25

Issue #21355 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21355: `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days https://bugs.ruby-lang.org/issues/21355 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced test failure of `make test-bundled-gems` in GitHub Actions. It caused by `csv` testing with `Ractor`. https://github.com/ruby/ruby/actions/runs/15156308046/job/42611877817?pr=13… ``` /home/runner/work/ruby/ruby/src/gems/src/csv/test/csv/interface/test_read.rb:56: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:370> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:3 ruby 3.5.0dev (2025-05-21T07:35:21Z pull/13391/merge 7c1f3e8f7e) [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122593] [Ruby Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 24 Jun '25

24 Jun '25

Issue #19057 has been updated by ioquatix (Samuel Williams). Status changed from Assigned to Closed The current behaviour as implemented is good enough and we can introduce new private fields in `internal/io.h`. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-113828 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Target version: 3.5 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122582] [Ruby Bug#21450] Inconsistent `upcase` between `String` and `Symbol`
by Stranger6667 (Dmitry Dygalo) 23 Jun '25

23 Jun '25

Issue #21450 has been reported by Stranger6667 (Dmitry Dygalo). ---------------------------------------- Bug #21450: Inconsistent `upcase` between `String` and `Symbol` https://bugs.ruby-lang.org/issues/21450 * Author: Stranger6667 (Dmitry Dygalo) * Status: Open * ruby -v: 3.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Behavior for `Symbol#upcase` and `String#upcase` differs for `i` character if the `:turkic` is present I'd expect `val.upcase(:turkic)` behaves consistently for both cases: ```ruby 'i'.upcase(:turkic) # "İ" with dot :i.upcase(:turkic) # :I no dot ``` However, when a non-ASCII character is present, then the mapping on `Symbol` works the same way as with `String`: ```ruby :iФ.upcase(:turkic) # :İФ # with dot ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120315] [Ruby master Bug#20968] `Array#fetch_values` unexpected method name in stack trace
by koic (Koichi ITO) 23 Jun '25

23 Jun '25

Issue #20968 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #20968: `Array#fetch_values` unexpected method name in stack trace https://bugs.ruby-lang.org/issues/20968 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-19T04:44:56Z master 2783868de2) +PRISM [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that the current Ruby implementation is displaying unexpected method name in stack trace. ## Expected Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace. ```console $ ruby -e '{k: 42}.fetch_values(:unknown)' -e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError) from -e:1:in '<main>' $ ruby -e '[1].fetch_values(42)' -e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError) from -e:1:in '<main>' ``` ## Actual The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `<internal.array>` stack trace. ```console $ ruby -e '[1].fetch_values(42)' <internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError) from <internal:array>:211:in 'block in Array#fetch_values' from <internal:array>:211:in 'Array#map!' from <internal:array>:211:in 'Array#fetch_values' from -e:1:in '<main>' ``` It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555. -- https://bugs.ruby-lang.org/

10 21

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

23 Jun '25

Issue #17473 has been updated by Eregon (Benoit Daloze). I (finally) made a PR to define most of Pathname in Ruby: https://github.com/ruby/pathname/pull/53 ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-113820 * 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

[ruby-core:122417] [Ruby Bug#21398] Ractor.select hangs when multiple threads submit heavy jobs concurrently
by arino.tamada 23 Jun '25

23 Jun '25

Issue #21398 has been reported by arino.tamada (有乃玉田). ---------------------------------------- Bug #21398: Ractor.select hangs when multiple threads submit heavy jobs concurrently https://bugs.ruby-lang.org/issues/21398 * Author: arino.tamada (有乃玉田) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When multiple threads run heavy Ractor-based jobs at the same time, `Ractor.select(*workers)` can hang indefinitely without any crash, exception, or deadlock being reported. This issue does not occur when only one thread is running similar jobs — the hang happens only when four or more threads submit large jobs concurrently to a shared Ractor pipeline. ### Steps to Reproduce Run the script below in Ruby 3.4.2 or later. In some runs, one or more threads will hang forever at Ractor.select. The issue reproduces more easily on machines with multiple cores and sufficient memory. ### Expected Behavior All calls to Ractor.select(*workers) should return when any worker Ractor yields a result. All jobs should complete. ### Actual Behavior - In some runs (especially with multiple threads), `Ractor.select` hangs and never returns. - There is no crash or exception; the process remains alive but blocked. - All Ractors and threads are created and started correctly. - This behavior does not occur when only one thread performs the same job sequentially. - It appears that `Ractor.select` does not always behave reliably under concurrent multithreaded usage with heavy Ractor pipelines. Reproducible Example: ```ruby THREADS = 4 JOBS_PER_THREAD = 10 ARRAY_SIZE = 10_000 def ractor_job(job_count, array_size) pipe = Ractor.new do loop { Ractor.yield Ractor.receive } end workers = (1..4).map do Ractor.new(pipe) do |pipe| while job = pipe.take result = job.map { |x| x * 2 }.sum Ractor.yield result end end end jobs = Array.new(job_count) { Array.new(array_size) { rand(1000) } } jobs.each { |job| pipe.send(job) } results = [] jobs.size.times do puts "Waiting for results..." _ractor, result = Ractor.select(*workers) puts "Received result: #{result}" results << result end results end threads = [] THREADS.times do threads << Thread.new do ractor_job(JOBS_PER_THREAD, ARRAY_SIZE) end end threads.each(&:join) puts "All threads finished." ``` -- https://bugs.ruby-lang.org/

2 4