September 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123212] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by briankung (Brian Kung) 11 Sep '25

11 Sep '25

Issue #12282 has been updated by briankung (Brian Kung). How about `dig_cons()`, similar to `each_cons()`? They'd be different in that the argument to `each_cons` is how large each output slice is, whereas the arguments to `dig_cons` would represent consecutive keys in a "path" (not the file path, of course). The similarity would be the idea of "consecutive" elements. The "consecutive" in `dig_cons()` would just refer to its inputs rather than its outputs. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114542 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123203] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123202] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123201] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123200] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123196] ‍
by voicemaiI 08 Sep '25

08 Sep '25

1 0

[ruby-core:123192] [Ruby Bug#18487] Kernel#binding behaves differently depending on implementation language of items on the stack
by alanwu (Alan Wu) 08 Sep '25

08 Sep '25

Issue #18487 has been updated by alanwu (Alan Wu). @ttilberg That's right. The backtrace has `bind_call` as the caller of `binding`, and `bind_call` is a C method, hence the exception. ---------------------------------------- Bug #18487: Kernel#binding behaves differently depending on implementation language of items on the stack https://bugs.ruby-lang.org/issues/18487#change-114523 * Author: alanwu (Alan Wu) * Status: Closed * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Recently I [discovered] that one could use `Kernel#binding` to capture the environment of a frame that is not directly below the stack frame for `Kernel#binding`. I've known that C extensions have this [privilege] for a while, but didn't realize that it was also possible using only the core library. This is a powerful primitive that allows for some funky programs: ```ruby def lookup(hash, key) hash[key] hash end p lookup( Hash.new(&( Kernel.instance_method(:send).method(:bind_call).to_proc >> ->(binding) { binding.local_variable_set(:hash, :action_at_a_distance!) } ) ), :binding ) # => :action_at_a_distance! ``` There might be ways to compose core library procs such that it's less contrived and more useful, but I couldn't figure out a way to do it. Maybe there is a way to make a "local variable set" proc that takes only a name-value pair and no block? ### What's the big deal? This behavior makes the implementation language of methods part of the API surface for `Kernel#binding`. In other words, merely changing a Ruby method to be a C method can be a breaking change for the purposes of `Kernel#binding`, even if the method behaves the same in all other observable ways. I feel that whether a method is native or not should be an implementation detail and should not impact `Kernel#binding`. This is a problem for Ruby implementations that want to implement many core methods in Ruby, because they risk breaking compatibility with CRuby. TruffleRuby has this [problem][privilege] as I alluded to earlier, and CRuby risks making unintentional breaking changes as more methods change to become Ruby methods in the core library. ### Leaking less details I think a straight forward way to fix this issue is by making it so that `Kernel#binding` only ever looks at the stack frame directly below it. If the frame below is a not a Ruby frame, it can return an empty binding. I haven't done the leg work of figuring out how hard this would be to implement in CRuby, though. This new behavior allows observing the identity of native frames, which is new. ### Does the more restrictive behavior help YJIT? Maybe. It's hard to tell without building out more optimizations that are related to local variables. YJIT currently doesn't do much in that area. If I had to guess I wouuld say the more restrictive semantics at least open up the possibility of some deoptimization strategies that are more memory efficient. ### What do you think? This is not a huge issue, but it might be nice to start thinking about for the next release. If a lot of people actually rely on the current behavior we can provide a migration plan. Since it might take years to land, I would like to solicit feedback now. [discovered]: https://github.com/ruby/ruby/commit/54c91042ed61a869d4a66fc089b21f56d165265f [privilege]: https://github.com/oracle/truffleruby/issues/2171 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123190] [Ruby Bug#18487] Kernel#binding behaves differently depending on implementation language of items on the stack
by ttilberg (Tim Tilberg) 08 Sep '25

08 Sep '25

Issue #18487 has been updated by ttilberg (Tim Tilberg). I'm upgrading a project from Ruby 3.0 to Ruby 3.4, and I think I came across an unexpected bug related to this related to using `binding` from a `SimpleDelegator` child. Can someone help me confirm and organize? Example reproduction script: ``` ruby require 'erb' require 'delegate' class Report < SimpleDelegator def title "Great report" end def to_s ERB.new("<%= title %>!").result(binding) end end puts Report.new(Object.new).to_s ``` ``` ▶ ruby --version && ruby example.rb ruby 3.0.6p216 (2023-03-30 revision 23a532679b) [arm64-darwin22] Great report! ▶ ruby --version && ruby example.rb ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin22] Great report! ▶ ruby --version && ruby example.rb ruby 3.2.4 (2024-04-23 revision af471c0e01) +YJIT [arm64-darwin23] /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `binding': Cannot create Binding object for non-Ruby caller (RuntimeError) from /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `bind_call' from /Users/ttilberg/.asdf/installs/ruby/3.2.4/lib/ruby/3.2.0/delegate.rb:89:in `method_missing' from example.rb:10:in `to_s' from example.rb:14:in `<main>' ``` And it continues the same into future versions. I arrived here by way of Zevrok's ruby references notes. https://rubyreferences.github.io/rubychanges/3.2.html#kernelbinding-raises-… -- it seemed like the most reasonable suspect. ---------------------------------------- Bug #18487: Kernel#binding behaves differently depending on implementation language of items on the stack https://bugs.ruby-lang.org/issues/18487#change-114520 * Author: alanwu (Alan Wu) * Status: Closed * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Recently I [discovered] that one could use `Kernel#binding` to capture the environment of a frame that is not directly below the stack frame for `Kernel#binding`. I've known that C extensions have this [privilege] for a while, but didn't realize that it was also possible using only the core library. This is a powerful primitive that allows for some funky programs: ```ruby def lookup(hash, key) hash[key] hash end p lookup( Hash.new(&( Kernel.instance_method(:send).method(:bind_call).to_proc >> ->(binding) { binding.local_variable_set(:hash, :action_at_a_distance!) } ) ), :binding ) # => :action_at_a_distance! ``` There might be ways to compose core library procs such that it's less contrived and more useful, but I couldn't figure out a way to do it. Maybe there is a way to make a "local variable set" proc that takes only a name-value pair and no block? ### What's the big deal? This behavior makes the implementation language of methods part of the API surface for `Kernel#binding`. In other words, merely changing a Ruby method to be a C method can be a breaking change for the purposes of `Kernel#binding`, even if the method behaves the same in all other observable ways. I feel that whether a method is native or not should be an implementation detail and should not impact `Kernel#binding`. This is a problem for Ruby implementations that want to implement many core methods in Ruby, because they risk breaking compatibility with CRuby. TruffleRuby has this [problem][privilege] as I alluded to earlier, and CRuby risks making unintentional breaking changes as more methods change to become Ruby methods in the core library. ### Leaking less details I think a straight forward way to fix this issue is by making it so that `Kernel#binding` only ever looks at the stack frame directly below it. If the frame below is a not a Ruby frame, it can return an empty binding. I haven't done the leg work of figuring out how hard this would be to implement in CRuby, though. This new behavior allows observing the identity of native frames, which is new. ### Does the more restrictive behavior help YJIT? Maybe. It's hard to tell without building out more optimizations that are related to local variables. YJIT currently doesn't do much in that area. If I had to guess I wouuld say the more restrictive semantics at least open up the possibility of some deoptimization strategies that are more memory efficient. ### What do you think? This is not a huge issue, but it might be nice to start thinking about for the next release. If a lot of people actually rely on the current behavior we can provide a migration plan. Since it might take years to land, I would like to solicit feedback now. [discovered]: https://github.com/ruby/ruby/commit/54c91042ed61a869d4a66fc089b21f56d165265f [privilege]: https://github.com/oracle/truffleruby/issues/2171 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111526] [Ruby master Bug#19288] Ractor JSON parsing significantly slower than linear parsing
by maciej.mensfeld (Maciej Mensfeld) 08 Sep '25

08 Sep '25

Issue #19288 has been reported by maciej.mensfeld (Maciej Mensfeld). ---------------------------------------- Bug #19288: Ractor JSON parsing significantly slower than linear parsing https://bugs.ruby-lang.org/issues/19288 * Author: maciej.mensfeld (Maciej Mensfeld) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- a simple benchmark: ```ruby require 'json' require 'benchmark' CONCURRENT = 5 RACTORS = true ELEMENTS = 100_000 data = CONCURRENT.times.map do ELEMENTS.times.map do { rand => rand, rand => rand, rand => rand, rand => rand }.to_json end end ractors = CONCURRENT.times.map do Ractor.new do Ractor.receive.each { JSON.parse(_1) } end end result = Benchmark.measure do if RACTORS CONCURRENT.times do |i| ractors[i].send(data[i], move: false) end ractors.each(&:take) else # Linear without any threads data.each do |piece| piece.each { JSON.parse(_1) } end end end puts result ``` Gives following results on my 8 core machine: ```shell # without ractors: 2.731748 0.003993 2.735741 ( 2.736349) # with ractors 12.580452 5.089802 17.670254 ( 5.209755) ``` I would expect Ractors not to be two times slower on the CPU intense work. -- https://bugs.ruby-lang.org/

9 23

[ruby-core:123180] [Ruby Bug#21563] Misleading error message when `to_proc` does not return a Proc in an Object used as a &block argument
by soulcutter (Bradley Schaefer) 06 Sep '25

06 Sep '25

Issue #21563 has been reported by soulcutter (Bradley Schaefer). ---------------------------------------- Bug #21563: Misleading error message when `to_proc` does not return a Proc in an Object used as a &block argument https://bugs.ruby-lang.org/issues/21563 * Author: soulcutter (Bradley Schaefer) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When a class implements `#to_proc` it should always return a Proc. Nonetheless bugs are possible, and when an implementation returns something else, and is used as a block argument to a method, you get an error that claims that the argument type is the implementing class rather than the type that was returned from `to_proc`. Reproduction ``` class SayHi def call = "hi" def to_proc = "obviously not a proc" end def callablock(&block) = block.call callablock &SayHi.new # wrong argument type SayHi (expected Proc) (TypeError) ``` In real-world code it may not be _this_ obvious that `to_proc` is returning the wrong type, and so I would expect the error would report the type of object returned by `to_proc` so that you have a more-direct path to understanding the misbehavior. In this case I would expect: wrong argument type String (expected Proc) Or maybe something more-descriptive as an error message, but I don't have a concrete suggestion for that. -- https://bugs.ruby-lang.org/

2 2