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

[ruby-core:126653] [Ruby Bug#22305] Ruby::Box: statically linked prism loads in only one box
by hsbt (Hiroshi SHIBATA) 11 Sep '26

11 Sep '26

Issue #22305 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22305: Ruby::Box: statically linked prism loads in only one box https://bugs.ruby-lang.org/issues/22305 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, the statically linked prism can be required in only one box. The second box raises `LoadError`. ``` $ RUBY_BOX=1 ruby --disable-gems -e 'require "prism"; p Ruby::Box.new.eval(%q{require "prism"; Prism::VERSION})' lib/prism.rb:161:in 'Kernel#require': cannot load such file -- prism/prism (LoadError) ``` Swapping the order fails the same way. `--disable-gems` matters here. With a prism gem installed, each box dlopens its own copy of the gem's `prism.bundle` and the problem disappears, which makes it easy to miss. There is no `prism.so` file. `prism_init.c:8` registers the name `prism/prism.so` with `ruby_init_ext`, pointing at the `Init_prism` already linked into the interpreter, so `require "prism/prism"` behaves as if it had loaded an extension. That entry can be used only once (`load.c:1280`). The parser itself works in every box, but loading a gem that requires prism internally, such as error_highlight, is enough to break it in every box other than the one that loaded prism first. The obvious fixes do not hold. Running the init in every box leaves one set of C globals pointing at whichever box ran it last, so nodes parsed in the other box fail `is_a?(Prism::ProgramNode)`. That trades the `LoadError` for a silent type mismatch. Initializing prism before the boxes exist and marking the feature provided makes the `require "prism/prism"` inside an activated prism gem a no-op, so the gem's Ruby half binds to the interpreter's C half. The `ruby-lsp` benchmark fails on exactly that. I see three designs and would like one chosen. The first treats prism as an extension. The Ruby binding is built as its own shared object while the parser stays static, so each box dlopens its own copy the way it already does for other extensions. The same principle would also fix every extension under `--with-static-linked-ext`. It changes the build and needs symbol exports on Windows. The second treats it as part of the interpreter, like `String`. It is initialized once before the boxes and every box shares its classes. `defined?(Prism)` becomes true without a `require`, it adds 339 classes at boot, and a prism gem can no longer take over. The third changes Box instead. One way would be to share a statically linked extension across boxes like a builtin class without marking it provided, so that a prism gem can still take over, though I am not sure that fits where Box is heading. ## How prism came to ship this way #19741 mirrored YARP into ruby/ruby together with its Ruby API and registered the native part with `ruby_init_ext`. #19772 then moved toward mirroring only the C implementation and leaving the Ruby API to a bundled prism gem (#19772#note-29), and #19900 stated that prism would be a bundled gem with a native extension. The static registration from #19741 survived the rename, so prism ships as a default gem linked into the interpreter, and that registration is what fails here. The native extension #19900 described works in every box, and the first design comes down to it. The second design has a history of its own. Matz first approved a built-in `Ruby::Parser` that no gem could replace (#19772#note-9), and the same idea came back as a gem-independent `Ruby::Node` for `Proc#syntax_tree` (#21795#note-1). There Matz required that the parser that ran the program and the parser that returns the tree be the same (#21795#note-19), and the feature settled on the default gem prism for that. That is exactly the prism a second box cannot load, which also blocks the way #21795#note-38 suggested Box could eventually expose the interpreter's own parser. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125416] [Ruby Feature#22056] Add zero-copy String constructor backed by an arbitrary Ruby object
by himura467 (Akito Shitara) 11 Sep '26

11 Sep '26

Issue #22056 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22056: Add zero-copy String constructor backed by an arbitrary Ruby object https://bugs.ruby-lang.org/issues/22056 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ### Description Ruby has rich built-in functionality for working with byte sequences through `String`. Objects that manage their own byte buffers naturally want to expose their data through this interface. The straightforward approach is `rb_str_new()`, which copies the bytes: ``` c VALUE str = rb_str_new(str, len); ``` For large or frequently accessed buffers this copy is wasteful in both time and memory. One approach is to create a String that directly references the existing memory, with the GC keeping the owner alive for as long as the String is reachable. This avoids both the copy and the need for manual lifetime management. ### Existing APIs and their limitations | API | Memory behavior | | ---- | ---- | | `rb_str_new` / `rb_str_new_cstr` | Copies bytes; String owns the allocation | | `rb_str_new_shared` / `rb_str_new_frozen` | References another String's buffer; parent must be a String | | `rb_str_new_static` | References static (compile-time) storage; no lifetime management | `rb_str_new_static` avoids copying but is only safe for storage that lives forever. When memory is owned by a Ruby object, it is freed when that object is collected, and `rb_str_new_static` offers no way to express that dependency. The common workaround is to pin the owner via an instance variable: ``` c VALUE str = rb_str_new_static(str, len); rb_ivar_set(str, id_owner, owner); ``` This relies on undocumented GC behavior, incurs ivar table allocation overhead, and leaves lifetime management entirely to the caller. ### Proposal Add zero-copy String constructors that accept an explicit parent object. The proposed names are tentative and open for discussion (see below): ``` c VALUE rb_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_usascii_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_utf8_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_enc_str_new_external(const char *ptr, long len, rb_encoding *enc, VALUE parent); ``` `parent` can be any live Ruby object. The GC guarantees it is not collected before the returned String is. `ptr` must point into memory whose lifetime is tied to `parent`; no copy is made. ### Use cases *IO::Buffer#get_string* `IO::Buffer.for(string)` wraps a String's bytes in a READONLY EXTERNAL buffer. `IO::Buffer#get_string` now copies those bytes into a new String. With this API, the returned String can reference the source String directly: ``` c return rb_enc_str_new_external((const char *)base + offset, length, encoding, buffer->source); ``` The returned String holds a direct GC reference to the source String, so it remains valid even after the buffer is freed. *GLib::Bytes#to_s (ruby-gnome)* `GLib::Bytes` is an immutable, reference-counted byte buffer from GLib. The current [implementation](https://github.com/ruby-gnome/ruby-gnome/blob/1dad74d1a86f9… uses the ivar workaround: ``` c VALUE str = rb_str_new_static(data, size); rb_iv_set(str, "@bytes", self); ``` With the proposed API this becomes: ``` c return rb_str_new_external(data, size, self); ``` ### Open questions *Naming* The name `rb_str_new_external` is one option. Other candidates: * `rb_str_new_owned_by` / `rb_enc_str_new_owned_by` * `rb_str_new_pinned` / `rb_enc_str_new_pinned` * `rb_str_new_with_parent` / `rb_enc_str_new_with_parent` *Memory retention* When a String referencing a small slice of a large buffer remains reachable, the entire backing object is kept alive. This is the same concern that led Java to remove the shared-backing optimization from `String.substring()` in Java 7. The risk was also raised in the context of Ruby's own lazy substring proposal (#19315, https://bugs.ruby-lang.org/issues/19315#note-7) > I heard that Java stopped the shared substring technique 10 years ago (https://www.infoq.com/news/2013/12/Oracle-Tunes-Java-String/) because of the potential for memory leaks > > I don't disagree this proposal, but it would be nice if we could evaluate the effectiveness of this optimization. Whether the same concern applies to this proposal, and whether the API should offer a way to force an independent copy, is worth discussing. ### Proof of concept A prototype implementation is at: https://github.com/ruby/ruby/pull/16834 The implementation introduces a new flag on non-embedded strings and stores the parent reference in `RString.as.heap.aux.parent`. The GC mark phase pins embedded parent strings to prevent compaction from invalidating the raw pointer stored in the zero-copy child. -- https://bugs.ruby-lang.org/

7 28

[ruby-core:126651] [Ruby Feature#13677] Add more details to error "Name or service not known (SocketError)"
by akr (Akira Tanaka) 11 Sep '26

11 Sep '26

Issue #13677 has been updated by akr (Akira Tanaka). The current patch, which adds 'rb_str_catf(msg, " %+"PRIsVALUE, host);' is fine. ---------------------------------------- Feature #13677: Add more details to error "Name or service not known (SocketError)" https://bugs.ruby-lang.org/issues/13677#change-118909 * Author: dsbonev (Dimitar Bonev) * Status: Open ---------------------------------------- ruby version: `ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]` ruby script: ~~~ ruby require 'socket' TCPSocket.new 'nonexistent.example.com', 80 ~~~ Result: `getaddrinfo: Name or service not known (SocketError)` Expected: `getaddrinfo: Name or service not known for nonexistent.example.com (SocketError)` Why: This will make it easier to resolve errors of this kind by just looking at the logged messages. It is common for production and non-production (development, test) code to connect to different hosts which can produce errors due to wrong configuration. This change will make the ruby stdlib code more consistent as other methods already provide useful error information. Some examples: ~~~ ruby host = 'nonexistent.example.com'; port = 80 Resolv.getaddress host # => Resolv::ResolvError: no address for nonexistent.example.com Socket.getservbyname host # => SocketError: no such service nonexistent.example.com/tcp Net::HTTP.get Struct.new(:hostname, :port, :scheme).new(host, port, 'http') # => SocketError: Failed to open TCP connection to nonexistent.example.com:80 (getaddrinfo: Name or service not known) ~~~ If this issue will be resolved, please add any useful information to the error message in addition to the host. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126625] [Ruby Bug#22302] Prism and parse.y disagree on the `:line` event for a bare `nil` method body
by Eregon (Benoit Daloze) 10 Sep '26

10 Sep '26

Issue #22302 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22302: Prism and parse.y disagree on the `:line` event for a bare `nil` method body https://bugs.ruby-lang.org/issues/22302 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary The Prism compiler and the parse.y compiler produce a different set of `:line` trace points (line events) for a bare `nil` literal that is the value-producing body of a method. Prism emits a line event on the `nil`'s own line; parse.y does not. ```ruby def m nil end ``` - With `--parser=prism`, executing `m` (or setting a `TracePoint(:line)` / coverage / a debugger breakpoint) reports a line event on **line 2**. - With `--parser=parse.y`, there is **no** line event on line 2. ## Reproduction ### Compile-time line events ```ruby def line_events(iseq) events = iseq.trace_points.select { |_, event| event == :line }.map(&:first) iseq.each_child { |child| events.concat(line_events(child)) } events.sort end p line_events(RubyVM::InstructionSequence.compile("def m\n nil\nend\n")) ``` ``` $ ruby --parser=prism repro.rb [1, 2] $ ruby --parser=parse.y repro.rb [1] ``` ### Runtime `:line` events ```ruby seen = [] TracePoint.new(:line) { |tp| seen << tp.lineno if tp.path.end_with?("body.rb") }.enable do File.write("body.rb", "def m\n nil\nend\nm\n") load "./body.rb" end p seen.sort ``` ``` $ ruby --parser=prism rt.rb [1, 2, 4] $ ruby --parser=parse.y rt.rb [1, 4] ``` Under Prism a line event fires on line 2 (the `nil`) when `m` is called; under parse.y it does not. ## Instruction sequences The method body iseq differs only in the line attributed to the `putnil`, and whether it carries the line event (`[Li]`): ``` # --parser=parse.y 0000 putnil ( 1)[Ca] 0001 leave ( 3)[Re] # --parser=prism 0000 putnil ( 2)[LiCa] 0001 leave ( 3)[Re] ``` parse.y attributes the method's implicit-`nil` `putnil` to the definition line (1) with only the `RUBY_EVENT_CALL` flag, so no line event is emitted for line 2. Prism attributes the `putnil` to the `nil`'s own line (2) and emits a line event there. ## Scope of the difference The difference is specific to a bare `nil` in method (`def`/`defs`) tail position. Other cases behave the same under both parsers: - Other literals in the same position emit a line event under both parsers (`def m; true; end`, `def m; 1; end`, `def m; :a; end`, `def m; "s"; end`). - A bare `nil` at the top level, or as the body of a block or lambda, emits a line event under both parsers. - The failing shape also occurs when the tail `nil` is reached through the branch of a conditional, e.g. a method whose body is `if cond; nil; elsif ...; end`. The behavior is consistent across Ruby versions: parse.y has never emitted the line event for this case (checked back to 2.3), and Prism has emitted it since its compiler could be selected. This is a standing difference between the two compilers rather than a recent change; it only became visible by default when Prism became the default parser. ## Note on the cause This difference stems from void-expression elimination: parse.y treats the trailing `nil` as the method's implicit `nil` return and elides it (compiling a synthetic `putnil` with no line event), whereas Prism keeps it as an explicit value expression that carries a line event. It is not ideal that whether a `:line` event is emitted depends on whether an expression is eliminated as void, but that coupling is already the established behavior in both compilers — an unused bare literal in non-tail statement position (e.g. `1` or `:a` followed by another statement) likewise loses its line event under both parsers — so this is not unique to the case here, only the one place the two happen to disagree. ## Question Which behavior is intended — should a bare `nil` in method tail position emit a `:line` event or not? Currently the two parsers disagree, which affects `TracePoint(:line)`, line coverage, and debuggers depending on which parser compiled the code. ## Environment ``` ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] ``` Also reproduced on ruby 3.4.0 with `--parser=prism` / `--parser=parse.y`. (found in https://github.com/ruby/prism/pull/4223) -- https://bugs.ruby-lang.org/

1 3

[ruby-core:126506] [Ruby Feature#22266] Stop warning for duplicate keywords in splatted literal hashes
by jeremyevans0 (Jeremy Evans) 10 Sep '26

10 Sep '26

Issue #22266 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22266: Stop warning for duplicate keywords in splatted literal hashes https://bugs.ruby-lang.org/issues/22266 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby warns for duplicate keywords in the same literal hash: ```shellsession $ ruby -we '{h: 1, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` Ruby does not warn for duplicate keywords in splatted hashes: ```shellsession $ ruby -we 'h = {h:}; {h:, **h}' $ ruby -we 'h = {h:}; {**h, h:}' $ ruby -we 'h = {h:}; {**h, h:, **h}' $ ruby -we 'h = {h:}; {**h, **h}' ``` However, Ruby warns for for duplicate keywords in splatted literal hashes: ```shellsession $ ruby -we '{h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` I think Ruby should stop warning in the splatted literal hash case, for two reasons: * Treatment of splatted literal hashes is inconsistent with treatment of splatted non-literal hashes. Even if the compiler optimizes the splatted literal hash to the same bytecode as a direct keyword, it should not emit the same warning, because fundamentally the duplicate keyword is in a different hash, not in the same hash. * Warnings are designed to be helpful to the programmer, but unlike the warning for duplicate keywords in the same hash (a common mistake), no Ruby programmer is going to write splatted literal hashes. I can see an automated program generating splatted literal hashes, but in that case, the warnings are likely to be undesirable, just as warning for duplicate keywords in splatted non-literal hashes would be undesirable. Consider a hypothetical future Ruby compiler that could optimize the `h = {h:}; {h:, **h}` to the same bytecode as `{h: nil, **{h: nil}}`. Would we still want to emit the same warning? If accepted, I'm happy to work on a patch to implement this. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126600] [Ruby Bug#22301] Writing to the contents of a frozen IO::Buffer does not raise FrozenError
by himura467 (Akito Shitara) 10 Sep '26

10 Sep '26

Issue #22301 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22301: Writing to the contents of a frozen IO::Buffer does not raise FrozenError https://bugs.ruby-lang.org/issues/22301 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Writing to the contents of a frozen `IO::Buffer` does not raise `FrozenError`: ```ruby buffer = IO::Buffer.new(8) buffer.freeze buffer.set_string("x", 0) # no FrozenError buffer.get_string # => "x\x00\x00\x00\x00\x00\x00\x00" ``` `io_buffer_validate_for_writing()` rejects a buffer whose `RB_IO_BUFFER_READONLY` flag is set, or whose source is frozen, so it already treats frozen as not writable. But it takes a `struct rb_io_buffer *`, so the receiver never reaches it and the buffer's own frozen state goes unchecked. Reachable from `#set_string`, `#copy`, `#clear`, `#set_value`, `#set_values`, `#and!`, `#or!`, `#xor!`, `#not!`, `#read` and `#pread`. `#free`, `#resize` and `#transfer` already raise as of [Bug #22219]. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126458] [Ruby Feature#22255] Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select
by ko1 (Koichi Sasada) 10 Sep '26

10 Sep '26

Issue #22255 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22255: Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select https://bugs.ruby-lang.org/issues/22255 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- ## Abstract Add a `timeout:` keyword to the three ways a Ractor waits for a message: ```ruby Ractor::Port#receive(timeout: nil) # -> msg or nil Ractor.receive(timeout: nil) # -> msg or nil Ractor.select(*ports, timeout: nil) # -> [port, msg] or nil ``` They return `nil` once the timeout passes. `timeout: 0` never blocks: it takes a message if one is already there and returns `nil` otherwise. ## Background Today a Ractor wait cannot be bounded. Once a Ractor calls `receive`, it waits until a message arrives, so there is no way to write * a worker that gives up and reports progress if nothing arrives for a while, * a shutdown that stops waiting after a grace period, * a non-blocking "is there anything for me?" check. The usual workarounds are worse than a timeout: a watchdog Ractor that sends a dummy message, or a helper thread that closes the port. Both add a Ractor or a thread per wait and change the shape of the program. Every other blocking wait in Ruby already has this: `Thread::Queue#pop(timeout:)`, `ConditionVariable#wait(mutex, timeout)`, `Thread#join(limit)`, `IO#wait(timeout)`, `Mutex#sleep(timeout)`. ## Specification | call | result | |---|---| | `port.receive` | blocks until a message arrives (unchanged) | | `port.receive(timeout: 1.5)` | the message, or `nil` after 1.5 seconds | | `port.receive(timeout: 0)` | the message if one is already queued, else `nil`, without blocking | | `port.receive(timeout: -1)` | `ArgumentError` | | `Ractor.select(a, b, timeout: 1.5)` | `[port, msg]`, or `nil` after 1.5 seconds | The timeout behaves as it does elsewhere in Ruby: `nil` when it passes, and `timeout: 0` polls without blocking, as in `Thread::Queue#pop(timeout:)`, `IO.select` and `IO#wait`. * `timeout` accepts what `sleep` accepts (Integer, Float, Rational); a non-numeric value raises `TypeError`. * A negative timeout raises `ArgumentError`, as `IO.select` does. Note that `Thread::Queue#pop(timeout: -1)` instead returns `nil` right away, so the two existing APIs already disagree here; this follows `IO.select`. * `timeout: nil` (the default) means no timeout, i.e. today's behaviour. * A closed port still raises `Ractor::ClosedError`, timeout or not. * The timeout bounds how long the call blocks; it does not cut delivery off. A message that arrives while the timeout is being reported is still returned. Nothing is lost either way: a message only leaves the queue when it is returned. ### Why `nil` `nil` on timeout is what `Thread::Queue#pop(timeout:)`, `IO.select`, `IO#wait` and `Thread#join` all return. It is ambiguous when `nil` itself is a valid message, which is the same ambiguity `Queue#pop` has. The alternatives are a new exception class (`Ractor::TimeoutError`) or a sentinel object; both were judged heavier than the ambiguity is worth, but this is worth confirming. ### Why `timeout: 0` rather than a separate `try_receive` `timeout: 0` covers the non-blocking case with no new method name, and it is a genuine fast path in the implementation: it converts nothing, reads no clock and never parks. It costs about what a `receive` of an already-waiting message costs (~70ns vs ~150ns in a micro benchmark), against ~1.7us for a `receive(timeout: 10)` that has to compute a deadline. ## Implementation The wait stays where it is. `rb_ractor_sched_wait()` keeps parking the thread in the thread scheduler, so **an M:N thread still hands its native thread back** instead of becoming a dedicated one. Measured with 50 Ractors waiting at once, a timed `receive` uses the same 18 native threads an untimed one does. How the deadline is taken depends on the thread: * A **dedicated native thread** parks on its own condvar, so it takes the deadline there, the way `native_cond_sleep()` does. The condvar it waits on is the one a send already signals, so nothing else is involved. * An **M:N thread** has no condvar of its own, so its deadline is armed on the timer thread as a timeout-only wheel entry. The timer thread then wakes it through `thread_sched_to_ready_common()`, which is exactly how a send wakes it. That gives an M:N waiter two wakers, so the send path takes an armed timeout back before waking, skips a thread a fired timeout already made runnable, and bumps the scheduler event serial so a timeout that has not fired cannot wake it twice. Both kinds of wait exist on every pthread platform, including builds without the timer wheel (`USE_MN_THREADS == 0`, e.g. s390x-linux), where every thread is dedicated. On win32 the wait is already a condvar wait, which takes the timeout directly. Timer resolution follows the thread kind, exactly as `sleep` already does on the same thread: a dedicated thread gets the condvar's resolution, an M:N thread gets the timer wheel's 1ms tick. Measured, `receive(timeout: 0.0002)` and `sleep(0.0002)` return in 0.275ms on the main thread and 1.15ms inside a Ractor. ## Verification Besides `test/ruby/test_ractor.rb` additions: an attack suite of 13 scenarios (timeout racing with send, `Port#close`, `Thread#kill`, `Thread#raise`, Ractor termination, GC and compaction, `fork`, 64 waiters expiring in the same instant, all-Ractors-waiting deadlock detection) and a sweep that injects a trap, `SIGINT`, `Thread#kill` and `Thread#raise` at four points of the wait, including the instant the timer fires. Run against a release build, a `VM_CHECK_MODE` build and a `USE_MN_THREADS=0` build, with `RUBY_MN_THREADS=0` and `=1`. Of ~120,000 interrupt injections, ~78,000 landed while the thread was parked: no missed wakeup, no wait cut short by a trap, no assertion. 2,000,000 arm/disarm cycles showed no timer-wheel growth. ## Open questions 1. `nil` on timeout, or a `Ractor::TimeoutError`? 1a. A negative timeout: `ArgumentError` as in `IO.select`, or `nil` as in `Thread::Queue#pop`? 2. Should `Ractor.select` return something other than `nil`, given it already returns an Array? ## Patch https://github.com/ruby/ruby/pull/18418 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125877] [Ruby Feature#22134] Faster rb_scan_args() for keyword args (optimization)
by luke-gru (Luke Gruber) 10 Sep '26

10 Sep '26

Issue #22134 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22134: Faster rb_scan_args() for keyword args (optimization) https://bugs.ruby-lang.org/issues/22134 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Motivation When using the `rb_scan_args()` API, often we want to find a value for a given keyword argument. In order to do this, we call `rb_scan_args()` like so: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:", &str, &kwargs); // duplicates the kwargs hash in argv if (!NIL_P(kwargs)) rb_get_kwargs(kwargs, &id_example, 0, 1, &example); // mutates the duplicated kwargs hash to retrieve `example:` ``` This duplicates the keyword args hash given in `argv`. It would be nice to be able to grab a direct reference to the keyword hash and to have a variant of `rb_get_kwargs()` that didn't mutate the passed in hash. ## Proposal Add a new valid format character for `rb_scan_args()`: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:^", &str, &kwargs); // access kwargs directly from argv if (!NIL_P(kwargs)) rb_get_kwargs_const(kwargs, &id_example, 0, 1, &example); // don't mutate the passed kwargs hash ``` This '^' character would only be valid after a ":'. I have a [pull request](https://github.com/ruby/ruby/pull/17558) available for anyone that is interested. Thank you! -- https://bugs.ruby-lang.org/

2 4

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 10 Sep '26

10 Sep '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:126293] [Ruby Feature#22232] Deprecate `RHASH_TBL` and associated APIs
by byroot (Jean Boussier) 10 Sep '26

10 Sep '26

Issue #22232 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22232: Deprecate `RHASH_TBL` and associated APIs https://bugs.ruby-lang.org/issues/22232 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- I would like to deprecate `RHASH_TBL` and `RHASH_TBL_RAW`. ### Problem These API take a `RHash` instance and return its associated `st_table *`. If the Hash isn't backed by an `st_table` it will force convert it. I think it's a bad API because: - It allows to mutate the hash without triggering write barriers (dangerous). - Using it on a Hash backed by an `ar_table` blow memory usage. - It restrict evolution of RHash, as we must always be able to convert a Hash into a public `st_table`. There are various optimizations that would make sense for `RHash` but that would break the public `ruby/st.h` API, as such, in the future we may want to essentially fork `ruby/st.h` to have a distinct internal version dedicated to `RHash`. Just to give an example, `st_table.type` is very wasteful for RHash, as it's a full length 8B pointer that has only 2 possible values. It would be way more efficient to pass it as an argument every time, and get rid of some pointer chasing. With the possible future introduction of arbitrary length allocation in the GC, we might also want RHash to allocate its bins and entries with the GC rather than malloc. Both those ideas aren't possible to implement (or much harder) if we need to support `RHASH_TBL`. ### Impact I need to figure out how to use the gem search server, but a preliminary search on GitHub didn't show a lot of usage, it's a relatively rare API and if there are use cases that currently necessitate using `st_*` functions on RHash we should define equivalent `rb_hash_` functions to replace them. -- https://bugs.ruby-lang.org/

3 4