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

[ruby-core:126083] [Ruby Bug#22195] `IO::Buffer` read after free silently returns empty data instead of raising
by himura467 (Akito Shitara) 14 Jul '26

14 Jul '26

Issue #22195 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22195: `IO::Buffer` read after free silently returns empty data instead of raising https://bugs.ruby-lang.org/issues/22195 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading from an `IO::Buffer` after calling `#free` does not raise. It behaves like an empty buffer, and `#valid?` still returns `true`: ```ruby buffer = IO::Buffer.for("Hello World") buffer.free buffer.valid? # => true buffer.get_string # => "" (no error) ``` ## Why this looks like an unintended regression Originally (https://github.com/ruby/ruby/commit/e30920354f, Ruby 3.1–3.3), accessing a freed buffer raised `IO::Buffer::AllocationError` ("The buffer is not allocated!"). https://github.com/ruby/ruby/commit/c5cf4d4e12 made zero-length buffer operations succeed instead of raising, for [Bug #19542] and [Bug #18805]. Since a freed buffer also has `base == NULL, size == 0`, it was caught in the same code path and stopped raising too. Neither ticket mentions freed buffers, so this appears to be an accidental side effect rather than a decision. Note that the rdoc of `#free` still promises that access after free raises. ## Proposal How about marking a buffer as invalidated when it is explicitly freed (`#free` / `rb_io_buffer_free`), so that: * `#valid?` returns `false`. * Any byte access raises `IO::Buffer::InvalidatedError` or `IO::Buffer::AllocationError`. * `#resize` re-allocates and clears the mark, as `#free`'s rdoc promises ("You can resize a freed buffer to re-allocate it"). * The zero-length buffer semantics from https://github.com/ruby/ruby/pull/9532 are preserved: `IO::Buffer.new(0)`, `resize(0)` and zero-length slices remain valid and readable. I'm not sure which exception class is preferable: `IO::Buffer::InvalidatedError` is consistent with how invalidated slices already behave and with `#valid?` returning `false`, while `IO::Buffer::AllocationError` restores the pre-3.4 behavior. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126049] [Ruby Bug#22191] `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises
by Earlopain (Earlopain _) 14 Jul '26

14 Jul '26

Issue #22191 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22191: `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises https://bugs.ruby-lang.org/issues/22191 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-29T14:34:40Z master 7a07a54298) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb Signal.trap(:EXIT, proc { raise "foo" }) # No output ``` ```rb Signal.trap(:EXIT, proc { raise "foo" }) at_exit { raise "bar" } # test.rb:2:in 'block in <main>': bar (RuntimeError) # test.rb:1:in 'block in <main>': foo (RuntimeError) ``` A bit weird -- https://bugs.ruby-lang.org/

3 2

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

14 Jul '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/

2 1

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

14 Jul '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/

6 5

[ruby-core:126066] [Ruby Misc#22192] Clarify the scope of default visibility changed inside a block
by shugo (Shugo Maeda) 13 Jul '26

13 Jul '26

Issue #22192 has been reported by shugo (Shugo Maeda). ---------------------------------------- Misc #22192: Clarify the scope of default visibility changed inside a block https://bugs.ruby-lang.org/issues/22192 * Author: shugo (Shugo Maeda) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- `private` etc. called with no arguments inside a block changes the default visibility of the enclosing lexical scope, and the change survives the block: ```ruby class C %i[foo bar].each do |name| private define_method(name) { } end def afterwards; end # also private end C.private_method_defined?(:foo) #=> true C.private_method_defined?(:afterwards) #=> true ``` When multiple Procs share the same lexical scope, `private` in a Proc affects all Procs: ```ruby class Host SET_PRIVATE = proc { private } DEFINE = proc { def probe; end } end Host::SET_PRIVATE.call Host::DEFINE.call Host.private_method_defined?(:probe) #=> true ``` Neither CRuby nor ruby/spec has corresponding tests. I assume this is intentional, but am I correct? It seems that the visibility change is effective only within the block on JRuby, so I'd like to clarify this. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126076] [Ruby Feature#7876] Add method for accessing Class from within Singleton Class
by Earlopain (Earlopain _) 13 Jul '26

13 Jul '26

Issue #7876 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed Implemented as `attached_object` in https://bugs.ruby-lang.org/issues/12084 ```rb class Test class << self p attached_object # => Test end end ``` ---------------------------------------- Feature #7876: Add method for accessing Class from within Singleton Class https://bugs.ruby-lang.org/issues/7876#change-118078 * Author: wardrop (Tom Wardrop) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- =begin I'm quite surprised I haven't run into this sooner, but I seem to have just discovered that there's no means by which you can access the outer Class object once inside the context of the Singleton Class. Take the following example; how would I get a reference to (({Test})) from within the singleton? class Test class << self # How do I get a reference to Test from here? end end I assume the answer is that there is no reliable way, hence the reason for this request. Could we add a method to the singleton class that allows access to the "outer" class, e.g. class Test class << self self.outerclass end end Thoughts? =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126075] [Ruby Feature#7895] Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations
by Earlopain (Earlopain _) 13 Jul '26

13 Jul '26

Issue #7895 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Available since a long time ago ---------------------------------------- Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations https://bugs.ruby-lang.org/issues/7895#change-118075 * Author: headius (Charles Nutter) * Status: Closed ---------------------------------------- Thread#backtrace_locations and Kernel#caller_locations were added in Ruby 2.0.0, but no equivalent method was added to Exception to get backtrace locations. The String format of Exception#backtrace elements makes it difficult to do any inspection of the actual files and lines it reports, so having backtrace_locations would be very useful. In #7435 ko1 pointed out that Exception defines set_backtrace, which takes an array (presumably of Strings in the same format as Exception#backtrace) and that this would need to be addressed in order to support backtrace_locations. I propose that if you set_backtrace, you are already breaking the ability to get structured Location elements, so set_backtrace should cause backtrace_locations to return nil or an empty array (probably an empty array, so it can always be expected to be non-nil). We could consider also adding set_backtrace_locations as a way to set Location elements into the exception. An example script where backtrace_locations would be very useful is here (avoiding the need to regexp match to get file and line number): https://gist.github.com/headius/4999244 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126074] [Ruby Feature#5781] Query attributes (attribute methods ending in `?` mark)
by Earlopain (Earlopain _) 13 Jul '26

13 Jul '26

Issue #5781 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed Sadly https://bugs.ruby-lang.org/issues/21555#note-10 > I still ask you to define def valid? = @valid manually. It is not much worse than attr_reader :valid?. ---------------------------------------- Feature #5781: Query attributes (attribute methods ending in `?` mark) https://bugs.ruby-lang.org/issues/5781#change-118074 * Author: trans (Thomas Sawyer) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Pretty sure this has come up before, but I'd like to revisit b/c I don't understand why it isn't allowed. Sometimes I define "query" attributes, and in those cases I'd like the reader method to end in a `?` mark. Currently I have to do: # @attribute def foo? @foo end or, if I don't mind a shadowing bare method, attr :foo alias_method :foo?, :foo So why not just allow: attr :foo? Currently this causes an error. But why? It just seems like a waste of potentially cleaner code. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113743] [Ruby master Feature#19708] Support `attr_reader :foo?`
by AMomchilov (Alexander Momchilov) 13 Jul '26

13 Jul '26

Issue #19708 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #19708: Support `attr_reader :foo?` https://bugs.ruby-lang.org/issues/19708 * Author: AMomchilov (Alexander Momchilov) * Status: Open * Priority: Normal ---------------------------------------- Creating reader methods with `attr_reader` is preferable over defining them by hand, not only because it's more convenient, but also because it hits a fast path in MRI (see `VM_METHOD_TYPE_IVAR`). Since local and instance variables can't end with `?`, you can't use `attr_reader` to define predicate-style methods for boolean values, like: ```ruby class Person attr_reader(:name, :age, :active?) # invalid attribute name `active?' (NameError) def initialize @name = "Bob" @age = 30 @active = true end end ``` It would be nice if `attr_reader` (and friends) could behave like: ```ruby def active? = @active ``` (`attr_writer` and `attr_accessor` couldn't do the same, since `def active?=(new_value)` isn't valid, so they'd probably stick with `def active=(new_value)`) -- https://bugs.ruby-lang.org/

5 7

[ruby-core:126072] [Ruby Feature#6842] Add Optional Arguments to String#strip
by Earlopain (Earlopain _) 13 Jul '26

13 Jul '26

Issue #6842 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed delete_prefix and delete_suffix exist now. https://bugs.ruby-lang.org/issues/21552 also did arguments to various strip methods like above. ---------------------------------------- Feature #6842: Add Optional Arguments to String#strip https://bugs.ruby-lang.org/issues/6842#change-118071 * Author: wardrop (Tom Wardrop) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- =begin One of the very few things I miss from the ol' php days many years ago, was the ability to easily strip arbitrary characters from the ends of string using trim(). Typically, this is whitespace characters, and #strip currently fulfils that use case, but there are also instances where it'd be nice to be able to strip any range of characters from the ends of a string. It goes well with Array#join as often when joining strings with a delimiter, you want to make sure those strings don't already begin or end with that character. For a full-featured #strip, I'd like to see it have the option of accepting both an Array or String. If a string is provided, each character in that string will be stripped. If an array of strings is given, each element of the array is stripped from the ends of the string - this allows for multi-character delimiters for example. Of course you could go really nuts and supports regex as well (or instead of arrays). To demonstrate the difference... "bold text".strip("") #=> "old text" "bold text".strip(["", ""]) #=> "bold text" "bold text".strip(["", "", "", ""]) #=> "bold text" "bold text".strip(/<\/?.+?>/) #=> "bold text" A simple real-world example; this is actually what I was wanting to do right before I came here to raise this feature request, but there's been all kinds of other use cases I've hit in the past: ['some', '/chunked', 'path/'].map{ |v| v.strip('/') }.join('/') #=> "some/chunked/path" File#join does something similar, but when you need control over the joining character, this is the way you'd do it. I've lost count of how many times I've wanted this in Ruby, and there's really no nice workaround. Here's an example on StackOverflow of someone asking how to achieve this stripping behaviour in ruby: http://stackoverflow.com/questions/3453262/how-to-strip-leading-and-trailin… Obviously, you'd do the same for #lstrip and #rstrip, and all the mutable variants (#strip!, #lstrip!, #rstrip!). Looking forward to others thoughts on this one. =end -- https://bugs.ruby-lang.org/

1 0