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

[ruby-core:126303] [Ruby Feature#17930] Add column information into error backtrace
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #17930 has been updated by Eregon (Benoit Daloze). This exact information is now available via `Thread::Backtrace::Location#source_range` (#22212), just slightly different method names. ---------------------------------------- Feature #17930: Add column information into error backtrace https://bugs.ruby-lang.org/issues/17930#change-118404 * Author: mame (Yusuke Endoh) * Status: Closed * Assignee: mame (Yusuke Endoh) ---------------------------------------- Consider the following code and error. ``` data["data"].first["field"] #=> undefined method `[]` for nil:NilClass ``` There are two possibilities; the variable `data` is nil, or the return value of `first` is nil. Unfortunately, the error message is less informative to say which. This proposal allows to help identifying which method call failed. ``` $ ruby -r ./sample/no_method_error_ext.rb err1.rb err1.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError) data["data"].first["field"] ^^^^^^^^^ ``` ## Proposal I'd like to propose a feature to get column information from each `Thread::BacktraceLocation`. Maybe it is good to provide the following four methods: * `Thread::BacktraceLocation#first_lineno` * `Thread::BacktraceLocation#first_column` * `Thread::BacktraceLocation#last_lineno` * `Thread::BacktraceLocation#last_column` These names came from `RubyVM::AbstraceSyntaxTree::Node`'s methods. ## Implementation Here is a proof-of-concept implementation: https://github.com/ruby/ruby/pull/4540 See https://github.com/ruby/ruby/pull/4540/commits/6ff516f4985826e9f9c560663800… for an example usage. (Note that, currently, you need to build ruby with `./configure cflags=-DEXPERIMENTAL_ISEQ_NODE_ID` to enable the feature.) To put it simply, this PR provides only a raw API, `Thread::BacktraceLocation#node_id`. To get actual column information, you need to manually identify `RubyVM::AbstractSyntaxTree::Node` that corresponds to `Thread::BacktraceLocation#node_id`. But it would be arguable to expose "node_id", so I will wrap it as the above four methods if this is accepted. Credit: the original implementation was done by @yui-knk. ## Drawback To use this feature, we need to enable `-DEXPERIMENTAL_ISEQ_NODE_ID` to add "node_id" information (a subtree ID of the original abstract syntax tree) into each byte code instruction. If we provide this feature, the option should be enabled by default. However, the option increases memory consumption. I performed a simple experiment: I created a scaffold app by `rails new`, and measured the memory usage after `rails s`. The result was 97 MB without `-DEXPERIMENTAL_ISEQ_NODE_ID`, and 100 MB with the option enabled. In my opinion, it is not so large, but requiring more gems will increase the difference. I will appriciate it if anyone could provide the actual memory increase in a more practical Rails app. Do you think this feature deserves the memory increase? ---Files-------------------------------- image.png (73.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126302] [Ruby Feature#8751] Add offsets to method#source_location
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #8751 has been updated by Eregon (Benoit Daloze). This is now available since #21998 with `{Method,UnboundMethod,Proc}#source_range`. It's start/end line + start/end byte-column and not byte offsets, but one can convert between both if the source file is available. ---------------------------------------- Feature #8751: Add offsets to method#source_location https://bugs.ruby-lang.org/issues/8751#change-118403 * Author: tenderlovemaking (Aaron Patterson) * Status: Closed ---------------------------------------- Hello, I would like to have byte offsets returned on the source_location for methods. For example: def foo(&b) b.source_location # => [file_name, line_number, start_byte, end_byte] end If we had the start and end byte for a method or proc, then we could find the source for methods and procs in each file. There are some cases (like with heredocuments) where the "end of the method" could be after the `end` keyword. But I think if we just have offsets for the start of `def` and the end of `end`, I think it would cover 99% of usecases. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126301] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #6012 has been updated by Eregon (Benoit Daloze). This is now available since #21998 with `Proc#source_range` ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-118402 * Author: rogerdpack (Roger Pack) * Status: Rejected * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126211] [Ruby Feature#22222] Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary`
by byroot (Jean Boussier) 06 Aug '26

06 Aug '26

Issue #22222 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22222: Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary` https://bugs.ruby-lang.org/issues/22222 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Currently the only API to deserialize instruction sequence is `RubyVM::InstructionSequence.load_from_binary(String)`. It works fine, but isn't ideal for gems like bootsnap, as it needs to allocate a fairly large string and `memcpy` into it. I would like to be able to directly pass a `char *ptr` and `size_t len` pair, so that I can directly pass a internal buffer or even mmapped file. Proposed API: ``` VALUE rb_iseq_load_from_binary(const char *ptr, size_t len) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:126092] [Ruby Bug#22197] Backtraces show methods which do not exist
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22197 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22197: Backtraces show methods which do not exist https://bugs.ruby-lang.org/issues/22197 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class Parent def original puts caller_locations(0), nil end end class Child < Parent alias_method :alias, :original end Child.new.alias module Original def original puts caller_locations(0) end end class A define_method(:a, Original.instance_method(:original)) end A.new.a ``` gives: ``` $ ruby -v backtrace_alias.rb ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] backtrace_alias.rb:3:in 'Child#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'A#original' backtrace_alias.rb:23:in '<main>' ``` But this seems clearly incorrect: * there is no `Child#original`, there is only `Parent#original` and `Child#alias`. * there is no `A#original`, there is only `Original#original` and `A#a`. This behavior exists since Ruby 3.4 which added the module name in backtraces (#19117). So the issue is that backtraces show the "original method name from the definition" with the "method owner of the actually-called method". It should be consistent to avoid showing methods which don't exist. And it should be the original method from the definition, because we show the file and line of that, so we should also show the original name (already the case) and the original module (not the case yet, the bug). FWIW TruffleRuby already behaves like that: ``` $ truffleruby 34.0.1 (2026-04-26), like ruby 3.4.9, Oracle GraalVM Native [arm64-darwin23] backtrace_alias.rb:3:in 'Parent#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'Original#original' backtrace_alias.rb:23:in '<main>' ``` In #19117 there was some discussion about this, notably: https://bugs.ruby-lang.org/issues/19117#note-17 @byroot > My suggestion is for the owner. Simply put because it matches the path and other existing method representations. But actually the owner isn't that, what is described here is the original module of the method definition, same as the expected from this issue. https://bugs.ruby-lang.org/issues/19117#note-18 @eregon > It must be the owner, anything else would be very confusing. > I believe nobody wants String#then (there is no such method), they want to see Kernel#then. Where I was wrong about owner being the only thing. I was also expressing we should show where the method is defined, but I overlooked the "originally" part (aliases, define_method, etc). Also CC @mame who implemented the change. I think this is worth fixing for Ruby 4.1 (not sure if worth backporting). -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126160] [Ruby Feature#22212] Add Thread::Backtrace::Location#source_range
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22212 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #22212: Add Thread::Backtrace::Location#source_range https://bugs.ruby-lang.org/issues/22212 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ## Motivation The main motivation is to be able to implement `Prism.find(Thread::Backtrace::Location)` precisely and cleanly on any Ruby implementation, in a way which does not depend on implementation details like `node_id`. For that we need the start/end line/column and the `absolute_path`, which is exactly what `Ruby::SourceRange` provides. In https://bugs.ruby-lang.org/issues/21998 we added `source_range` for `{Method,UnboundMethod,Proc}`. However we also need `source_range` for `Thread::Backtrace::Location` as this is used in `error_highlight`, `power_assert`, etc. Those tools currently use `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(Thread::Backtrace::Location)`, however: * that's a CRuby-only experimental API * it exposes CRuby internals (`node_id`) * it adds a lot of complexity for all usages because they need to handle both `Prism::Node` and `RubyVM::AbstractSyntaxTree::Node`. We solve all of this by adding a new portable API which exposes universal concepts like line and column, which are stable to find AST nodes. ## Implementation How can we get the start/end line/column when we only keep the start line in CRuby? By re-parsing, and specifically by re-parsing with *exactly* the same parser that the interpreter used to compile to bytecode. That way there is no issue of using different Prism versions, it's the Prism C library built in CRuby, or `parse.y` in `--parser=parse.y` mode. Either way, we reparse to extract the start/end line/column. We make the returned start/end line/column match for both `Prism` and `parse.y`, in practice the only difference is for calls with blocks, where we adapt the location from parse.y to match Prism. One can then easily use Prism to get a node matching that `Ruby::SourceRange` and use the resulting `Prism::Node` as they wish. This also means all versions of Prism can be used, and for example if some dependency requires some specific version of Prism it works fine and is not a problem. As a result, the user of this API can choose the Prism version they want and always get a `Prism::Node` (and not having to handle `RubyVM::AbstractSyntaxTree::Node` too, or a duplicate `Ruby::Node` API as mentioned in #21795). PR: https://github.com/ruby/ruby/pull/18043 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126291] [Ruby Feature#9779] Add Module#descendants
by matz (Yukihiro Matsumoto) 06 Aug '26

06 Aug '26

Issue #9779 has been updated by matz (Yukihiro Matsumoto). Accepted. Let's define `Module#descendants`. This settles the question I left open in [#14394](https://bugs.ruby-lang.org/issues/14394#note-38). `Class#subclasses` already lets you write the transitive closure for classes in Ruby, but there is no equivalent primitive for modules, so `Module` is where this method actually adds something. Defining it there also gives `Class` the method for free. Not including `self` is fine too. It departs from `ancestors`, but it agrees with `Class#subclasses` and with ActiveSupport's `descendants`, and `[mod, *mod.descendants]` is available when needed. Once this is merged, I think [#14394](https://bugs.ruby-lang.org/issues/14394) can be closed. Matz. ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118388 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126165] [Ruby Feature#22213] Allow no-argument and chained calls of Proc#refined
by shugo (Shugo Maeda) 06 Aug '26

06 Aug '26

Issue #22213 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22213: Allow no-argument and chained calls of Proc#refined https://bugs.ruby-lang.org/issues/22213 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract Currently, `Proc#refined` rejects no-argument and chained calls, because I wasn't sure what the desired behavior should be. How about returning the receiver for no-argument calls: ```ruby original = -> {} refined = original.refined p refined.equal?(original) #=> true ``` and activating all the given modules for chained calls? ```ruby module M refine String do def shout = upcase + "!" end end module M2 refine Integer do def doubled = self * 2 end end original = ->(s, i) { [s.shout, i.doubled] } refined = original.refined(M).refined(M2) # the same result as original.refined(M, M2) refined.call("hi", 3) #=> ["HI!", 6] ``` ## Motivation This change is necessary to make `Proc#refined` composable. A no-argument call of `Proc#refined` is a no-op, but it's useful when the arguments are calculated at runtime: ```ruby def foo(prc, *modules) ... refined = prc.refined(*modules) ... end ``` If an empty module list were rejected, a guard like `unless modules.empty?` would be needed. A chained call of `Proc#refined` is useful to extend existing DSLs: ```ruby require "packrat_parser" require "mathn" class MathParser < PackratParser def define(sym, &block) # PackratParser#define also calls Proc#refined super(sym, &block.refined(Math::N)) end end parser = MathParser.new { ... define :multitive do [:primary, "*", :multitive].map { |x, _, y| x * y } | [:primary, "/", :multitive].map { |x, _, y| x / y } | :primary end ... } parser.parse("1 / 2") #=> (1/2) ``` ## Formal semantics With this proposal, `Proc#refined` can be formalized as a monoid action on Procs created from a block, where the acting monoid is the sequences of modules under concatenation, with the empty sequence as its unit. Writing ≃ for behavioral equivalence, the action satisfies the unit and associativity laws: ``` prc.refined ≃ prc # unit law prc.refined(*ms).refined(*ns) ≃ prc.refined(*ms, *ns) # associativity law ``` Note that the unit law holds for any Proc, since `refined` with no modules returns the receiver itself. I've written a formalization in the Rocq Prover: https://github.com/shugo/ruby-refinements-semantics It abstracts away the details irrelevant to refinements. ## Design decisions ### The receiver or a copy for no-argument calls Returning a copy was also considered, but I chose to return the receiver, following precedents such as `Data#with` and `Enumerator::Lazy#lazy`. Mutable containers tend to return a copy even for a no-op, but `Proc#refined` is closer to the former group. ### Extend or replace for chained calls If a chained call replaced the receiver's refinements instead of extending them, `prc.refined(M).refined(M2)` would activate only `M2`. That breaks the associativity law above, and makes chaining useless for the DSL case in Motivation. Extending also matches nested `using`, where refinements activated later take precedence. ## Implementation Pull request: https://github.com/ruby/ruby/pull/18052 `Proc#refined` on an already refined Proc is not memoized: the cache would be keyed on short-lived copies, and entries are retained for the VM's lifetime, so it would grow without bound. A performance warning is emitted under `Warning[:performance] = true`, and passing all the modules in a single call is more efficient. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125775] [Ruby Feature#22118] Introduce Basic Bit Operations into String
by hasumikin (hitoshi hasumi) 06 Aug '26

06 Aug '26

Issue #22118 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22118: Introduce Basic Bit Operations into String https://bugs.ruby-lang.org/issues/22118 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- This PR implements a subset of the specification proposed in the parent feature ticket #22082 PR URL: [placeholder to be updated] ## Methods implemented with the same specification as the parent ticket * `String#bit_at(offset, lsb_first: true) -> true | false | nil` * `String#bitwise_not -> String` * `String#bitwise_not! -> self` * `String#bitwise_and(other) -> String` * `String#bitwise_and!(other) -> self` * `String#bitwise_or(other) -> String` * `String#bitwise_or!(other) -> self` * `String#bitwise_xor(other) -> String` * `String#bitwise_xor!(other) -> self` ## Methods with range-oriented forms omitted for now The parent ticket also included range-oriented forms for some methods. In this PR, those range arguments are intentionally omitted, and the methods are limited to simpler forms. Range support can be considered as a future extension. * `String#bit_count -> Integer` * `String#bit_set(offset, lsb_first: true) -> self` * `String#bit_clear(offset, lsb_first: true) -> self` * `String#bit_flip(offset, lsb_first: true) -> self` In particular, `String#bit_count` currently takes no arguments. It does not accept a range, offset/length pair, or `lsb_first:` keyword. --- ## Remaining design questions even after narrowing the scope The overall direction of adding these methods has already been approved by Matz. The remaining questions are mostly about naming and API details. ### 1. Why the `bitwise_*` prefix is used In the parent ticket, all other methods are related to bit positions: they either take bit-position arguments, yield bit positions, or operate on a specified bit range. In contrast, the `bitwise_*` methods are whole-data operations. They apply to the entire string as a fixed-size bitmap and do not expose bit positions or bit ordering. The `bitwise_*` prefix is intended to make this distinction explicit. ### 2. Bit numbering #### `lsb_first: true` (default) Within each byte, `offset = 0` is the LSB. Numbering proceeds upward through byte[0] and then continues at the LSB of byte[1]: ```text byte[0] byte[1] offset: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ LSB LSB offset = byte_index * 8 + bit_in_byte ``` #### `lsb_first: false` for MSB-first Byte order is preserved (`byte[0]` is still first), but within each byte numbering starts at the MSB: ```text byte[0] byte[1] offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ MSB MSB offset = byte_index * 8 + (7 - bit_in_byte) ``` * Whether `lsb_first:` is needed at all, or whether an equivalent mechanism should exist under another name? * If such a mechanism is needed, whether `lsb_first:` is the right keyword name? * If `lsb_first:` is acceptable, should its default be `true`? My point is that `lsb_first:` is needed because both bit numbering conventions are used in real byte-buffer formats. LSB-first is the more common convention for general in-memory bitmap use, including formats and APIs such as Apache Arrow validity bitmaps, ext4 block bitmaps, Roaring bitmaps, Linux/BSD bitmap APIs, and hardware register descriptions. MSB-first is also needed for domains such as RFC-style network protocol diagrams, PNG low-bit-depth scanlines, BitTorrent bitfields, and some compressed bit streams. The keyword only controls bit numbering within each byte. Byte order itself is unchanged. ### 3. Out-of-range behavior `String#bit_at` returns `nil` when the bit offset is out of range. On the other hand, mutating methods such as `String#bit_set`, `String#bit_clear`, and `String#bit_flip` raise `IndexError` for an out-of-range bit offset. This follows the same general distinction as read-like access versus write-like access: reading a missing position can return `nil`, but mutating a missing position should not silently do nothing. ### 4. Negative bit offsets Negative bit offsets are rejected with `IndexError`. Although Ruby often uses negative indices to count from the end, combining negative bit offsets with the `lsb_first: true/false` mechanism would make the numbering rule harder to explain and reason about. The API keeps bit offsets as non-negative flat positions from the beginning of the string. ### 5. Length mismatch for binary bitwise operations `String#bitwise_and`, `String#bitwise_or`, and `String#bitwise_xor` require both operands to have the same byte size. If the byte sizes differ, they raise `ArgumentError`. This avoids implicit truncation or zero-padding. Since these methods operate on strings as fixed-size bitmaps, requiring equal sizes makes the operation explicit and predictable. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:126227] [Ruby Bug#22225] YJIT regenerates a branch while a duplicate target still points to the invalidated block
by cosgroveb (Brian Cosgrove) 05 Aug '26

05 Aug '26

Issue #22225 has been reported by cosgroveb (Brian Cosgrove). ---------------------------------------- Bug #22225: YJIT regenerates a branch while a duplicate target still points to the invalidated block https://bugs.ruby-lang.org/issues/22225 * Author: cosgroveb (Brian Cosgrove) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-03T03:11:21Z master f622e12503) +YJIT dev +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- YJIT adds one incoming-list entry for each branch target that points to a block. When both targets point to the same block, that block's incoming list contains the same `BranchRef` twice. `invalidate_block_version` processes those entries separately. For the first entry, it redirects one target and immediately calls `regenerate_branch`. The other target still references the invalidated block. The following assertion fails immediately before that call: ```patch diff --git a/yjit/src/core.rs b/yjit/src/core.rs index d08cd1fb26..4555081ae2 100644 --- a/yjit/src/core.rs +++ b/yjit/src/core.rs @@ -4282,6 +4282,18 @@ pub fn invalidate_block_version(blockref: &BlockRef) { } } + assert!( + branch.targets.iter().all(|target| unsafe { + // SAFETY: no mutation. + target + .ref_unchecked() + .as_ref() + .and_then(|target| target.get_block()) + != Some(*blockref) + }), + "regeneration started while a branch target still referenced the invalidated block" + ); + // Rewrite the branch with the new jump target address let old_branch_size = branch.code_size(); regenerate_branch(cb, branch); ``` This Ruby script triggers the assertion: ```ruby # duplicate_target_invalidation.rb module DuplicateTargetInvalidation TARGET = 1 def self.call(condition) if condition 1 else 2 end TARGET end end 3.times do |index| DuplicateTargetInvalidation.call(index.even?) end DuplicateTargetInvalidation.send(:remove_const, :TARGET) puts "completed" ``` Save the patch as `assert-no-invalidated-target-before-regeneration.patch` and the script as `duplicate_target_invalidation.rb`. From CRuby `ruby 4.1.0dev`: ```sh git apply assert-no-invalidated-target-before-regeneration.patch ./autogen.sh mkdir build cd build ../configure --enable-yjit=dev make -j"$(nproc)" ./ruby --yjit-call-threshold=1 ../duplicate_target_invalidation.rb ``` The process aborts before printing `completed`: ```text [BUG] YJIT: panicked at yjit/src/core.rs:4285:9: regeneration started while a branch target still referenced the invalidated block ``` regenerate_branch runs with one target redirected to a stub and the other still pointing at the invalidated block. That can leave generated code jumping back into code YJIT just invalidated. -- https://bugs.ruby-lang.org/

3 8