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

[ruby-core:124418] [Ruby Feature#21826] Deprecating RubyVM::AbstractSyntaxTree
by Eregon (Benoit Daloze) 07 Aug '26

07 Aug '26

Issue #21826 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21826: Deprecating RubyVM::AbstractSyntaxTree https://bugs.ruby-lang.org/issues/21826 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I think it is time to deprecate `RubyVM::AbstractSyntaxTree`. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/) so it's clear the official Ruby parsing API is the Prism API. `RubyVM::AbstractSyntaxTree` is CRuby-specific and does not work on any other Ruby implementation, the API is unstable, inconvenient, etc: > This module is experimental and its API is not stable, therefore it > might change without notice. As examples, the order of children nodes is > not guaranteed, the number of children nodes might change, there is no > way to access children nodes by name, etc. Because it's under `RubyVM`, it also has the following documented caveats: > This module is for very limited purposes, such as debugging, prototyping, and research. > Normal users must not use it. This module is not portable between Ruby implementations. Given these caveats I think it could possibly be fair enough to remove it without deprecation, however I see no urgency to remove it straight away so I think having it deprecated for one release is nicer for the few gems using it. The advantages of deprecating it are: * Make it clear that this API should not be used in new code * Encourage the few usages to migrate to the Prism API, which is stable, officially supported, designed with many people to be usable and convenient for every parsing/tooling usage, etc. * Improve portability of Ruby code between Ruby implementations So, let's deprecate `RubyVM::AbstractSyntaxTree` in 4.1, and remove it in 4.2? -- https://bugs.ruby-lang.org/

5 6

[ruby-core:125966] [Ruby Feature#22186] Increase the embeddable size limit for substrings created by `str_subseq()`
by himura467 (Akito Shitara) 07 Aug '26

07 Aug '26

Issue #22186 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22186: Increase the embeddable size limit for substrings created by `str_subseq()` https://bugs.ruby-lang.org/issues/22186 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ## Summary `str_subseq()` unnecessarily limits how large a sharable middle substring can be while still being embedded into the new `RString`. Substrings roughly 24 to 1000 bytes long (on a 64-bit build) always take the shared path, even though variable width allocation (VWA, Feature #18239) already supports embedding objects of that size. I propose sizing the allocation to the actual substring length via `STR_EMBEDDABLE_P()` / `str_alloc_embed()`, the same pattern used by other allocation sites in `string.c`, instead of allocating through `str_alloc_heap()` and checking whether the substring fits in the smallest heap slot class. ## Background For a sharable substring (per `SHARABLE_SUBSTRING_P`), `str_subseq()` either embeds the bytes directly into the new `RString`, or shares the parent's heap buffer, which keeps the parent alive. Since [commit 132f097149](https://github.com/ruby/ruby/commit/132f097149af36cb77308d9fe1c…, the decision has been: ```c str2 = str_alloc_heap(rb_cString); if (str_embed_capa(str2) >= len + termlen) { // embed } else { // share } ``` `str_alloc_heap()` always allocates the default `sizeof(struct RString)` slot regardless of `len`, so `str_embed_capa(str2)` is capped at roughly 23 bytes. Meanwhile the default GC's size pools go up to 1024 bytes on 64-bit builds, and other allocation sites (`str_enc_new` behind `rb_str_new`, `rb_str_buf_new`, `str_new_frozen_buffer`, `rb_str_times`, ...) already pick the right-sized slot via `STR_EMBEDDABLE_P()` / `str_alloc_embed()`. ## Proposed change Draft PR: https://github.com/ruby/ruby/pull/17723 Check `STR_EMBEDDABLE_P(len, termlen)` up front and allocate with `str_alloc_embed()`; only allocate the `STR_NOEMBED` heap object on the sharing branch. Behavior is unchanged for substrings that aren't sharable or that reach the end of the parent's buffer. Only the threshold at which a sharable middle substring switches from embedding to sharing grows. ## Benchmark results Using [ruby-bench](https://github.com/ruby/ruby-bench), this branch vs current master (`arm64-darwin25`, `+PRISM`). Top 3 and bottom 3 by ratio (master/branch, higher is better): | bench | master (ms) | current (ms) | ratio | | ---- | ---- | ---- | ----- | | fluentd | 258.6 | 230.8 | 1.120 | | ruby-json | 154.1 | 150.2 | 1.026 | | liquid-c | 31.2 | 30.6 | 1.022 | | graphql-native | 172.0 | 174.9 | 0.983 | | activerecord | 148.7 | 153.0 | 0.972 | | psych-load | 1244.9 | 1291.4 | 0.964 | Note that most except fluentd varies between runs. The fluentd improvement reproduces across runs, while the entries in the bottom 3 do not. So the few 2-4% slowdowns may be noise, but I'd like to verify them with more runs and machines before treating this as risk-free. ## Relation to Feature #19315 #19315 (sharable middle substrings) addresses the same underlying problem: middle substrings copy unnecessarily. The branch benchmarked in https://bugs.ruby-lang.org/issues/19315#note-52 actually included this embed size change as one of its commits, in addition to enabling `SHARABLE_MIDDLE_SUBSTRING`. To isolate the two, I benchmarked a variant of that branch with only the embed size change reverted ([rstring-raw-ptr-reverted](https://github.com/himura467/ruby/tree/rstring-ra…) alongside this proposal, against the same master: | bench | master (ms) | this proposal (ms) | #19315 without this change (ms) | | ---- | ---- | ---- | ---- | | fluentd | 256.9 | 207.2 (x1.240) | 255.6 (x1.005) | The clear `fluentd` improvement seen in note-52 reproduces with this change alone, and disappears when this change is reverted from the #19315 branch. So the practical win observed on ruby-bench so far is attributable to the larger embed threshold rather than to `SHARABLE_MIDDLE_SUBSTRING` itself. Beyond that, this change is much narrower: - A self-contained fix to one function, reusing the VWA embedding infrastructure already battle-tested elsewhere in `string.c`. - No API/ABI implications; `RSTRING_PTR()`'s `\0`-termination guarantee is untouched. - No memory-retention risk, since embedding copies the bytes instead of referencing the parent. The two are orthogonal (#19315 still helps for slices too large to embed, as its micro-benchmarks show), but this smaller fix seems worth landing first on its own merits. ---Files-------------------------------- output_001.txt (7.76 KB) output_001-ratio-current.png (184 KB) output_002.txt (14.9 KB) -- https://bugs.ruby-lang.org/

3 15

[ruby-core:126315] [Ruby Feature#14394] Class.descendants
by shugo (Shugo Maeda) 07 Aug '26

07 Aug '26

Issue #14394 has been updated by shugo (Shugo Maeda). Status changed from Assigned to Closed Module#descendants was added instead of Class#descendants, so I'm closing this issue. See #9779 for details. ---------------------------------------- Feature #14394: Class.descendants https://bugs.ruby-lang.org/issues/14394#change-118425 * Author: ridiculous (Ryan Buckley) * Status: Closed * Assignee: ko1 (Koichi Sasada) ---------------------------------------- There have been numerous implementations of the method Class.descendants by various gems. However, I can't help but think that this ability should be included in the Ruby language itself. Especially since Ruby already offers the counterpart method Class.ancestors. Would it possible to add a `descendants` class method? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126309] [Ruby Feature#22233] Warn when Net::HTTP#set_debug_output enables debug output
by adam.sligar＠getquip.com (Adam Sligar) 06 Aug '26

06 Aug '26

Issue #22233 has been reported by adam.sligar(a)getquip.com (Adam Sligar). ---------------------------------------- Feature #22233: Warn when Net::HTTP#set_debug_output enables debug output https://bugs.ruby-lang.org/issues/22233 * Author: adam.sligar(a)getquip.com (Adam Sligar) * Status: Open ---------------------------------------- # Abstract `Net::HTTP#set_debug_output` logs every request and response in plain text, including `Authorization` and `Cookie` headers and message bodies. Its documentation says never to use it in production, and nothing enforces that. I propose writing a warning to `$stderr` when debug output is enabled, at most once per thread. # Background The method has carried this documentation for as long as it has existed: # *WARNING* This method opens a serious security hole. # Never use this method in production code. The advice is sound and there is nothing behind it. The method behaves identically in a console and in a production worker, so debug output committed by accident, or enabled by hand during an incident and never reverted, keeps writing credentials to whatever stream it was given. The credentials are then retained and indexed. The only warning the method has today concerns call ordering, not safety: warn 'Net::HTTP#set_debug_output called after HTTP started', uplevel: 1 if started? # Proposal Warn when `set_debug_output` is enabled: $ ruby -rnet/http -e 'Net::HTTP.new("example.com").set_debug_output($stdout)' -e:1: warning: Net::HTTP#set_debug_output: every request and response, including Authorization and Cookie headers and message bodies, will be written to the given stream in plain text; never enable this in production Nothing is written when: * `$DEBUG` is set. Ruby already has a flag meaning "this process is being debugged", and enabling wire logging under it is deliberate. `net/http`'s own test harness reads it the same way, in `test/net/http/utils.rb`. * `output` is `nil`, which disables debug output rather than enabling it. * the warning has already been written on this thread. The once-per-thread flag lives in thread-local storage. `set_debug_output` is a configuration setter that `net/http` never calls itself, so a connection configured once and reused pays nothing per request. But wrappers that build a `Net::HTTP` per request and configure it each time would otherwise repeat an identical message on every request and flood the log the warning is meant to draw attention to. Thread-local storage rather than a class-level instance variable because assigning the latter from a non-main Ractor raises `Ractor::IsolationError`, and `Thread#thread_variable_set` has been available since 2.0, so no version guard is needed. # Use cases * A `set_debug_output` call reaches production in a release. Today the first sign is credentials in the log store. * Debug output is enabled while diagnosing a production incident and not reverted. The next deploy carries it forward silently. * A gem enables debug output on a connection it owns. The application never sees the call and today gets no indication that its requests are being logged. # Discussion **Why not detect production and warn only there?** Because Ruby has no concept of an application environment to consult. No file in `lib/` reads `RAILS_ENV`, `RACK_ENV` or `APP_ENV`; there is no `RUBY_ENV`; `RbConfig` describes the build, not the deployment. Reading a framework's variable would put knowledge of that framework into the standard library and force it to pick a side. Rails, which resolves `RAILS_ENV` then `RACK_ENV`, and Sinatra, which resolves `APP_ENV` then `RACK_ENV`, etc. It would also still miss the case most relevant to a standard library: a script with no framework and no variables set. Warning unconditionally and exempting `$DEBUG` avoids all of it and covers more. **Why not gate on `$VERBOSE`?**`$VERBOSE` is false unless `-w` is passed, which would hide this in exactly the unattended runs it exists to catch. The existing "called after HTTP started" warning in this same method is not gated either. **Why not a `Warning` category?** Of the categories Ruby 4.0 defines (`:deprecated`, `:experimental`, `:performance`, `:strict_unused_block`), only `:experimental` is enabled by default, and none of them describes this. A guardrail nobody has enabled does not guard anything. If ruby-core would prefer a category, an always-on `:security` category has precedent in `:experimental` and would be a reasonable separate proposal; I would rather not block this on introducing one. The warning can already be intercepted by overriding `Warning.warn`. **Why not deprecate the method?** It is intended to exist and is useful. `Warning[:deprecated]` is also off by default, so a deprecation would be invisible in production. Feature #19630 used deprecation correctly because that behavior genuinely was scheduled for removal. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126105] [Ruby Bug#22200] ObjectSpace._id2ref can return a different object than the id's owner on Ruby 4.0 (stale id2ref_tbl entry for objects with generic fields)
by navidemad (Navid Emad) 06 Aug '26

06 Aug '26

Issue #22200 has been reported by navidemad (Navid Emad). ---------------------------------------- Bug #22200: ObjectSpace._id2ref can return a different object than the id's owner on Ruby 4.0 (stale id2ref_tbl entry for objects with generic fields) https://bugs.ruby-lang.org/issues/22200 * Author: navidemad (Navid Emad) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin23] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On Ruby 4.0.x, `ObjectSpace._id2ref(id)` can return a **different, unrelated live object** instead of raising `RangeError`, after the object that owned the id has been garbage collected and its heap slot reused. Observed returns in the reproduction below include recycled strings, `Thread::Backtrace` instances and previously-raised `RangeError` exception objects. Ruby ≤ 3.4 is not affected. Ruby master is not affected because `_id2ref` was removed ([Feature #22135], commit df062232), so this is a 4.0-branch-only bug — but 4.0 is the current stable release and `_id2ref` is still callable there (with a deprecation warning). Tested and reproduced on 4.0.2, 4.0.5 and 4.0.6 (arm64-darwin23); production crashes caused by the same mechanism were observed on 4.0.5 x86_64-linux (see "Real-world impact"). ## Root cause Since the object_id redesign ([Feature #15408]), the id lives in the object itself and `id2ref_tbl` (lazily built on first `_id2ref` call) is the only id → object mapping. Entry deletion happens in `obj_free_object_id`, called from sweep via `rb_gc_obj_free_vm_weak_references`, and depends on where the id is stored (gc.c, v4.0.5, `obj_free_object_id`): * `T_OBJECT` (id in its own fields) and `T_CLASS`/`T_MODULE` (id in `RCLASS->object_id`): the entry is deleted when the owner itself is swept — same as ≤ 3.4. * **Every other type** (String, Array, Hash, Data, ... — id stored in the companion `T_IMEMO/fields`): the owner's sweep hits `default: return;` ("For generic_fields, the T_IMEMO/fields is responsible for freeing the id") and only detaches the imemo via `rb_free_generic_ivar`, which does not touch `id2ref_tbl`. The entry is deleted only when **the imemo is swept**. The owner and its imemo generally live in different size pools, so under lazy sweeping their sweeps are separated by arbitrary amounts of Ruby execution. In that window `id2ref_tbl` still maps a valid id to a freed slot. The only gate on lookup is `rb_gc_impl_garbage_object_p`, which catches `T_NONE`/`T_MOVED`/`T_ZOMBIE` and unswept garbage during lazy sweeping — it cannot catch a *recycled* slot, whose new occupant is a perfectly live object. `object_id_to_ref` then returns that occupant instead of raising `RangeError`. (Note the weak-table pass over `id2ref_tbl` via `rb_gc_vm_weak_table_foreach` only runs during compaction reference updating, so ordinary GC cycles never purge these dangling entries.) On ≤ 3.4 this window cannot exist: `obj_free_object_id` deleted both `obj_to_id_tbl`/`id_to_obj_tbl` entries for every freed object in the same sweep step that frees the slot. ## Reproduction ```ruby # MODE=string -> owners are Strings (generic fields, deferred deletion) => bug on 4.0 # MODE=object -> owners are T_OBJECTs (id in own fields, eager deletion) => control Warning[:deprecated] = false OWNERS = Integer(ENV["OWNERS"] || 50_000) MODE = ENV["MODE"] || "string" BATCHES = Integer(ENV["BATCHES"] || 60) PROBES_PER_BATCH = Integer(ENV["PROBES_PER_BATCH"] || 300) RECYCLERS_PER_BATCH = Integer(ENV["RECYCLERS_PER_BATCH"] || 1_000) srand(42) def probe(id) ObjectSpace._id2ref(id) end # Make id2ref_tbl exist before owners get their ids, so each object_id call # inserts an entry (gc.c object_id0). anchor = Object.new probe(anchor.object_id) # Allocate all owners first (their pages come earlier in sweep order), then # take object_ids afterwards (imemos land on later pages / another pool). owners = if MODE == "string" Array.new(OWNERS) { |i| +"owner-#{i}" } else Array.new(OWNERS) { |i| o = Object.new; o.instance_variable_set(:@owner, i); o } end ids = owners.map(&:object_id) owners = nil GC.start(full_mark: true, immediate_sweep: false) dead = 0 alive_original = 0 wrong = Hash.new(0) wrong_samples = [] recyclers = [] BATCHES.times do |batch| recyclers.concat(Array.new(RECYCLERS_PER_BATCH) { +"recycler-#{batch}" }) PROBES_PER_BATCH.times do id = ids.sample begin obj = probe(id) original = if MODE == "string" obj.instance_of?(String) && obj.start_with?("owner-") else obj.instance_of?(Object) && obj.instance_variable_defined?(:@owner) end if original alive_original += 1 # kept alive by conservative stack refs; not a bug else wrong[obj.class] += 1 wrong_samples << obj.inspect[0, 60] if wrong_samples.size < 10 end rescue RangeError dead += 1 end end end puts RUBY_DESCRIPTION puts "mode=#{MODE} owners=#{OWNERS}" puts " RangeError (correct): #{dead}" puts " returned original (alive): #{alive_original}" puts " returned WRONG object (BUG): #{wrong.values.sum} #{wrong.sort_by { |_, v| -v }.to_h}" wrong_samples.each { |s| puts " e.g. #{s}" } exit(wrong.values.sum > 0 ? 1 : 0) ``` Results (18,000 probes per run): | Ruby | owners | wrong-object returns | |---|---|---| | 4.0.2 | String (generic fields) | 4 | | 4.0.5 | String (generic fields) | 12 | | 4.0.6 | String (generic fields) | 12 | | 4.0.5 | `T_OBJECT` (control) | 0 | | 3.4.10 | String (control) | 0 | Sample of what `_id2ref(dead_string_id)` returned instead of raising, on 4.0.6: ``` "recycler-0" # the object recycled into the slot #<Thread::Backtrace:0x0000000122507710> # a VM-internal object #<RangeError: "67488" is a recycled object> # an exception raised by an earlier probe ``` Two notes for reproducing: * `GC.disable` must not be used: under `dont_gc`, allocation never drives lazy sweeping (`heap_prepare` grows the heap instead), so slots are never recycled and every probe is correctly caught by the unswept-garbage branch of `rb_gc_impl_garbage_object_p`. * The dangling-entry zone moves with the sweep cursors (`gc_sweep_continue` advances one page in every heap per step), hence the randomly-sampled probes. ## Real-world impact This is the root cause of https://github.com/DataDog/dd-trace-rb/issues/5936: the datadog gem's heap profiler tracks sampled objects by object_id and resurrects them with `_id2ref` at serialization time, relying on the ≤ 3.4 contract "the exact object or `RangeError`". On 4.0 it receives arbitrary slot occupants and calls `rb_obj_memsize_of()` on them; production crash dumps show SIGSEGVs in three distinct type branches of `rb_obj_memsize_of` (`T_CLASS` classext walk, `T_REGEXP` `onig_memsize`, `T_DATA` `rb_objspace_data_type_memsize`) — full dumps in https://gist.github.com/navidemad/e6ed6e38fad5b3ebe9e89f553f7562ba. Datadog has since disabled the feature on 4.0 (https://github.com/DataDog/dd-trace-rb/pull/6022) Beyond that particular consumer, `_id2ref` handing out arbitrary live objects (including VM-internal ones like `Thread::Backtrace`) to any caller holding a stale integer id seems undesirable for remaining `_id2ref` users (e.g. DRb) even during the deprecation period. ## Possible fix direction At owner sweep time the id is no longer reachable from the owner (its shape may already have been reset by the generic-fields weak-table pass), so the natural place to delete the `id2ref_tbl` entry for a dead generic-fields owner appears to be the GC's weak-table processing of `generic_fields_tbl` (`vm_weak_table_gen_fields_foreach`, `ST_DELETE` case): at that point the imemo is still intact, so its id can be read and the `id2ref_tbl` entry removed there, restoring the ≤ 3.4 guarantee that an entry never outlives its owner. [Feature #15408]: https://bugs.ruby-lang.org/issues/15408 [Feature #22135]: https://bugs.ruby-lang.org/issues/22135 -- https://bugs.ruby-lang.org/

5 7

[ruby-core:126308] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by matz (Yukihiro Matsumoto) 06 Aug '26

06 Aug '26

Issue #18947 has been updated by matz (Yukihiro Matsumoto). Please go ahead with this approach. Relying on an undocumented bit is not ideal, but the failure mode decides it for me: if the bit ever stops working, we are back to today's 260 character limit, not broken. That is a cheap downside for fixing a four year old problem that the `\\?\` alternative cannot fully fix anyway. I leave the embedder question to you. Whichever way you go, please document the limitations you found in [#note-9](https://bugs.ruby-lang.org/issues/18947#note-9): the 255 character limit per path component, and that spawning a child process from a working directory longer than 260 characters still fails. Matz. ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118414 * Author: inversion (Yura Babak) * Status: Open * Assignee: windows * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On Windows 10, I am working on a script to copy a complex folder structure. Pathname and FileUtils work fine for me until there is a folder with a **very long path** (>260 chars). Normally you cannot access such a folder with Ruby. The next operations will raise `Errno::ENOENT` ``` ruby Pathname.new(300_chars_path).children FileUtils.mkpath(300_chars_path) ``` But there is a way in Windows to remove the MAX_PATH limitation. You can find a small .reg file in this article: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-lim… After changing this system option, things start to work strangely in Ruby. This will now raise `Errno::ENAMETOOLONG`: ``` ruby Pathname.new(300_chars_path).children ``` But at the same time, you can create a folder with such a long path and write-read a file in it ``` ruby FileUtils.mkpath(300_chars_path) file = Pathname.new(300_chars_path+'/file.txt') file.write 'oooooooooo' puts Pathname.new(300_chars_path+'/file.txt').read ``` So you can work with individual items but attempts to list such folders' content fail (`.children`, `.glob`, `.copy`, etc). In my case, deep `.glob` is broken for all the parent folders of that deep long-path folder (( The only way I found for listing is ``` ruby require 'win32ole' fso = WIN32OLE.new 'Scripting.FileSystemObject' for file in fso.GetFolder(300_chars_path).files file.name file.path.length end ``` But using this workaround breaks all my code workflow built on top of Pathname and FileUtils ((. So for me, it looks like some operations with long-path folders are not working just because in Ruby there is a check for the path length and not a real operation problem. And in some places (see .mkpath) there is no such check and all works fine. Also notice that other applications on Windows have no problems with long-path folders (like Total Commander). Please consider reviewing if we really need to raise `Errno::ENAMETOOLONG` if the `LongPathsEnabled` option is enabled in the Windows registry. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 06 Aug '26

06 Aug '26

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

8 21

[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