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

[ruby-core:122558] [Ruby Bug#21446] StackOverflow when changing visibility in reopened refinement
by luke-gru (Luke Gruber) 24 Mar '26

24 Mar '26

Issue #21446 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21446: StackOverflow when changing visibility in reopened refinement https://bugs.ruby-lang.org/issues/21446 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class A def a :a end end class B < A end module R refine B do private :a end end module R refine B do public :a end end using R B.new.a # StackOverflow ``` I would expect it to change the visibility, not to overflow the stack. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 23 Mar '26

23 Mar '26

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 19 Mar '26

19 Mar '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 18

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 17 Mar '26

17 Mar '26

Issue #21520 has been reported by nuzair46 (Nuzair Rasheed). ---------------------------------------- Feature #21520: Feature Proposal: Enumerator::Lazy#peek https://bugs.ruby-lang.org/issues/21520 * Author: nuzair46 (Nuzair Rasheed) * Status: Open ---------------------------------------- # Abstract Add a #peek method to Enumerator::Lazy that allows observing each element in a lazy enumeration pipeline without modifying or consuming the stream. # Background Ruby provides Enumerator::Lazy for efficient lazy stream processing. However, unlike languages such as Java, it lacks a clean way to inspect intermediate elements during lazy evaluation. Currently, developers must misuse .map for side effects, example: ```rb (1..).lazy.map { |x| puts x; x }.select(&:even?).first(3) ``` This is semantically incorrect and confusing, since .map implies transformation, not observation. # Proposal Introduce Enumerator::Lazy#peek, which yields each item to a block and returns the item unmodified, similar to Object#tap, but in a lazy stream: ```rb (1..).lazy .peek { |x| puts "saw: #{x}" } .select(&:even?) .first(3) ``` This would be equivalent to: ```rb lazy.map { |x| block.call(x); x } ``` but with improved semantic clarity. # Use cases • Debugging lazy enumerators without breaking the chain • Logging or instrumentation in pipelines • Educational / demo use for showing lazy evaluation step-by-step • Cleaner replacement for map { puts x; x } hacks Example: ```rb data = (1..).lazy .peek { |x| puts "got #{x}" } .select(&:even?) .first(5) ``` result: ```rb got 1 got 2 got 3 got 4 got 5 ``` And return [2, 4, 6, 8, 10] # Discussion #peek is a minimal, non-breaking addition that improves clarity and idiomatic usage of Enumerator::Lazy. It avoids abusing .map for observation and is familiar to developers from other languages. #peek is also not needed for other enumerators where .tap or .each can do the job. It mirrors Java’s .stream().peek(...) and makes Ruby’s lazy enumeration more expressive and readable. # See also • [Java Stream.peek](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Str… I would be glad to work on this and make a PR. Thank you. -- https://bugs.ruby-lang.org/

4 14

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 16 Mar '26

16 Mar '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 16 Mar '26

16 Mar '26

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

9 12

[ruby-core:116589] [Ruby master Misc#20238] Use prism for mk_builtin_loader.rb
by kddnewton (Kevin Newton) 13 Mar '26

13 Mar '26

Issue #20238 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20238: Use prism for mk_builtin_loader.rb https://bugs.ruby-lang.org/issues/20238 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose that we use prism for mk_builtin_loader.rb. Right now the Ruby syntax that you can use in builtin classes is restricted to the base Ruby version (2.7). This means you can't use a lot of the nicer syntax that Ruby has shipped in the last couple of years. If we switch to using prism to parse the builtin files instead of using ripper, then we can always use the latest version of Ruby syntax. A pull request for this is here: https://github.com/kddnewton/ruby/pull/65. The approach for the PR is taken from how RJIT bindgen works. -- https://bugs.ruby-lang.org/

6 22

[ruby-core:123871] [Ruby Feature#21700] `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful
by trinistr (Alexander Bulancov) 12 Mar '26

12 Mar '26

Issue #21700 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Feature #21700: `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful https://bugs.ruby-lang.org/issues/21700 * Author: trinistr (Alexander Bulancov) * Status: Open ---------------------------------------- *This was supposed to be a bug report, but it turned into a feature request halfway through.* `IO::Buffer.map` supports `size` and `offset` arguments to localize buffer to a specific part of mapped file. While `size` works fine, specifying `offset` as anything but 0 is a recipe for disaster. 1. It is practically undocumented. This is it currently: "Optional size and offset of mapping can be specified." While `size` can be whatever user desires, `offset` can only be set to specific values. It was *very* surprising when I started testing it, as I expected it to behave similar to size and offset of a slice. Which values are allowed? That's the next point. 2. Possible values for `offset` are highly platform-dependent. - On Linux it must be a multiple of page size. (https://www.man7.org/linux/man-pages/man2/mmap.2.html) - On macOS it can be any value? manpage doesn't specify exactly. (https://developer.apple.com/library/archive/documentation/System/Conceptual… (I looked at the manpage on a mac, seems to be the same.)) - On Windows it must be a multiple of some value that *isn't* page size and page size doesn't work here. StackOverflow says it's 64 kB, but that didn't work for me. (See dwFileOffsetLow in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…) - On other systems? Who knows. 3. On macOS, a buffer successfully created with an offset crashes on read. I don't know why, it's exactly the same file, size and offset that works on Ubuntu, and the read is bounded. 4. Currently, offset doesn't change the buffer's size if unspecified, leading to crashes. I will be making a PR addressing this but still. 5. All of this makes offset unpractical to test, leading to all kinds of problems. So the problem is: this argument is a very low-level detail that requires significant knowledge of all platforms your code may be ever deployed to, even if strictly Ruby is used (no C API), with unexpectedly high footgun potential. I understand that IO::Buffer is a lower-level class, but this seems too much. I propose to make `offset` argument into a convenience for users, allowing any reasonable value (i.e inside the file). Behind the scenes, we can use the native offset for efficieny, on platforms where it works well, but the user API would be decoupled from this. However, I'm not particularly familiar with Ruby internals, so I can't tell how viable this is. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:123992] [Ruby Bug#21760] Ruby::Box: a couple of require-related problems
by zverok (Victor Shepelev) 09 Mar '26

09 Mar '26

Issue #21760 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21760: Ruby::Box: a couple of require-related problems https://bugs.ruby-lang.org/issues/21760 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: 4.0.0dev (2025-12-03T05:16:03Z master 4762f429f4) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am not sure whether all the problems have the same nature, but putting them together for now. **1. Enabling box breaks `gem`+`require`** Minimal reproducible example: `test.rb`: ```ruby gem 'faraday', '= 2.14.0' require 'faraday' p Faraday::VERSION ``` (Note that there is no explicit use of `Ruby::Box`) Running it with and without `RUBY_BOX`: ```sh $ ruby test.rb "2.14.0" $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' ``` (sic, the error is printed twice) **2. requiring the same gem from `Box`-loaded file and the main file** `box.rb`: ```ruby require 'faraday' p "In a box: #{Faraday::VERSION}" ``` `main.rb` ```ruby b = Ruby::Box.new b.load('box.rb') require 'faraday' ``` ```sh $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. "In a box: 2.14.0" main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' ``` **3. `Box#require` seem to not be aware of gems** In the example above, we see that Box-loaded file can require a gem. This also works: ```ruby b = Ruby::Box.new b.eval(<<~RUBY) require "faraday" p Faraday::VERSION RUBY ``` (prints "2.14.0" as expected) But this doesn't: ```ruby b = Ruby::Box.new b.require('faraday') ``` ```sh $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. test.rb:3:in 'Ruby::Box#require': cannot load such file -- faraday (LoadError) from test.rb:3:in '<main>' ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 07 Mar '26

07 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2