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

[ruby-core:125830] [Ruby Feature#22128] C API: Expose RB_OBJ_SET_FROZEN_SHAREABLE
by byroot (Jean Boussier) 24 Jun '26

24 Jun '26

Issue #22128 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22128: C API: Expose RB_OBJ_SET_FROZEN_SHAREABLE https://bugs.ruby-lang.org/issues/22128 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I'm trying to experiment with adapting Active Record for a Ractor architecture. Since database connections can't possibly be Ractor shareable, the idea is to warp each connection inside its own ractor, and then send SQL queries and responses through a port. But for this to perform well, I'd like to directly build the query response as a fully shareable object, so that it can be pushed into the port for free, instead of having Ruby need to recursively walk the potentially large response to mark objects as shareable. Here's an example of how it would work in trilogy: https://github.com/byroot/trilogy/commit/5f58200b398995d2fc0d4673a5a6bbccd0… ### Problem Unfortunately, the necessary API isn't currently exposed in the C API: - `RB_OBJ_SET_FROZEN_SHAREABLE` - `RB_OBJ_SET_SHAREABLE` / `rb_obj_set_shareable` I understand that this API could potentially be misused, but given it's a C API, I believe it's acceptable to require care from the caller. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125833] [Ruby Bug#22129] error_highlight raises NotImplementedError for ArgumentErrors that get wrapped
by rwstauner (Randy Stauner) 24 Jun '26

24 Jun '26

Issue #22129 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22129: error_highlight raises NotImplementedError for ArgumentErrors that get wrapped https://bugs.ruby-lang.org/issues/22129 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- With code like ```ruby def x(y:) = y begin x rescue => e p e.exception("wat").detailed_message end ``` a NotImplementedError is raised on ruby 4.0+ ```/Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/base.rb:297:in 'ErrorHighlight::Spotter#spot': NotImplementedError (NotImplementedError) from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/base.rb:68:in 'ErrorHighlight.spot' from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/core_ext.rb:34:in 'ErrorHighlight::CoreExt#generate_snippet' from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/core_ext.rb:43:in 'ErrorHighlight::CoreExt#detailed_message' from tiny.rb:6:in 'Exception#full_message' from tiny.rb:6:in '<main>' tiny.rb:1:in 'Object#x': missing keyword: :y (ArgumentError) caller: tiny.rb:4 | x ^ callee: tiny.rb:1 | def x(y:) = y ^ from tiny.rb:4:in '<main>' ``` on ruby 3.4 it did not raise: ``` tiny.rb:1:in 'x': wat (ArgumentError) from tiny.rb:4:in '<main>' ``` seems related to https://bugs.ruby-lang.org/issues/21543 I have a PR up at https://github.com/ruby/error_highlight/pull/78 -- https://bugs.ruby-lang.org/

1 0

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

24 Jun '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/

2 2

[ruby-core:125818] [Ruby Bug#22126] Stack underflow for partial DCE and loops
by viralpraxis (Iaroslav Kurbatov) 24 Jun '26

24 Jun '26

Issue #22126 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22126: Stack underflow for partial DCE and loops https://bugs.ruby-lang.org/issues/22126 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T13:29:36Z master 13fe77dd2b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ruby ruby --parser prism -e 'if []; else; a => [*, 42, *]; end' -- raw disasm-------- trace: 1 0000 putnil ( 1) 0001 leave ( 1) <L018> [sp: 1, unremovable: 0, refcnt: 1] 0002 dup ( 1) 0003 topn 2 ( 1) 0005 opt_le <calldata:<=, 1> ( 1) 0007 branchunless <L021> ( 1) 0009 topn 3 ( 1) 0011 topn 1 ( 1) 0013 opt_aref <calldata:[], 1> ( 1) 0015 putobject 42 ( 1) 0017 dupn 2 ( 1) 0019 checkmatch 2 ( 1) 0021 dup ( 1) 0022 branchif <L023> ( 1) 0024 putspecialobject 1 ( 1) 0026 putobject "%p === %p does not return true" ( 1) 0028 topn 3 ( 1) 0030 topn 5 ( 1) 0032 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0034 setn 10 ( 1) 0036 putobject false ( 1) 0038 setn 12 ( 1) 0040 pop ( 1) 0041 pop ( 1) <L023> [sp: 4, unremovable: 0, refcnt: 1] 0042 setn 2 ( 1) 0044 pop ( 1) 0045 pop ( 1) 0046 branchif <L020> ( 1) 0048 putobject_INT2FIX_1_ ( 1) 0049 opt_plus <calldata:+, 1> ( 1) 0051 jump <L018> ( 1) <L021> [sp: 1, unremovable: 0, refcnt: 1] * 0053 adjuststack 3 ( 1) 0055 putspecialobject 1 ( 1) 0057 putobject "%p does not match to find pattern" ( 1) 0059 topn 2 ( 1) 0061 opt_send_without_block <calldata:core#sprintf, 2> ( 1) 0063 setn 4 ( 1) 0065 putobject false ( 1) 0067 setn 6 ( 1) 0069 pop ( 1) 0070 pop ( 1) 0071 jump <L012> ( 1) <L020> [sp: 1, unremovable: 0, refcnt: 1] 0073 adjuststack 3 ( 1) 0075 pop ( 1) 0076 jump <L003> ( 1) <L012> [sp: -1, unremovable: 0, refcnt: 1] 0078 pop ( 1) 0079 putspecialobject 1 ( 1) 0081 topn 4 ( 1) 0083 branchif <L024> ( 1) 0085 putobject NoMatchingPatternError ( 1) 0087 putspecialobject 1 ( 1) 0089 putobject "%p: %s" ( 1) 0091 topn 4 ( 1) 0093 topn 7 ( 1) 0095 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0097 opt_send_without_block <calldata:core#raise, 2> ( 1) 0099 jump <L025> ( 1) <L024> [sp: -1, unremovable: 0, refcnt: 1] 0101 putobject NoMatchingPatternKeyError ( 1) 0103 putspecialobject 1 ( 1) 0105 putobject "%p: %s" ( 1) 0107 topn 4 ( 1) 0109 topn 7 ( 1) 0111 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0113 topn 7 ( 1) 0115 topn 9 ( 1) 0117 opt_send_without_block <calldata:new, 3> ( 1) 0119 opt_send_without_block <calldata:core#raise, 1> ( 1) <L025> [sp: -1, unremovable: 0, refcnt: 1] 0121 adjuststack 7 ( 1) 0123 putnil ( 1) 0124 leave ( 1) <L003> [sp: -1, unremovable: 0, refcnt: 1] 0125 adjuststack 6 ( 1) 0127 putnil ( 1) 0128 leave ( 1) --------------------- -e:1: argument stack underflow (-2) -e: compile error (SyntaxError) ``` proposed patch: https://github.com/ruby/ruby/pull/17449 every version since 3.4.0-preview2 is affected -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125650] [Ruby Feature#22097] Add Proc#with_refinements
by shugo (Shugo Maeda) 24 Jun '26

24 Jun '26

Issue #22097 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22097: Add Proc#with_refinements https://bugs.ruby-lang.org/issues/22097 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract I propose `Proc#with_refinements` to support block-level refinements. ```ruby module StringExt refine String do def shout = upcase + "!" end end original = ->(s) { s.shout } refined = original.with_refinements(StringExt) p refined.call("hello") # "HELLO!" p original.call("hello") # NoMethodError ``` ## Background and Motivation I previously proposed `Proc#using` in [Feature #16461], but it introduced semantic complexities because it mutated existing blocks. Instead of mutating the existing block, `Proc#with_refinements` returns a new `Proc` object with its own isolated call sites. This approach makes its semantics much simpler than `Proc#using`, and it avoids thread-safety issues and plays nicely with inline caches. ## Limitation Similar to `Proc#binding`, `Proc#with_refinements` raises ArgumentError if the receiver is not created from a Ruby block. ```ruby :to_s.to_proc.with_refinements(StringExt) #=> ArgumentError ``` ## Implementation I've opened a pull request: https://github.com/ruby/ruby/pull/17248 A PoC for JRuby is also available at: https://github.com/shugo/jruby/pull/2 ### Data structure changes * Added a bit field `has_refinements` to `rb_proc_t`. * Added a hidden instance variable to `Proc` to store a `cref` with the applied refinements. * Added a single-entry cache `refinement_memo` to `rb_iseq_constant_body`. ### Deep copy of iseq and caching `Proc#with_refinements` performs a deep copy of the receiver's `iseq` to isolate its call sites from the original `Proc`. While a deep copy can be an expensive operation, the single-entry cache in `rb_iseq_constant_body` mitigates this overhead effectively for most practical use cases where the same refinements are applied repeatedly. ### Overhead for code not using Proc#with_refinements * Memory footprint: Neither internal structure grows in size. `has_refinements` is a 1-bit field added to rb_proc_t's existing bit field, and `refinement_memo` shares a union with `mandatory_only_iseq` in rb_iseq_constant_body. * Execution speed: The common `Proc#call` path is kept frameless and only adds a single `has_refinements` bit check. * GC: The mark/free/memsize functions add a single branch per `iseq` to select the union member. Benchmark results: https://gist.github.com/shugo/ddfe92f28ea31e6527a2f270e6daee7c Here's an excerpt from the results, where `compare-ruby` is master and `built-ruby` is the branch for this feature (focusing on Proc/Block operations): | |compare-ruby|built-ruby| |:------------------------------------|-----------:|---------:| |vm_proc | 47.215M| 46.149M| | | 1.02x| -| |vm_yield | 1.649| 1.754| | | -| 1.06x| -- https://bugs.ruby-lang.org/

3 8

[ruby-core:125796] [Ruby Feature#22121] Introduce Parallel Sweep feature
by luke-gru (Luke Gruber) 23 Jun '26

23 Jun '26

Issue #22121 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22121: Introduce Parallel Sweep feature https://bugs.ruby-lang.org/issues/22121 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Abstract Ruby's GC sweep implementation is currently incremental and lazy. This is to reduce pause times when sweeping. However, the sweep implementation doesn't take advantage of parallelism (multi-core). Sweeping in a GC is not an "embarassingly parallel" problem, but extra threads can help. I would like to introduce such a feature to Ruby so that users can take advantage of their multi-core CPUs to reduce GC pause times. ## Design I would like to have an additional "sweep thread" that sweeps alongside the Ruby GC thread (in parallel) and at the same time as Ruby code is running (concurrent). When the sweep thread is working alongside the Ruby GC thread, both threads grab pages from the current heap. If the sweep thread has already swept a page, the Ruby GC thread finishes it by clearing its bitmaps and adding the page to the free pages or empty pages lists. If there are no swept pages from the sweep thread, the Ruby GC thread sweeps a page by itself instead of waiting for swept pages. When an incremental sweep step is over, the sweep thread sweeps 1 incremental step's budget worth of slots while Ruby code is running. This is so that during the next incremental step, the Ruby GC thread just has to finish the pages off instead of sweeping the objects. ## Limitations Certain objects aren't safe to be freed by the sweep thread. T_DATA types from native extensions cannot be swept in general (although most are safe) because the user's sweep function may not be thread-safe. That function may modify global state in such a way that when it is called from both the sweep thread AND the Ruby GC thread at once, it behaves badly. In order to get around this, we introduce a new [TypedData flag](https://github.com/ruby/ruby/pull/17395). T_DATA internal to the VM mostly have this flag set, and native extension authors can set this flag if it is defined to allow their type to be swept concurrently. This feature is only available for the default GC. Ruby's MMTK garbage collector has its own implementation of concurrent sweeping that is not affected by this feature. This feature is only available for pthread platforms, although that restriction could be lifted with a bit of work. This feature is not on by default (see section `Building`). ## Implementation The [PR](https://github.com/ruby/ruby/pull/17411) is currently a draft, but it's in a working state. Please play with it and tell me what you think! ## Building ```bash ./configure --enable-parallel-sweep make -j ./ruby --enable-parallel-sweep -v #=> ruby 4.1.0dev (2026-06-19T15:49:17Z parallel-sweep cd7e59d45b) +PRISM +Parallel-Sweep [arm64-darwin25] ``` ## Benchmarks This image below is from running [ruby-bench](https://github.com/ruby/ruby-bench) `--headline` benchmarks 10 times and taking the median of means of the runs. The ruby-bench command was: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --headline ``` If you want sweep info per run, you can run it with the GC harness: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --harness=gc --headline ``` <img style="width: 1219px;" src="clipboard-202606191327-7umxq.png"><br> I encourage others to experiment with this feature, run your own benchmarks and share them here. When running your benchmarks, make sure not to pin the process to a CPU with `taskset`, otherwise the sweep thread will not run in parallel. > [!NOTE] > Sometimes there are regressions run to run. Run the benchmark 5-10 times to get more accurate results. > GC micro-benchmarks may not see any improvements or even slight regressions. The implementation targets a workload where there is sufficient time in between sweep steps for the sweep thread to do its work. > [!WARNING] > Benchmarking on MacOS tends to be less accurate than Linux. However, if that's all you have and want to share your results, please do. ## Future Work In the future, I would like it if we could process the metadata of a page in the sweep thread. For example, if we could clear the bitmaps and unlink an empty page, or even add a page to the free pages list then the Ruby pause time would get even smaller (or none at all). I did have a prototype of this, but it caused issues because it was creating too many empty pages too fast, and that had unintended consequences for the rest of the GC. I also believe parallel marking would have a large benefit. Major GCs take a long time due to marking, and if you have lots of threads of fibers than it takes even longer. Marking is a more naturally parallel problem, so would likely benefit from more than 1 worker thread. ---Files-------------------------------- clipboard-202606191327-7umxq.png (342 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:125811] [Ruby Bug#22125] IO::Buffer triggers use-after-free when it's freed/resized during enumeration
by hanazuki (Kasumi Hanazuki) 23 Jun '26

23 Jun '26

Issue #22125 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22125: IO::Buffer triggers use-after-free when it's freed/resized during enumeration https://bugs.ruby-lang.org/issues/22125 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T09:56:24Z master 55945e5c98) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The block passed to `IO::Buffer#each` can free or resize the receiver (or its parent buffer when the reciver is a slice), which invalidates the memory region being iterated. The next iteration causes use-after-free. repro: ``` ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.resize(20) }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b.free }' # No use-after-free but I think those should be errors too ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b1.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.transfer }' ``` same for `#each_byte`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125714] [Ruby Misc#22107] DevMeeting-2026-07-09
by mame (Yusuke Endoh) 23 Jun '26

23 Jun '26

Issue #22107 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #22107: DevMeeting-2026-07-09 https://bugs.ruby-lang.org/issues/22107 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/07/09 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/07/06. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125265] [Ruby Feature#21998] Add {Method,UnboundMethod,Proc}#source_range
by Eregon (Benoit Daloze) 23 Jun '26

23 Jun '26

Issue #21998 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21998: Add {Method,UnboundMethod,Proc}#source_range https://bugs.ruby-lang.org/issues/21998 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I'm using matz's suggestion almost as-is from https://bugs.ruby-lang.org/issues/6012#note-53. The only change is the proposed class name. ## Use Cases Use cases have been discussed extensively and matz said: > The use cases are real and I want to support them So I think we don't need to discuss that anymore :) ## Background Adding column and last line information to `#source_location` is deemed too incompatible given the usages of `obj.source_location.last` which expect the start line (they would get the end column instead). ## Proposal So instead we add a new method, `{Method,UnboundMethod,Proc}#source_range`, which returns a `Ruby::SourceRange` and has these methods: * `start_line`: 1-indexed (same as `source_location.first`) * `end_line`: 1-indexed * `start_column`: in bytes, 0-indexed, I think `start_byte_column` could be good for extra clarity * `end_column`: in bytes, 0-indexed, I think `end_byte_column` could be good for extra clarity * `inspect` which shows something like `#<Ruby::SourceRange (1,0)-(2,10)>`. For the edge case of a heredoc spanning further than the end of a method/block, we would not include it in the `end_line` & `end_column` methods, but instead document it and provide a small code snippet in the docs to compute that if desired with Prism. ## Alternative An alternative could be a `Ruby::SourceLocation` class and `obj.source_location(object: true)`/`obj.source_location(extended: true)` but it feels less nice. Since we are designing something new I think it's best to go for the cleanest design. ## Consistency The above methods match the name of methods on `Prism::Node` and have the same semantics, which is good for consistency and to avoid confusion. ## Scope The scope is intentionally minimal to keep the discussion focused. ## Implementation I'm happy to implement this, it should be pretty trivial and very similar to the extended `source_location`. I would prefer to get an approval for this feature before implementing. -- https://bugs.ruby-lang.org/

6 21

[ruby-core:125821] [Ruby Bug#22127] parse.y regexp crash on invalid encoding
by kddnewton (Kevin Newton) 23 Jun '26

23 Jun '26

Issue #22127 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22127: parse.y regexp crash on invalid encoding https://bugs.ruby-lang.org/issues/22127 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ./ruby --parser=parse.y -e '/#{"\xcd"}/' ``` results in a segfault -- https://bugs.ruby-lang.org/

1 0