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

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

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

4 11

[ruby-core:125754] [Ruby Bug#22111] Non-symbolic hash keys with `expr : value` syntax
by yertto (_ yertto) 11 Jul '26

11 Jul '26

Issue #22111 has been reported by yertto (_ yertto). ---------------------------------------- Bug #22111: Non-symbolic hash keys with `expr : value` syntax https://bugs.ruby-lang.org/issues/22111 * Author: yertto (_ yertto) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Non-symbolic hash keys with `expr : value` syntax Allow `expr : value` as a computed hash key. Almost 20 years in the making, the missing puzzle piece for Hash's "new" colon syntax: ```ruby h = { name: "symbol shorthand", # Ruby 1.9+ "quoted label": "symbol label", # Ruby 2.2+ (Feature #4935) value_omission: , # Ruby 3.1+ (Feature #14579) expr : "non symbol", # THIS PROPOSAL } ``` ## Motivation Ruby has several colon-based hash key syntaxes for symbolic keys, but the `=>` ("hash rocket") is still needed for non-symbolic keys. Adding `expr : value` is a backwards compatible leap forward toward allowing all-colon hashes for all key types: ```ruby ## Before -- mixed styles n = 42; { name: "Alice", role: "admin", "key-#{n}": "foo", RUBY_VERSION:, n => "bar" }.keys # => [:name, :role, :"key-42", :RUBY_VERSION, 42] ## After -- uniform colon syntax n = 42; { name: "Alice", role: "admin", "key-#{n}": "foo", RUBY_VERSION:, n : "bar" }.keys # => [:name, :role, :"key-42", :RUBY_VERSION, 42] ``` Could this be what we need to one day retire our old friend "hash rocket" from Hashes entirely? ### Completing the colon family | Example | Ruby | Feature | Key type | |---------|------|---------|----------| | `{ name: value }` | v1.9 | | Symbol | | `{ "quoted label": value }` | v2.2 | Feature #4935 | Symbol (quoted label) | | `{ value_omission: }` | v3.1 | Feature #14579 | Value omission | | `{ expr : value }` | *???* | **Feature #XXXXX** | Non-symbolic | ### Readability for computed-key-heavy code Code that builds dynamic hashes currently forces a style break midway through a literal. This is especially noticeable with computed keys, numeric keys, or variable-driven keys. ### Reducing `=>` overloading The `=>` token is now being used to serve more purposes than just the Hash literal (aka "Hash rocket") it was originally used for. - rightward assignment ``` expr => var ``` - pattern capture ``` case {name: "Alice", role: "admin"} in {name: String => name, role:} # capture the name String value into `name` p name # => "Alice" end ``` - rescue variables ``` rescue SomeExceptionClass => e ``` ``` rescue => e ``` Reducing the rocket's use in Hashes simplifies the language, especially for newcomers. ## Design ### Disambiguation A label-eligible expression (bareword identifier or quoted string) followed by `:` with **no space** is a symbol key. The same expression followed by `:` with **a space** cannot be a label, so it becomes a computed key: ```ruby { a: 1 } # => {:a=>1} symbol key, label syntax { a : 1 } # => {1=>1} variable `a`, expr-colon (space disambiguates) ``` Expressions that cannot be labels never need a space, so there is no ambiguity to resolve: ```ruby { "a": 1 } # => {:a=>1} symbol key { "a" : 1 } # => {"a"=>1} string "a" { 42: 1 } # => {42=>1} integer 42 { Math::Pi: 1 } # => {3.141592653589793 => 1} ``` Other expressions also work without a space — there is no ambiguity to resolve: ```ruby { foo(): 1 } # computed, method call result { -42: 1 } # computed, negative integer { 1 ? 10 : 20: 1 } # computed, ternary expression result (1 is truthy) ``` ## Relationship to Feature #22108 The earlier proposal [Feature #22108](https://bugs.ruby-lang.org/issues/22108) suggested `{ (expr): value }` using parenthesized expressions with a lexer-generated label token (`tLABEL_END`). I assumed there'd be too many dragons to fight with whitespace sensitivity. However, after making the code changes somehow it just worked for all the test cases I threw at it. ¯\_(ツ)_/¯ | | `(expr): value` | `expr : value` | |---|---|---| | Parser changes | Lexer + grammar | Grammar only | | New fields | `hash_nest` | None | | LALR conflicts | 0 | 0 | | Parens required? | Yes | No | | Interpolated key | `("key-#{n}"): val` | `"key-#{n}" : val` | | Integer key | `(42): val` | `42: val` | The whitespace version is strictly more general, has a simpler implementation, and requires no lexer changes. ## Edge cases ```ruby { a: 1 } # => {:a=>1} symbol key (unchanged) { a : 1 } # => {42=>1} computed key { 42: 1 } # => {42=>1} computed key { -42: 1 } # => {-42=>1} computed key { "a" : 1 } # => {"a"=>1} computed key {%"a": 1} # => {"a"=>1} percent string as computed key { (1+2): "three" } # => {3=>"three"} parenthesized expression { n : n } # => {42=>42} expression as both key and value { n : } # syntax error value omission not supported { n : 1, } # => {42=>1} trailing comma ok { 1 ? 10 : 20: 1 } # => {10=>1} ternary inner, colon outer (1 is truthy) ``` ## Implementation Two files (plus tests): - **`parse.y`**: One new production in `assoc`: `| arg_value ':' arg_value` - **`prism/prism.c`**: In `parse_assocs`, accept `PM_TOKEN_COLON` when `pm_symbol_node_label_p` returns false Zero lexer changes, zero new fields, zero LALR conflicts. PR: [#17318](https://github.com/ruby/ruby/pull/17318) ## Historical context A version of this was discussed on ruby-core in October 2007 (as part of ["General hash keys for colon notation"](https://public-inbox.org/ruby-core/E1ImQBE-00033s-IZ@x31/T/), murphy). Unfortunately it was brought up during the v1.9 feature freeze, but it looks like [Matz's invitation to discuss for v2.0](https://public-inbox.org/ruby-core/E1ImQA8-00033T-8c@x31/) didn't end up going anywhere. Since then, `"quoted label":` (Ruby 2.2, Feature #4935) and value omission (Ruby 3.1, Feature #14579) have expanded the colon family, making the computed-key gap more conspicuous. This proposal fills that gap with a minimal grammar change that requires no new lexer states. ## Open questions - Should `{ a : }` be a value omission? (Would need compile-time inference.) - Is there community appetite for eventually deprecating `=>` from hash literals? ## Future directions All colon-based key syntaxes would now be available. This opens up the possibility of eventually deprecating `=>` from Hash literals (while keeping it for rescue, pattern matching, and rightward assignment). This proposal does not require that change — it is simply the enabling step, and any deprecation timeline could be a separate discussion. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:116083] [Ruby master Feature#20163] Introduce #bit_count method on Integer
by garrison (Garrison Jensen) 10 Jul '26

10 Jul '26

Issue #20163 has been reported by garrison (Garrison Jensen). ---------------------------------------- Feature #20163: Introduce #bit_count method on Integer https://bugs.ruby-lang.org/issues/20163 * Author: garrison (Garrison Jensen) * Status: Open * Priority: Normal ---------------------------------------- This feature request is to implement a method called #bit_count on Integer that returns the number of ones in the binary representation of the absolute value of the integer. ``` n = 19 n.bit_count #=> 3 (-n).bit_count #=> 3 ``` This is often useful when you use an integer as a bitmask and want to count how many bits are set. This would be equivalent to ``` n.to_s(2).count("1") ``` However, this can be outperformed by ``` def bit_count(n) count = 0 while n > 0 n &= n - 1 # Flip the least significant 1 bit to 0 count += 1 end count end ``` I think this would be a useful addition because it would fit alongside the other bit-related methods defined on integer: `#bit_length,` `#allbits?`, `#anybits?`, `#nobits?`. Also, when working with bitmasks, a minor upgrade to performance often results in a significant improvement. Similar methods from other languages: https://docs.python.org/3/library/stdtypes.html#int.bit_count https://doc.rust-lang.org/std/primitive.i32.html#method.count_ones -- https://bugs.ruby-lang.org/

14 32

[ruby-core:125389] [Ruby Bug#22019] Set#intersect () segv if the block is called after return
by jhawthorn (John Hawthorn) 10 Jul '26

10 Jul '26

Issue #22019 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22019: Set#intersect () segv if the block is called after return https://bugs.ruby-lang.org/issues/22019 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: jhawthorn (John Hawthorn) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class C include Enumerable def each(&b) $b = b yield 1 end end Set[1, 2, 3] & C.new $b.call(1) # [BUG] Segmentation fault at 0x00007f21bfa67f60 ``` The cause is essentially the same as #5801, we're initializing an ifunc pointing to a stack-allocated struct. The solution I think is to only ever use `rb_block_call` with a GC managed object like an imemo_memo. In addition to `set_intersection_block` this likely also affects, `lazy_flat_map_i`, `nmin_i`, `enum_sum_i`, and `product_each_i` all of which are passed a stack buffer. It might also be helpful to prevent the ifunc from being called after return. Some iterators (ex. `sort_by`) will raise a runtime error when this happens, but it's done ad-hoc (and detection depends on the variable still being accessible). -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125891] [Ruby Feature#22137] Change `Symbol#to_s` to return frozen strings
by byroot (Jean Boussier) 10 Jul '26

10 Jul '26

Issue #22137 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22137: Change `Symbol#to_s` to return frozen strings https://bugs.ruby-lang.org/issues/22137 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Since Ruby 3.4 ([Feature #20350]) `Symbol#to_s` returns a chilled string, meaning mutating it emits a deprecation warning. I believe it's now time to act on this deprecation, I'd like to request that on Ruby 4.1, `Symbol#to_s` always return a frozen string. Several very large codebases include Shopify and GitHub have been running with `Symbol.alias_method(:to_s, :name)` without any compatibility issues whatsoever. Making this change would allow to progressively get rid of an annoying pattern in performance sensitive code: ```ruby arg.is_a?(Symbol) ? arg.name : arg.to_s ``` -- https://bugs.ruby-lang.org/

4 3

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

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

[ruby-core:125586] [Ruby Feature#22085] `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
by byroot (Jean Boussier) 09 Jul '26

09 Jul '26

Issue #22085 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings https://bugs.ruby-lang.org/issues/22085 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Ruby issue warnings when parsing out of range floats, e.g.: ``` $ ruby -We '1e184467440737095516160.to_s' -e:1: warning: Float 1e184467440737095516... out of range ``` This makes a lot of sense for float literals parsed by the Ruby parser. However I'm not convinced it makes sense when parsing user input or third party data: ```ruby >> '1e184467440737095516160'.to_f (irb):1: warning: Float 1e184467440737095516... out of range => Infinity >> Float('1e184467440737095516160') <internal:kernel>:196: warning: Float 1e184467440737095516... out of range => Infinity ``` As these warnings aren't really actionable in most cases. So I think `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 09 Jul '26

09 Jul '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125889] [Ruby Feature#22136] `sprintf` shouldn't raise ArgumentError when $DEBUG is set
by byroot (Jean Boussier) 09 Jul '26

09 Jul '26

Issue #22136 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22136: `sprintf` shouldn't raise ArgumentError when $DEBUG is set https://bugs.ruby-lang.org/issues/22136 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Expected behavior If I'm tracking down a problem and suspect an error might be swallowed somewhere, I do run my test case with `RUBYOPT="-d"` (or simply set `$DEBUG = true`. I do expect the program to execute all in the same way than without `-d`, expect for extra output on STDERR. ### Actual behavior If some code happens to call `sprintf` or `String#%` with too many arguments, then it will raise an error and likely break the program, preventing me from simply running the same code but in debug mode. ### Reproduction ``` $ ruby -e 'sprintf("foo", "bar"); p :ok' :ok $ ruby -We 'sprintf("foo", "bar"); p :ok' -e:1: warning: too many arguments for format string :ok $ ruby -dWe 'sprintf("foo", "bar"); p :ok' Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1423 - cannot load such file -- rubygems/defaults/operating_system Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1438 - cannot load such file -- rubygems/defaults/ruby Exception 'ArgumentError' at -e:1 - too many arguments for format string Exception 'RuntimeError' at <internal:ast>:96 - cannot get AST for ISEQ compiled by prism -e:1:in 'Kernel#sprintf': too many arguments for format string (ArgumentError) from -e:1:in '<main>' ``` ### Bug or Feature? I looked around the Ruby codebase, as far as I can tell this is the only method behaving this way (aside from its aliases like `String#%`). So I filed this as a Feature, but really in my opinion it is a bug. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 09 Jul '26

09 Jul '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

4 4