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

[ruby-core:126019] [Ruby Feature#16757] Add intersection to Range
by matz (Yukihiro Matsumoto) 10 Jul '26

10 Jul '26

Issue #16757 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed Closing this issue. We have accepted `Range#clamp` (#22175), which covers the main use case here: restricting a range to given bounds. For overlapping ranges it gives the same result as an intersection would. I do not want to add a general `Range#intersection` (or `Range#&`). It raises semantic questions with no obviously right answer, such as what to return for disjoint ranges (`nil`, an empty range, or an exception). More fundamentally, it frames Range as a set-like collection, which invites `Range#union` next, and union of two ranges cannot be defined in general because the result may be discontiguous. I prefer to keep Range out of set algebra. Matz. ---------------------------------------- Feature #16757: Add intersection to Range https://bugs.ruby-lang.org/issues/16757#change-117998 * Author: stuyam (Stuart Yamartino) * Status: Closed ---------------------------------------- It would be great if there was a way to do an intersection with ranges. I wrote a method recently to solve this but it gets complicated and doesn't solve for all edge cases. The example I was using it for was getting the intersection of two date ranges. I was using it to calculate pricing discounts for overlapping dates for a reservation system. I would propose something like: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)) & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)) => Wed, 15 Apr 2020..Mon, 20 Apr 2020 ``` There are a handful of array methods that you can just convert a range to and do on an arrays rather than the ranges themselves, like so: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)).to_a & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)).to_a => [Wed, 15 Apr 2020, Thu, 16 Apr 2020, Fri, 17 Apr 2020, Sat, 18 Apr 2020, Sun, 19 Apr 2020, Mon, 20 Apr 2020] ``` There are a few issues with this however: 1. Performance: creating the ranges into arrays and doing array calculations can me slower based on the span of the range. 2. Returning a range: if you want to go back to a range, you need to convert the resulting array back to a range, which involves min and maxing the array and handling nil edge cases. 3. Infinite ranges: Now that there are endless and beginless ranges added in ruby 2.6 and 2.7 respectively, you can not convert an infinite range to an array and therefore can't do an intersection without more complex logic. I think the added infinite range support makes it a good reason to add range intersections since that is a feature you can't accomplish with just an array. It looks like there was an [Array#intersection alias](https://bugs.ruby-lang.org/issues/16155) added for Array#& recently. I would propose Range#& and Range#intersection to have parity with Array and Set methods. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125920] [Ruby Feature#22175] Add `Range#clamp`
by nobu (Nobuyoshi Nakada) 10 Jul '26

10 Jul '26

Issue #22175 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22175: Add `Range#clamp` https://bugs.ruby-lang.org/issues/22175 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I would like to propose `Range#clamp`, which returns a new `Range` whose begin and end values are clamped to the given bounds. Proposed call-seq: ```ruby range.clamp(min, max) -> range range.clamp(bounds) -> range ``` This is a range counterpart of `Comparable#clamp`. While `Comparable#clamp` clamps a single value, `Range#clamp` clamps both endpoints of a range. Examples: ```ruby (1..10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 10) #=> 3...10 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(3..7) #=> 3..7 (1..10).clamp(3...7) #=> 3...7 (1..5).clamp(3...7) #=> 3..5 ``` `clamp(min, max)` behaves like clamping by an inclusive range `min..max`. If an exclusive upper bound is needed, a range argument can be used: ```ruby (1..10).clamp(3...7) #=> 3...7 ``` Beginless and endless ranges are also supported: ```ruby (..10).clamp(3, 7) #=> 3..7 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(..7) #=> 1..7 (1..10).clamp(...7) #=> 1...7 (1..10).clamp(3..) #=> 3..10 ``` If the receiver is entirely outside the clamping bounds, the returned range is empty: ```ruby (1..10).clamp(20..30) #=> 20...20 (1..10).clamp(-10..0) #=> 0...0 (1..).clamp(..0) #=> 0...0 ``` The returned range excludes its end when the returned end value is an excluded end value of either the receiver or the argument range: ```ruby (1...10).clamp(3, 10) #=> 3...10 (1..10).clamp(3...10) #=> 3...10 ``` Otherwise, the returned range includes its end. #### Relation to [Feature #16757] [Feature #16757] proposes `Range#intersection` / `Range#&` as a general operation for intersecting two ranges. `Range#clamp` is closely related, but intentionally narrower. It treats the argument as clamping bounds for the receiver, similar to how `Comparable#clamp` treats its arguments as bounds for one value. For overlapping ranges, `range.clamp(bounds)` often produces the same result as a range intersection. For example: ```ruby (1..10).clamp(3..7) #=> 3..7 ``` However, `clamp` has a bounds-oriented API and naturally supports the two-argument form: ```ruby (1..10).clamp(3, 7) #=> 3..7 ``` Also, when the receiver is outside the bounds, `clamp` returns an empty `Range` at the nearest bound, rather than needing to decide whether a general intersection operation should return `nil`, `[]`, an empty range, or raise: ```ruby (1..10).clamp(20..30) #=> 20...20 ``` So this proposal can be considered either independently, as a range counterpart of `Comparable#clamp`, or as a smaller operation that could coexist with a future `Range#intersection`. #### Motivation It is common to restrict ranges to known boundaries, for example when limiting source locations, pagination windows, numeric domains, date/time windows, or user-provided ranges. Currently this has to be written manually by clamping both endpoints and reconstructing the range while preserving the correct excluded-end behavior. That logic is easy to get subtly wrong, especially with exclusive ranges, beginless/endless ranges, and ranges that become empty after clamping. `Range#clamp` would provide a small, direct API for this operation. #### Notes The method returns a new `Range` instance. The single-argument form accepts a range-like object accepted by Ruby’s range conversion logic. Source checked: [[Feature #16757]: Add intersection to Range](https://bugs.ruby-lang.org/issues/16757). -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125953] [Ruby Feature#22185] Add alignment directives to `Array#pack` and `String#unpack`
by nobu (Nobuyoshi Nakada) 10 Jul '26

10 Jul '26

Issue #22185 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22185: Add alignment directives to `Array#pack` and `String#unpack` https://bugs.ruby-lang.org/issues/22185 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- `Array#pack` and `String#unpack` can express byte skips and absolute positions with `x`, `X`, and `@`, but they do not currently have a direct way to align the current position to a byte boundary or to the ABI alignment of another directive. This makes it awkward to describe binary formats that follow C-like structure layout rules. Users need to calculate padding manually, and the required padding can depend on the platform ABI. I propose adding alignment forms to pack templates. ### Alignment Directive ```ruby [1, 2].pack("C x!4 C") # => "\x01\x00\x00\x00\x02" ``` `x!N` advances to the next `N`-byte boundary, filling with NUL bytes when packing and skipping bytes when unpacking. The alignment can also be specified by another directive: ```ruby [1, 2].pack("C x!i i") ``` Here `x!i` aligns to the native alignment of the `i` directive. This lets templates describe platform-dependent native layouts without spelling out the padding size. ### Alignment Mode For formats that need repeated C-structure-style alignment, add an alignment mode: ```ruby [1, 2].pack("!{C i}") ``` This is equivalent to inserting the necessary alignment before each numeric or pointer directive, for example: ```ruby [1, 2].pack("C x!i i") ``` The alignment mode is intentionally not nested. ### Relative and Absolute Alignment There is also a distinction between relative and absolute alignment when `buffer:` or `offset:` is used. `x!` aligns relative to the starting position of the current pack/unpack operation, while `@!` aligns relative to the beginning of the output or input string: ```ruby buffer = +"z" [1, 2].pack("C x!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x00\x02" buffer = +"z" [1, 2].pack("C @!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x02" ``` Similarly for unpacking: ```ruby "z\x01\x00\x00\x00\x02".unpack("C x!4 C", offset: 1) # => [1, 2] "z\x01\x00\x00\x02".unpack("C @!4 C", offset: 1) # => [1, 2] ``` This keeps `x!` useful for templates that describe a sub-layout starting at the given `buffer:`/`offset:` position, while `@!` covers formats whose alignment is based on the absolute position in the whole binary string. ### Caveats The directive-alignment form rejects endian modifiers, since byte order does not affect ABI alignment. For example, `x!i` is meaningful, but `x!i<` should not be accepted as an alignment specifier. The alignment is for the pack/unpack offset, not a guarantee about the native address of the underlying String buffer. Callers that need to pass the buffer to C as a typed pointer must ensure separately that the actual address is suitably aligned. Shared substrings, for example, may start at an arbitrary byte offset. ### Examples A concrete use case is building or reading binary records whose layout is shared with C code. For example, a file format, IPC message, device command buffer, or FFI payload may contain records equivalent to: ```C struct entry { uint8_t tag; uint32_t size; void *data; }; ``` Today, a Ruby template has to spell out the padding manually: ```ruby [tag, size, data].pack("C xxx L J") ``` This is both error-prone and ABI-dependent. The padding after `tag` depends on the native alignment of `uint32_t`, and the next field may depend on pointer alignment. With alignment directives, the template can express the intended layout directly: ```ruby [tag, size, data].pack("!{C L J}") ``` or, when only one boundary is needed: ```ruby [tag, size].pack("C x!L L") ``` One target use case is binary buffers that contain several C-like record types. For example, an IPC or device buffer may store a sequence of records, each with its own layout. It is natural to pack or unpack each record with a separate template at a given `buffer:` or `offset:` position. In that case `x!` is useful for alignment relative to the start of the current record, while `@!` is useful for formats whose alignment is defined relative to the start of the whole buffer. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125756] [Ruby Bug#22112] Backport for IO::Buffer USF issues
by nagachika (Tomoyuki Chikanaga) 09 Jul '26

09 Jul '26

Issue #22112 has been reported by nagachika (Tomoyuki Chikanaga). ---------------------------------------- Bug #22112: Backport for IO::Buffer USF issues https://bugs.ruby-lang.org/issues/22112 * Author: nagachika (Tomoyuki Chikanaga) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following commits are a series of fixes for IO::Buffer use-after-free issues across multiple methods. Please backport them to the stable branches. - commit:2552db04ddc44349c7b0f5f93aeb0fb02eccb509 (Fix UAF in IO::Buffer#&) - commit:95626e3a9c59cd073221c08ed013ed0f2d655b6f (Fix UAF in IO::Buffer#|) - commit:90ed85f91ed8c9df26efcbdc5e6a1b428be3ef06 (Fix UAF in IO::Buffer#^) - commit:3373fcc2dee7c4560d2c3e4280c549cdb1b5de63 (Fix UAF in IO::Buffer#~) - commit:4bd3e14fc2623414680008c7b1d38f1a3df2877e (Fix UAF in IO::Buffer#and!, IO::Buffer#or!, IO::Buffer#xor!) - commit:2c8002d58302e4fff51484826e1fd706cc2bfb19 (Validate the buffer after argument conversion) - commit:773e0c3a0f2ab2bd235c8d44cad1f999bfe2514b (Validate the buffer after type argument conversion) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125590] [Ruby Bug#22086] Backport Marshal overflow fix
by nobu (Nobuyoshi Nakada) 09 Jul '26

09 Jul '26

Issue #22086 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22086: Backport Marshal overflow fix https://bugs.ruby-lang.org/issues/22086 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- GH-17130 * commit:8ed456afc95ccb23256fe10036cd0d9678ceb245 Marshal.load: Fix buffer overflow at overread * commit:2510dfee2a6aba9e99664b453e2be69e00eb21a6 Marshal.load: Fix integer overflow of length * commit:3f6d6c0373d2cb005f7cf164414cbb531f42d525 Marshal.load: Check bignum sign -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125934] [Ruby Bug#22181] SEGV in branch peephole optimization due to label/insn struct aliasing
by viralpraxis (Iaroslav Kurbatov) 09 Jul '26

09 Jul '26

Issue #22181 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22181: SEGV in branch peephole optimization due to label/insn struct aliasing https://bugs.ruby-lang.org/issues/22181 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-05T09:21:26Z master fd34f67b18) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Both `iseq_label_data` and `iseq_insn_data` share the same layout prefix; in some cases `iseq_label_data->label_no` might collide with `iseq_insn_data->insn_id` (e.g. when there are many (monotonically increasing) label IDs allocated and one of them collides with `branchif := 74`). An example (generated so that the collision actually happens): ```ruby cat test.rb $g&.call&.to_s [*d, [__dir__].each(&:each), C1.value(/ab/o, &b)].each {} begin ((-243 != qux) ? (1..2) : 8i&.value) => ^([1].select(&:to_s)) rescue ((-243 != qux) ? (1..2) : 8i&.value) => ^([1].select(&:to_s)) end ``` ```shell ~/.rubies/ruby-master/bin/ruby test.rb test.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.1.0dev (2026-07-05T09:21:26Z master fd34f67b18) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:0026c0 l:y b:---- r:(nil) DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00005835a2c62129 RBP: 0x00005835de29bce0 RSP: 0x00007ffc8774f2e0 RAX: 0x00005835de3254d8 RBX: 0x000000000000004b RCX: 0x0000000000000001 RDX: 0x00005835de29bca0 RDI: 0x00005835de29b880 RSI: 0x0000000000000000 R8: 0x00005835de29b880 R9: 0x00005835a2de1501 R10: 0x0000000000000002 R11: 0x0000000000000000 R12: 0x0000000000000000 R13: 0x00005835a2e325f4 R14: 0x000071196d162b80 R15: 0x0000000000000001 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- ~/.rubies/ruby-master/bin/ruby(rb_print_backtrace+0x14) [0x5835a29e1a33] $RSRC/ruby/vm_dump.c:1111 ~/.rubies/ruby-master/bin/ruby(rb_vm_bugreport) $RSRC/ruby/vm_dump.c:1473 ~/.rubies/ruby-master/bin/ruby(rb_bug_for_fatal_signal+0x101) [0x5835a2cf1221] $RSRC/ruby/error.c:1140 ~/.rubies/ruby-master/bin/ruby(sigsegv+0x48) [0x5835a2911848] $RSRC/ruby/signal.c:948 /lib/x86_64-linux-gnu/libc.so.6(0x711988645330) [0x711988645330] ~/.rubies/ruby-master/bin/ruby(replace_destination+0x3) [0x5835a2c62129] $RSRC/ruby/compile.c:3127 ~/.rubies/ruby-master/bin/ruby(iseq_peephole_optimize) $RSRC/ruby/compile.c:3720 ~/.rubies/ruby-master/bin/ruby(iseq_optimize+0x1cb) [0x5835a2c63f83] $RSRC/ruby/compile.c:4495 ~/.rubies/ruby-master/bin/ruby(iseq_setup_insn) $RSRC/ruby/compile.c:1622 ~/.rubies/ruby-master/bin/ruby(iseq_setup_insn) $RSRC/ruby/compile.c:1611 ~/.rubies/ruby-master/bin/ruby(pm_iseq_compile_node+0x60) [0x5835a2cb1920] $RSRC/ruby/prism_compile.c:10623 ~/.rubies/ruby-master/bin/ruby(pm_iseq_build+0x184) [0x5835a2848d94] $RSRC/ruby/iseq.c:1133 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_with_opt_try+0x34) [0x5835a2848f14] $RSRC/ruby/iseq.c:1153 ~/.rubies/ruby-master/bin/ruby(rb_protect+0xfb) [0x5835a27d04db] $RSRC/ruby/eval.c:1135 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_with_opt+0x4d) [0x5835a28478f3] $RSRC/ruby/iseq.c:1181 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_main) $RSRC/ruby/iseq.c:1005 ~/.rubies/ruby-master/bin/ruby(process_options+0x1475) [0x5835a2902715] $RSRC/ruby/ruby.c:2700 ~/.rubies/ruby-master/bin/ruby(ruby_process_options+0x15d) [0x5835a290342d] $RSRC/ruby/ruby.c:3258 ~/.rubies/ruby-master/bin/ruby(ruby_options+0xc0) [0x5835a27cf1c0] $RSRC/ruby/eval.c:120 ~/.rubies/ruby-master/bin/ruby(rb_main+0x19) [0x5835a27c969e] $RSRC/ruby/jit.c:632 ~/.rubies/ruby-master/bin/ruby(main) ./main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x71198862a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x71198862a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x5835a27c96f5] ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125838] [Ruby Feature#22130] Add a new YARV instruction for a `String.new` fast path
by tenderlovemaking (Aaron Patterson) 09 Jul '26

09 Jul '26

Issue #22130 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #22130: Add a new YARV instruction for a `String.new` fast path https://bugs.ruby-lang.org/issues/22130 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- I would like to introduce a new YARV instruction, `opt_string_new`. It's similar to `opt_new`, but it is specialized for strings. Today, we [define the `new` method on `String`](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da4ab26/string.c#L12890). The reason we define the `new` method on `String` is because people can call `new` with a capacity like this: ```ruby s = String.new(capacity: 1234) ``` We want to pass the capacity to the GC so that we can ask the GC to possibly allocate a "right sized" object that includes the underlying string buffer. If we didn't implement `new`, then we would be forced to allocate a regular 40 byte slot _as well as_ a `malloc` buffer for the string. There are a few downsides to the current implementation. First, users can subclass `String` and expect the signature they define on `initialize` be the same signature that is expected for `new`. For example ```ruby class CoolString < String def initialize(is_cool:) @is_cool = is_cool super(encoding: "UTF-8") end end CoolString.new(is_cool: true) ``` In order to handle this, the `new` implementation on `String` [must check that the receiver is String, and if not, it forwards the call](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da…. The user can call `super` from `initialize`, and they expect the string to be setup in the normal fashion (setting the encoding, etc). That means that the implementation of `rb_str_s_new` is very similar to `rb_str_init` (we have a lot of duplicated code). The other down side is that since `new` can accept keyword arguments, we end up with an extra hash allocation when calling the C method. I would like to propose adding an `opt_string_new` instruction that does the "right sized allocation" and then calls `initialize` on the instance. For example, when we compile code like `String.new(capacity: 123)`, we can know where "capacity" will be stored on the stack at compile time. Since we have the capacity, we can emit an `opt_string_new` instruction that allocates the string and then delegates to `initialize` (which we'll rewrite in Ruby). To make this more concrete, here are the iseqs today: ``` ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG>, 13 0009 opt_send_without_block <calldata!mid:initialize, argc:1, kw:[#<Symbol:0x000000000086110c>], FCALL|KWARG> 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG> 0015 swap 0016 pop 0017 leave ``` Here is what I'm proposing: ``` > ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_string_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG>, 13, 0 0010 pop 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG> 0015 swap 0016 pop 0017 leave ``` I've made a WIP pull request here: https://github.com/ruby/ruby/pull/17482 Here are a few benchmark results comparing against Ruby's master branch. Interpreter + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new: 19.811M i/s (± 0.6%, GC 6.3%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new: 44.473M i/s (± 0.9%, GC 14.4%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 2.24 ± 0.02 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(capacity: 123): 10.179M i/s (± 1.1%, GC 17.7%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(capacity: 123): 35.924M i/s (± 0.4%, GC 20.2%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.53 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 8.282M i/s (± 2.5%, GC 12.0%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 7.770M i/s (± 1.6%, GC 2.7%) Summary ruby /Users/aaron/.rubies/arm64/master/bin/ruby ran 1.07 ± 0.03 times faster than ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ``` The first two cases easily win with this patch. Passing only an encoding may be slightly slower, but they are very close (and the allocations are decreased). Here are the same benchmarks but with YJIT enabled: YJIT + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new: 31.008M i/s (± 0.8%, GC 9.8%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new: 97.603M i/s (± 0.8%, GC 30.9%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.15 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 12.986M i/s (± 1.3%, GC 22.2%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 77.827M i/s (± 0.4%, GC 42.0%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 5.99 ± 0.08 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 9.909M i/s (± 0.5%, GC 13.9%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 11.916M i/s (± 0.7%, GC 3.8%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 1.20 ± 0.01 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` The first two benchmarks are much faster than the master branch, and the last benchmark is faster because I moved `initialize` to Ruby. I've implemented this in ZJIT too, but I'm not going to post the numbers because they are very similar to YJIT for this micro benchmark. -- https://bugs.ruby-lang.org/

6 13

[ruby-core:124833] [Ruby Bug#21882] IO::Buffer#locked leaves the buffer locked when the block raises
by hanazuki (Kasumi Hanazuki) 09 Jul '26

09 Jul '26

Issue #21882 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21882: IO::Buffer#locked leaves the buffer locked when the block raises https://bugs.ruby-lang.org/issues/21882 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `IO::Buffer#locked` should unlock the buffer even after the block raises an exception. ```ruby buf = IO::Buffer.new(100) buf.locked { fail } rescue nil buf.locked { p :ok } # expected to print :ok, but actually raises a LockedError ``` -- https://bugs.ruby-lang.org/

5 6

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

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

3 2

[ruby-core:125931] [Ruby Bug#22179] Coverage: redefined methods silently disappear from method Coverage.result after GC
by sferik (Erik Berlin) 09 Jul '26

09 Jul '26

Issue #22179 has been reported by sferik (Erik Berlin). ---------------------------------------- Bug #22179: Coverage: redefined methods silently disappear from method Coverage.result after GC https://bugs.ruby-lang.org/issues/22179 * Author: sferik (Erik Berlin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When method coverage is enabled, a method that has been redefined vanishes from `Coverage.result` once GC runs. It is not reported as uncovered (count 0), it is missing altogether, so the set of methods reported for a file changes nondeterministically depending on GC timing. ##### Reproduction target.rb: ```ruby def foo 1 end def foo 2 end foo ``` run.rb: ```ruby require "coverage" Coverage.start(methods: true) require_relative "./target" GC.start if ENV["FORCE_GC"] pp Coverage.result.find { |f, _| f.end_with?("target.rb") }.last[:methods] ``` Without GC, both definitions are reported: ``` $ ruby run.rb {[Object, :foo, 5, 0, 7, 3] => 1, [Object, :foo, 1, 0, 3, 3] => 0} ``` With a GC before `Coverage.result`, the first definition is gone: ``` $ FORCE_GC=1 ruby run.rb {[Object, :foo, 5, 0, 7, 3] => 1} ``` The explicit `GC.start` is only for determinism. In real programs any GC that happens to run between the redefinition and `Coverage.result` has the same effect, which is how this was noticed in the wild. I’ve looked into why this is happening and I believe it's because method coverage is not stored per file the way line and branch coverage are, it's reconstructed at result time by walking the heap for method entries (`method_coverage_i` via `rb_objspace_each_objects` in ext/coverage/coverage.c). A shadowed definition that was never called has no entry in `me2counter` and exists only as a garbage method entry after redefinition, so once GC collects it, the heap walk cannot see it and the definition is silently forgotten. This issue was discovered when it was reported as [a bug in SimpleCov](https://github.com/simplecov-ruby/simplecov/issues/1217), of which I am a maintainer. Reproduced on 3.2.11, 3.3.11, 3.4.10, and 4.0.5. -- https://bugs.ruby-lang.org/

2 2