- ruby-core - ml.ruby-lang.org

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 08 Oct '25

08 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 13

[ruby-core:123383] [Ruby Bug#21623] Endless method definition without parenthesis is wrongly accepted in Prism
by tompng (tomoya ishida) 08 Oct '25

08 Oct '25

Issue #21623 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21623: Endless method definition without parenthesis is wrongly accepted in Prism https://bugs.ruby-lang.org/issues/21623 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-02T03:48:32Z master 88222caaa9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax error in parse.y but accepted in Prism ~~~ruby def f x: = 1 def f ... = 1 def f * = 1 def f ** = 1 def f & = 1 def f *a = 1 def f **a = 1 def f &a = 1 ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123413] PAY OR BE EXPOSED
by ruby-core＠ml.ruby-lang.org 07 Oct '25

07 Oct '25

1 0

[ruby-core:123411] PAY OR BE EXPOSED
by ruby-core＠ml.ruby-lang.org 07 Oct '25

07 Oct '25

1 0

[ruby-core:122164] [Ruby Feature#21347] Add `open_timeout` as an overall timeout option for `Socket.tcp`
by shioimm (Misaki Shioi) 07 Oct '25

07 Oct '25

Issue #21347 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #21347: Add `open_timeout` as an overall timeout option for `Socket.tcp` https://bugs.ruby-lang.org/issues/21347 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- I propose to add an overall timeout option to `Socket.tcp` (and `TCPSocket.new`) ### Background Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options: - `resolv_timeout`, which controls the timeout for DNS resolution - `connect_timeout`, which controls the timeout for the connection attempt With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized. As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap. Example: When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set: 1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved). 2. A connection attempt is initiated to the IPv6 address 3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues. 4. After 200ms from the start, the method raises a `resolv_timeout` error. In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms). Furthermore, in HEv2, connection attempts are also parallelized. It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted. Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured. Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout. Example: When `connect_timeout: 100ms` is set and 3 address candidates: 1. Connect to address `a` at t=0ms. 2. Connect to address `b` at t=250ms. 3. Connect to address `c` at t=500ms. 4. If all fail, the exception is raised at t=1500ms (1000ms after `c`, 1250ms after `b`, 1500ms after `a`). 1. Start a connection attempt to the address `a` 2. 250ms after step 1, start a new connection attempt to the address `b` 3. 500ms after step 1, start a new connection attempt to the address `c` 4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about. These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout. ### Proposal I propose adding an `open_timeout` option to `Socket.tcp` in the following PR, which triggers a timeout after a specified duration has elapsed from the start of the method. https://github.com/ruby/ruby/pull/13368 The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`. If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases. If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`. While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout. ### Outcome If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`. https://github.com/ruby/ruby/blob/aa0f689bf45352c4a592e7f1a044912c40435266/… -- https://bugs.ruby-lang.org/

3 8

[ruby-core:123401] [Ruby Misc#21627] No usages of rb_enumeratorize
by ricardo.trindade743＠gmail.com (Ricardo Trindade) 07 Oct '25

07 Oct '25

Issue #21627 has been reported by ricardo.trindade743(a)gmail.com (Ricardo Trindade). ---------------------------------------- Misc #21627: No usages of rb_enumeratorize https://bugs.ruby-lang.org/issues/21627 * Author: ricardo.trindade743(a)gmail.com (Ricardo Trindade) * Status: Open * Assignee: ricardo.trindade743(a)gmail.com (Ricardo Trindade) ---------------------------------------- Throughout the codebase there seems to be no usages of the rb_enumeratorize method. Behind the scenes it is calling rb_enumeratorize_with_size which seems to be the recommended option, and this method has way more usages. Would it be ok to cleanup the method and its usages? Last issue reported here https://bugs.ruby-lang.org/issues/7302. If I get it correctly it seems to point that the method should be internal. Happy to work on a PR for this. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112552] [Ruby master Bug#19461] Time.local performance tanks in forked process (on macOS only?)
by ioquatix (Samuel Williams) 06 Oct '25

06 Oct '25

Issue #19461 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19461: Time.local performance tanks in forked process (on macOS only?) https://bugs.ruby-lang.org/issues/19461 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following program demonstrates a performance regression in forked child processes when invoking `Time.local`: ```ruby require 'benchmark' require 'time' def sir_local_alot result = Benchmark.measure do 10_000.times do tm = ::Time.local(2023) end end $stderr.puts result end sir_local_alot pid = fork do sir_local_alot end Process.wait(pid) ``` On Linux the performance is similar, but on macOS, the performance is over 100x worse on my M1 laptop. -- https://bugs.ruby-lang.org/

5 10

[ruby-core:116946] [Ruby master Bug#20302] Multiple refinements cannot be applied to the same module
by mame (Yusuke Endoh) 06 Oct '25

06 Oct '25

Issue #20302 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20302: Multiple refinements cannot be applied to the same module https://bugs.ruby-lang.org/issues/20302 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: shugo (Shugo Maeda) * ruby -v: ruby 3.4.0dev (2024-02-20T07:17:20Z master a605234bfa) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If we are using multiple refinements for the Kernel module, it seems that only the last refinement is enabled. In the following example, we can call `f2` of M2, which is enabled later. but cannot call `f1` of M1. ```ruby module M1 refine(Kernel) do def f1 = :f1 end end module M2 refine(Kernel) do def f2 = :f2 end end class Foo using M1 using M2 def test p f2 #=> :f2 p f1 # expected => :f1 # actual => undefined local variable or method 'f1' for an instance of Foo end end Foo.new.test ``` Note that if I change `refine(Kernel)` to `refine(Object)`, it works as expected. So I think there is a problem only when the refinement target is a module. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123402] [Ruby Feature#16769] Struct.new(..., immutable: true)
by CoderMiguel (Michael Newman) 06 Oct '25

06 Oct '25

Issue #16769 has been updated by CoderMiguel (Michael Newman). Breadcrumbs for those who land here early in their search: The [Data object](https://docs.ruby-lang.org/en/3.2/Data.html) is a reasonable alternative to this feature. ---------------------------------------- Feature #16769: Struct.new(..., immutable: true) https://bugs.ruby-lang.org/issues/16769#change-114771 * Author: k0kubun (Takashi Kokubun) * Status: Rejected ---------------------------------------- ## Background We've discussed interface to pass Struct attributes (like `immutable: true`, which is actually not added yet) at once. But I believe just adding `immutable: true` alone is really helpful in various cases. Thus I've spun out this ticket only for `immutable: true` from [Feature #16122]. ## Proposal ```rb Post = Struct.new(:id, :name, immutable: true) post = Post.new(1, "hello world") post.id = 2 # NoMethodError (undefined method `id=' for #<struct Post id=1, name="hello world">) ``` Given `immutable: true`, an instance returned by `.new` is frozen, and writer methods are not defined. ## Use case * Allow using Struct's nice features when we need an immutable model, instead of defining a normal class with `attr_reader`s and methods to support the Struct's features. * If it were a Struct, `to_s`, `inspect`, `==`, and a bunch of other methods are nicely defined by default. Deconstructing a Struct on Pattern Matching is also available. * This level of support from the entire ecosystem may not be available if it's just a third-party library. * We could achieve a similar thing if we call `Post.new(...).freeze` or override `#initialize` to call `freeze` inside it, but it is not fun and feels like a workaround. * Today I suggested to use Struct for a model class to take advantage of the above benefits in a code review, but the implementation stuck with a bare class with `attr_reader`s because the author didn't want writer methods to be defined (of course we don't want to manually undef them from a Struct class either) and calling `freeze` to workaround it seems tricky. I strongly desired Ruby's Struct is useful enough to cover this use case. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123288] [Ruby Bug#21610] Use ec->interrupt_mask to prevent interrupts.
by ioquatix (Samuel Williams) 05 Oct '25

05 Oct '25

Issue #21610 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21610: Use ec->interrupt_mask to prevent interrupts. https://bugs.ruby-lang.org/issues/21610 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program can trigger `rb_bug` in `rb_fiber_scheduler_unblock`: ```ruby require 'async/scheduler' scheduler = Async::Scheduler.new Fiber.set_scheduler(scheduler) Signal.trap(:USR1) do end q = Thread::Queue.new Thread.new do loop do Ractor.new do Process.kill(:USR1, $$) end.join end end Fiber.schedule do Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.pop q.push(1) puts "1 iter push/pop" end end Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.push(i) q.pop puts "1 iter push/pop#2" end end Fiber.schedule do gets exit! end end ``` In brief, when `rb_fiber_scheduler_unblock` executes with `ec->interrupt_flag` set, the following sequence can occur: ``` Thread A (Signaling) Thread B (Blocked Fiber) -------------------- --------------------- calls unblock(fiber_x) ├─ enters scheduler user code fiber_x sleeping in scheduler.block() ├─ ⚠️ SIGNAL INTERRUPT ⚠️ ├─ raises SignalException ├─ unblock operation aborted ├─ scheduler state inconsistent └─ returns believing success └─ fiber_x waits forever ⚠️ ``` Confirmed fix: https://github.com/ruby/ruby/pull/14588 -- https://bugs.ruby-lang.org/

2 6