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

[ruby-core:125997] [Ruby Bug#22189] `Enumerator::Lazy#to_enum` does not accept method names as strings
by nobu (Nobuyoshi Nakada) 09 Aug '26

09 Aug '26

Issue #22189 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22189: `Enumerator::Lazy#to_enum` does not accept method names as strings https://bugs.ruby-lang.org/issues/22189 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `Kernel#to_enum` accepts a `String` as well as a `Symbol`. ```ruby [1,2,3].to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].to_enum("map").to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum("map").to_a #=> [] ``` Related to [Bug #7877]. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125864] [Ruby Bug#22133] Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking.
by ioquatix (Samuel Williams) 09 Aug '26

09 Aug '26

Issue #22133 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22133: Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking. https://bugs.ruby-lang.org/issues/22133 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Ruby's default SIGINT handling currently bypasses `Thread.handle_interrupt` masking. When a process receives SIGINT with the default Ruby handler installed, CRuby calls `rb_interrupt()` directly. That can raise `Interrupt` immediately inside code wrapped by `Thread.handle_interrupt(SignalException => :never)`, including while blocked in operations like `Thread::Queue#pop`. This is inconsistent with other asynchronous exception delivery paths, such as `Thread#raise`, and with other default signal exceptions such as SIGTERM. Those paths enqueue a pending interrupt on the target thread, allowing `Thread.handle_interrupt` to defer delivery until the configured point. ## Background This was discovered while working on `Async`/`Async::Container` signal handling. Async relies on `Thread.handle_interrupt` and scheduler-level interruption boundaries to keep signal delivery deterministic. The current default SIGINT path means a Ctrl-C can escape a masked section and interrupt internal synchronization code, which can break graceful shutdown behavior. A minimal reproduction is: ```ruby waiting = Thread::Queue.new release = Thread::Queue.new inner = false Thread.new do waiting.pop Process.kill(:INT, Process.pid) release.push(true) end begin Thread.handle_interrupt(SignalException => :never) do begin waiting.push(true) release.pop rescue Interrupt inner = true raise end end rescue Interrupt puts "outer" end puts inner ``` Expected output: ```text outer false ``` Current affected behavior can produce `inner == true`, meaning the `Interrupt` was delivered inside the masked region. ## Proposed fix Route default SIGINT through the same pending-interrupt mechanism as other default signal exceptions, while preserving the traditional exception class and no-message `Interrupt` object. Concretely, the PR replaces the direct `rb_interrupt()` default SIGINT path with a helper that enqueues an `Interrupt` on the main thread and wakes that thread. This makes default SIGINT respect `Thread.handle_interrupt(SignalException => :never)` in the same way as default SIGTERM/SignalException and `Thread#raise`. ## Pull request PR: https://github.com/ruby/ruby/pull/17533 The PR includes: 1. A failing regression test for default SIGINT with `Thread.handle_interrupt`. 2. The implementation change routing default SIGINT through the pending interrupt queue. 3. Ruby/spec coverage for default SIGINT -> `Interrupt` and default SIGTERM -> `SignalException` being maskable by `Thread.handle_interrupt`. Once accepted, I would like to request backports for supported Ruby branches where this default SIGINT behavior is present. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:125661] [Ruby Bug#22099] Keyword-only method silently accepts a positional argument
by rumoto (Hiroki Motoyoshi) 09 Aug '26

09 Aug '26

Issue #22099 has been reported by rumoto (Hiroki Motoyoshi). ---------------------------------------- Bug #22099: Keyword-only method silently accepts a positional argument https://bugs.ruby-lang.org/issues/22099 * Author: rumoto (Hiroki Motoyoshi) * Status: Open * ruby -v: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A method that declares only keyword parameters accepts a positional argument without raising, but only from the second call onward; a prior valid keyword call to the same method is required to trigger it. Once triggered, the positional value is bound to the first keyword and an explicitly passed keyword of the same name is dropped. ```ruby class Foo def bar(a: nil, b: nil) p [:body, a: a, b: b] end end foo = Foo.new foo.bar(a: 1, b: 2) #=> [:body, {a: 1, b: 2}] foo.bar(99, a: 0) #=> [:body, {a: 99, b: nil}] foo.bar(99, b: 0) #=> [:body, {a: nil, b: 99}] ``` Although one positional argument is passed, no exception is raised. The positional value (`99`) is bound to the first keyword `a`, and the explicitly passed keyword (`a: 0` / `b: 0`) is not reflected in the result. Since `bar` accepts no positional arguments, an `ArgumentError (wrong number of arguments (given 1, expected 0))` should be raised. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:125939] [Ruby Bug#22183] parse.y interpolation inside lambda literal
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22183 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22183: parse.y interpolation inside lambda literal https://bugs.ruby-lang.org/issues/22183 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is an odd bug that I think is just leaking parse.y internals to do with paren_nest and lambda_beginning_p. In parse.y, `p->lex.lpar_beg` is not isolated when the lexer enters a string interpolation (`tSTRING_DBEG`). So `lambda_beginning_p()` can be true inside an interpolation that appears between a lambda's `->` and its body, causing a `do` or `{` inside the interpolation to be lexed as `keyword_do_LAMBDA` / `tLAMBEG` and produce a syntax error. ```ruby -> a = "#{foo do end}" do end ``` ```console $ ruby --parser=parse.y -c test.rb test.rb: test.rb:1: syntax error found (SyntaxError) > 1 | -> a = "#{foo do end}" do end | ^~ unexpected 'do' for lambda, ... ``` The same applies with a brace block inside the interpolation: ```ruby -> a = "#{foo { }}" do end # parse.y: syntax error at the `{`, lexed as tLAMBEG ``` I'm not 100% sure about this one to be honest. I guess it could potentially have been a design decision? But it seems inconsistent: ```ruby -> a = ("#{foo do end}") do end # parse.y: OK -> a = "#{foo do end}" do end # parse.y: syntax error ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125803] [Ruby Bug#22124] void value missed in parse.y
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22124 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22124: void value missed in parse.y https://bugs.ruby-lang.org/issues/22124 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` $ ruby --parser=parse.y -cwe 'x = return a b do end' Syntax OK $ ruby --parser=prism -cwe 'x = return a b do end' ruby: -e:1: syntax error found (SyntaxError) > 1 | x = return a b do end | ^~~~~~~~~~~~~~~~~ unexpected void value expression ``` I think it's likely because of the wrapped block expression. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:124579] [Ruby Bug#21842] Encoding of rb_interned_str
by herwin (Herwin W) 09 Aug '26

09 Aug '26

Issue #21842 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21842: Encoding of rb_interned_str https://bugs.ruby-lang.org/issues/21842 * Author: herwin (Herwin W) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is one of the API methods to get an fstring. The documentation in the source says the following: ```c /** * Identical to rb_str_new(), except it returns an infamous "f"string. What is * a fstring? Well it is a special subkind of strings that is immutable, * deduped globally, and managed by our GC. It is much like a Symbol (in fact * Symbols are dynamic these days and are backended using fstrings). This * concept has been silently introduced at some point in 2.x era. Since then * it gained wider acceptance in the core. Starting from 3.x extension * libraries can also generate ones. * * @param[in] ptr A memory region of `len` bytes length. * @param[in] len Length of `ptr`, in bytes, not including the * terminating NUL character. * @exception rb_eArgError `len` is negative. * @return A found or created instance of ::rb_cString, of `len` bytes * length, of "binary" encoding, whose contents are identical to * that of `ptr`. * @pre At least `len` bytes of continuous memory region shall be * accessible via `ptr`. */ VALUE rb_interned_str(const char *ptr, long len); ``` I tried to create some specs for them (https://github.com/ruby/spec/pull/1327) but instead of binary encoding, the string is actually encoded as US-ASCII. This may result is some weird behaviour if the input contains bytes that are not valid in US-ASCII (the following is more an observation of the current behaviour) ```ruby it "support binary strings that are invalid in ASCII encoding" do str = "foo\x81bar\x82baz".b result = @s.rb_interned_str(str, str.bytesize) result.encoding.should == Encoding::US_ASCII result.should == str.dup.force_encoding(Encoding::US_ASCII) result.should_not.valid_encoding? end ``` So it seems to me like either the implementation of the documentation is incorrect. (`rb_interned_str_cstr` has the same behaviour, it's pretty much the same thing except using a null terminator instead of an explicit length argument). -- https://bugs.ruby-lang.org/

6 8

[ruby-core:117658] [Ruby master Feature#20448] Make coverage event hooking C API public
by ms-tob (Matt S) 09 Aug '26

09 Aug '26

Issue #20448 has been reported by ms-tob (Matt S). ---------------------------------------- Feature #20448: Make coverage event hooking C API public https://bugs.ruby-lang.org/issues/20448 * Author: ms-tob (Matt S) * Status: Open ---------------------------------------- # Abstract Gathering code coverage information is a well-known goal within software engineering. It is most commonly used to assess code coverage during automated testing. A lesser known use-case is coverage-guided fuzz testing, which will be the primary use-case presented in this issue. This issue exists to request that Ruby coverage event hooking be made part of its official, public C API. # Background Ruby currently provides a number of avenues for hooking events *or* gathering coverage information: 1. The [Coverage](https://ruby-doc.org/3.3.0/exts/coverage/Coverage.html) module 2. The [TracePoint](https://ruby-doc.org/3.3.0/TracePoint.html) module 3. The [rb_add_event_hook](https://ruby-doc.org/3.3.0/extension_rdoc.html#label-Hoo… extension function Unfortunately, none of these pieces of functionality solve this issue's specific use-case. The `Coverage` module is not a great fit for real-time coverage analysis with an unknown start and stop point. Coverage-guided fuzz testing requires this. The `TracePoint` module and `rb_add_event_hook` are not able to hook branch and line coverage events. Coverage-guided fuzz testing typically tracks branch events. # Proposal The ultimate goal is to enable Ruby C extensions to process coverage events in real-time. I did some cursory investigation into the Ruby C internals to determine what it would take to achieve this, but I'm by no means an expert, so my list may be incomplete. The good news is that much of this functionality already exists, but it's part of the private, internal-only C API. 1. Make `RUBY_EVENT_COVERAGE_LINE` and `RUBY_EVENT_COVERAGE_BRANCH` public: https://github.com/ruby/ruby/blob/v3_3_0/vm_core.h#L2182-L2184 a. This would be an addition to the current public event types: https://github.com/ruby/ruby/blob/v3_3_0/include/ruby/internal/event.h#L32-… 2. Allow initializing global coverage state so that coverage tracking can be fully enabled a. Currently, if `Coverage.setup` or `Coverage.start` is not called, then coverage events cannot be hooked. I do not fully understand why this is, but I believe it has something to do with `rb_get_coverages` and `rb_set_coverages`. If calls to `rb_get_coverages` return `NULL` (https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L641-L647, https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L864-L868) then coverage hooking will not be enabled. I believe the `Coverage` module initializes that state via a `rb_set_coverages` call here: https://github.com/ruby/ruby/blob/v3_3_0/ext/coverage/coverage.c#L112-L120. b. So, to achieve this goal, a C extension would need to be able to call `rb_set_coverages` or somehow initialize the global coverage state. I've actually been able to achieve this functionality by calling undocumented features and defining `RUBY_EVENT_COVERAGE_BRANCH`: ```c #include <ruby.h> #include <ruby/debug.h> #define RUBY_EVENT_COVERAGE_BRANCH 0x020000 // ... rb_event_flag_t events = RUBY_EVENT_COVERAGE_BRANCH; rb_event_hook_flag_t flags = ( RUBY_EVENT_HOOK_FLAG_SAFE | RUBY_EVENT_HOOK_FLAG_RAW_ARG ); rb_add_event_hook2( (rb_event_hook_func_t) event_hook_branch, events, counter_hash, flags ); ``` If I call `Coverage.setup(branches: true)`, and add this event hook, then branch hooking works as expected. `rb_add_event_hook2` will still respect the `RUBY_EVENT_COVERAGE_BRANCH` value if its passed. But it would be better if I could rely on official functionality rather than undocumented features. The above two points would be requirements for this functionality, but there's an additional nice-to-have: 3. Extend the public `tracearg` functionality to include additional coverage information a. Currently, `tracearg` offers information like `rb_tracearg_lineno` and `rb_tracearg_path`. It would be helpful if it also provided additional coverage information like `coverage.c`'s column information and a unique identifier for each branch. Currently, I can only use `(path, lineno)` as a unique identifier for a branch because that's what's offered by the public API, but more information like column number would be helpful for uniquely identify branches. Since there can be multiple `if` statements on a single line, this can provide ambiguous identification for a branch event. # Use cases This use-case was born out of a new coverage-guided Ruby fuzzer: https://github.com/trailofbits/ruzzy. You can read more about its implementation details here: https://blog.trailofbits.com/2024/03/29/introducing-ruzzy-a-coverage-guided…. You can also find the Ruby C extension code behind its implementation here: https://github.com/trailofbits/ruzzy/blob/v0.7.0/ext/cruzzy/cruzzy.c#L220-L…. So, the primary use-case here is enabling real-time, coverage-guided fuzz testing of Ruby code. However, as mentioned in the abstract, gathering code coverage information is useful in many domains. For example, it could enable new workflows in standard unit/integration test coverage. It could also enable gathering coverage information in real-time as an application is running. I see this as the most generalized form of gathering code coverage information, and something like the `Coverage` module as a specialized implementation. Another example, https://bugs.ruby-lang.org/issues/20282 may be solved by this more generalized solution. We are tracking this request downstream here: https://github.com/trailofbits/ruzzy/issues/9 # Discussion Fuzz testing is another tool in a testers toolbelt. It is an increasingly common way to improve software's robustness. Go has it built in to the standard library, Python has Atheris, Java has Jazzer, JavaScript has Jazzer.js, etc. OSS-Fuzz has helped identify and fix over 10,000 vulnerabilities and 36,000 bugs [using fuzzing](https://google.github.io/oss-fuzz/#trophies). Ruby deserves a good fuzzer, and improving coverage gathering would help achieve that goal. The `Coverage` module, `TracePoint` module, and `rb_add_event_hook` function seem like they could fulfill this goal. However, after deeper investigation, none of them fit the exact requirements for this use-case. # See also - https://bugs.ruby-lang.org/issues/20282 - https://github.com/google/atheris - https://security.googleblog.com/2020/12/how-atheris-python-fuzzer-works.html - https://github.com/CodeIntelligenceTesting/jazzer/ - https://www.code-intelligence.com/blog/java-fuzzing-with-jazzer - https://go.dev/doc/security/fuzz/ -- https://bugs.ruby-lang.org/

3 11

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 08 Aug '26

08 Aug '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

6 32

[ruby-core:126070] [Ruby Bug#22193] Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides
by KitaitiMakoto 08 Aug '26

08 Aug '26

Issue #22193 has been reported by KitaitiMakoto (真北市). ---------------------------------------- Bug #22193: Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides https://bugs.ruby-lang.org/issues/22193 * Author: KitaitiMakoto (真北市) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-13T13:26:16Z origin/master cb2ea293c6) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I encountered a segmentation fault when calling `rb_memory_view_is_row_major_contiguous` with a MemoryView whose shape and strides are `NULL`. For instance, a MemoryView initialized with `rb_memory_view_init_as_byte_array` function causes this problem. The cause is that the function handles `shape` and `strides` as arrays without checking whether they are `NULL` or not. Environment ----------- * Ruby commit: cb2ea293c6 * OS: macOS (M2 Mac) Code to reproduce the problem: ------------------------------ I will send a pull request later for the full patch. ### ext/-test-/memory_view/memory_view.c ### ```c static VALUE memory_view_is_row_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_row_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } static VALUE memory_view_is_column_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_column_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } // ... void Init_memory_view(void) { // ... rb_define_module_function(mMemoryViewTestUtils, "is_row_major_contiguous", memory_view_is_row_major_contiguous, 1); rb_define_module_function(mMemoryViewTestUtils, "is_column_major_contiguous", memory_view_is_column_major_contiguous, 1); // ... } ``` ### test/ruby/test_memory_view.rb ### ```ruby class TestMemoryView < Test::Unit::TestCase # ... def test_rb_memory_view_is_row_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_row_major_contiguous(es)) end def test_rb_memory_view_is_column_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_column_major_contiguous(es)) end # ... end ``` Steps to reproduce the problem: ------------------------------- 1. Add code above to the current Ruby (cb2ea293c6) 2. Run `make test-all TESTS=test/ruby/test_memory_view.rb` 3. Then you can see segmentation fault Thank you. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126187] [Ruby Bug#22216] Regexp backref and IO lastline are incompatible with Ractor
by headius (Charles Nutter) 07 Aug '26

07 Aug '26

Issue #22216 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #22216: Regexp backref and IO lastline are incompatible with Ractor https://bugs.ruby-lang.org/issues/22216 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem Several Regexp-matching methods currently write (and sometimes read) the implicit "backref" `$~` variable in the local frame (and related variables like `$'`). Several IO methods read or write the "last line" `$_` variable in the same way. In both cases, the result is a mutable object, which makes these variables already problematic for ractors. Making matters worse, the frame might be shared if a proc is captured and used across threads or ractors, and there's no static way to inspect a piece of code to know if it expects to read or write these variables. Where procs can be rejected by a proc for accessing captured state, there's no such check possible for these variables. All of these facts make the backref and lastline variables fundamentally incompatible with Ractor. ## Possible remedies A wholesale removal of these variables would solve the problem, but there's a lot of code that depends on them... much of that code without even realizing it, since they might not access the variables directly. In some cases, the dependencies are internal and part of the behavior of core methods. Hard errors when using methods that read or write these variables would avoid introducing threading problems into a Ractor, but would also break a large number of commonly-used methods. There have been experiments to make these variables both frame and thread-local, but they have never been made standard. Updates to backref and lastline are visible across threads and already can lead to concurrency issues even on CRuby. Deprecating the implicit behavior and making it opt-in (or opt-out?), perhaps with keyword arguments or file pragmas, might be a halfway measure. It would probably not be an easy transition. I don't know the right path forward, but I believe this issue needs to be discussed. ## JRuby perspective We continue to mimic CRuby behavior, which has led to our users occasionally running into issues when a proc accesses these variables across threads. Our recommendation: "don't do that". We also have had our frustrations optimizing around these variables, since they implicitly require access across calls. Because we cannot statically detect when they will be used, we essentially treat all method names that might *potentially* access them as deopt triggers. It's not ideal. I'd like to hear ideas for how to make these variables less "magic", less implicit and easier to deal with across calls (and across threads/ractors). -- https://bugs.ruby-lang.org/

6 19