- ruby-core - ml.ruby-lang.org

[ruby-core:120694] [Ruby master Bug#21039] Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks
by Eregon (Benoit Daloze) 27 Aug '25

27 Aug '25

Issue #21039 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks https://bugs.ruby-lang.org/issues/21039 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby def make_counter count = 0 nil.instance_exec do [-> { count }, -> { count += 1 }] end end get, increment = make_counter reader = Thread.new { sleep 0.01 loop do p get.call sleep 0.1 end } writer = Thread.new { loop do increment.call sleep 0.1 end } ractor_thread = Thread.new { sleep 1 Ractor.make_shareable(get) } sleep 2 ``` This prints: ``` 1 2 3 4 5 6 7 8 9 10 10 10 10 10 10 10 10 10 10 10 ``` But it should print 1..20, and indeed it does when commenting out the `Ractor.make_shareable(get)`. This shows a given block/Proc instance is concurrently broken by `Ractor.make_shareable`, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment". It's expected that `Ractor.make_shareable` can `freeze` objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong values being read. I think what should happen instead is that `Ractor.make_shareable` should create a new Proc and mutate that. However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like `Ractor.make_shareable([get])`). So I think one fix would to be to only accept Procs for `Ractor.make_shareable(obj, copy: true)`. FWIW that currently doesn't allow Procs, it gives `<internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError)`. I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with `Ractor.make_shareable`. Instead it could be some new method like `isolated { ... }` or `Proc.isolated { ... }` or `Proc.snapshot_outer_variables { ... }` or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do `Ractor.make_shareable(copy: true)` on outer variables) and possibly also set `self` since that's anyway needed. That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables. Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5 Extracted from https://bugs.ruby-lang.org/issues/21033#note-14 -- https://bugs.ruby-lang.org/

7 25

[ruby-core:123086] [Ruby Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected
by yui-knk (Kaneko Yuichiro) 27 Aug '25

27 Aug '25

Issue #18878 has been updated by yui-knk (Kaneko Yuichiro). Do we also support `Foo::Bar do end` (and `Foo::Bar do end + 1`)? With `ruby 3.5.0dev (2025-08-27T03:02:56Z master 5ff7b2c582)` both parse.y and prism have same behavior for do block cases like below. ```ruby bar do end # method call Bar do end # method call bar() do end # method call Bar() do end # method call Foo::bar do end # method call # Foo::Bar do end # SyntaxError Foo::bar() do end # method call Foo::Bar() do end # method call ``` ---------------------------------------- Bug #18878: parse.y: Foo::Bar {} is inconsistently rejected https://bugs.ruby-lang.org/issues/18878#change-114398 * Author: qnighy (Masaki Hara) * Status: Assigned * Assignee: ydah (Yudai Takada) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The following source doesn't parse: ```ruby Foo::Bar {} ``` despite the following: ```ruby bar # local variable or method call Bar # constant bar() # method call Bar() # method call bar {} # method call Bar {} # method call bar() {} # method call Bar() {} # method call Foo::bar # method call Foo::Bar # constant Foo::bar() # method call Foo::Bar() # method call Foo::bar {} # method call # Foo::Bar {} # SyntaxError Foo::bar() {} # method call Foo::Bar() {} # method call ``` Especially considering `Bar {}`, this looks like a missing implementation rather than an intentional behavior. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123085] ‍ ‍
by administrator 27 Aug '25

27 Aug '25

1 0

[ruby-core:123069] [Ruby Bug#21553] Remove opt_aref_with and opt_aset_with instructions
by tenderlovemaking (Aaron Patterson) 27 Aug '25

27 Aug '25

Issue #21553 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21553: Remove opt_aref_with and opt_aset_with instructions https://bugs.ruby-lang.org/issues/21553 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, I'd like to remove the `opt_aref_with` and `opt_aset_with` instructions. I think they are fairly rare these days. Removing them will simplify the YARV compiler, the JIT compilers, and fix an issue with warnings. For background, these instructions are used with code like `foo["bar"]`, but only when the string literal isn't frozen: ``` > ./miniruby --dump=insns -e'foo["bar"]' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putself ( 1)[Li] 0001 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0003 opt_aref_with "bar", <calldata!mid:[], argc:1, ARGS_SIMPLE> 0006 leave ``` Enabling frozen string literals will use `putobject` with `opt_aref`: ``` > ./miniruby --dump=insns --enable=frozen-string-literal -e'foo["bar"]' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putself ( 1)[Li] 0001 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0003 putobject "bar" 0005 opt_aref <calldata!mid:[], argc:1, ARGS_SIMPLE>[CcCr] 0007 leave ``` The optimization avoids duping the string if the receiver happens to be a hash. I tested this with YJIT benchmarks and didn't see any impact. To be sure, I checked the lobsters benchmark to find uses of this instruction, and I found it was only used 4 times during any particular request which explained why removing the instruction didn't impact runtime performance. Also, removing these instructions fixes a bug where a "chilled string warning" won't show up. For example: ```ruby class Foo def self.[](x)= x.gsub!(/hello/, "hi") end Foo["hello world"] ``` I would expect to see a "chilled string" warning with this code, but no warning shows up. Removing these instructions makes the warning show up as expected. I sent a patch to remove the instructions here: https://github.com/ruby/ruby/pull/14336 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123076] [Ruby Feature#21554] Which `make` should be supported?
by hsbt (Hiroshi SHIBATA) 26 Aug '25

26 Aug '25

Issue #21554 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21554: Which `make` should be supported? https://bugs.ruby-lang.org/issues/21554 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- @nobu tried to support the following make for prism dependencies: * GNU make(gmake) * BSD make(bsdmake) * NetBSD make(bmake) * NMAKE But it's not complete with `bmake` now. I added `gmake` to our OpenBSD instance and use it for chkbuild failures. @jeremyevans0 Is it ok to use `gmake` on OpenBSD? And I propose defining the necessary make tools for building Ruby as `gmake`, `bsdmake`, and `NMAKE`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123080] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by zverok (Victor Shepelev) 26 Aug '25

26 Aug '25

Issue #12282 has been updated by zverok (Victor Shepelev). I'll allow myself to copy-paste my reasoning from the related ticket #14602: Just a bit of "design space" analysis: 1. I think `dig!` is unusual for core Ruby. A lot of Rubyists are used that in Rails pairs like `find_by`/`find_by!` are raising/non-raising, but I don't remember any Ruby core API using this convention 2. I don't believe the keyword argument is expressive enough. The "visual structure" of the `dig` signature includes multiple values of user data (and the list of values might be of arbitrary length), so the option at the end of arguments is a) not visible enough and b) not immediately intuitively obvious if it isn't part of user's data 3. In Hash, we already have at least two examples of using `fetch` in a sense "get the value or fail": `#[]` vs `#fetch` and `#values_at` vs `#fetch_values`. It seems like it gives enough precedent to look at the "fetch"-based naming, and it seems like `fetch_dig`, while grammatically not ideal, would be guessable enough, based on existing experience. (...) I fully agree with @duerst in #14602#note-24: > maybe we can think it as a combination of `dig` with `fetch`. Then what about `dig_fetch` or `fetch_dig`? These names don't look very natural, but it's easy to understand what they are about. First, we **already have examples of `fetch`-based naming**: not only `#fetch` itself as a variation of `#[]`, but also `#fetch_values` as a variation of `#values_at`, so there is a precedent for **recognizability** Second, I value short one-word names, so all the witty options like `#shovel` and `#retrieve` are nice, but I am afraid that when we have a variation of a known method in an API established long ago, introducing **completely new word** into Ruby would be a false move. Imagine you started to read code and met with `#retrieve` (or `#shovel`) for the first time. There is nothing that might help you to understand what it does; one verb that "a bit resembles `dig`" is not suggestive enough. Third, `deep_fetch` **is** somewhat suggestive, but the problem "it behaves like `dig`, but the name logic is nothing like `dig`" stands. Maybe if it would a pair of, IDK, `#deep_fetch` and `#deep_get` it might've been tolerable, but now is too late for that, everybody has used to `#dig`. `fetch_dig`, OTOH, is reasonably short, clearly suggests the meaning, and follows the logic of other methods existing. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114390 * 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:122969] [Ruby Feature#21545] `#try_dig`: a dig that returns early if it cannot dig deeper
by cb341 (Daniel Bengl) 26 Aug '25

26 Aug '25

Issue #21545 has been reported by cb341 (Daniel Bengl). ---------------------------------------- Feature #21545: `#try_dig`: a dig that returns early if it cannot dig deeper https://bugs.ruby-lang.org/issues/21545 * Author: cb341 (Daniel Bengl) * Status: Open ---------------------------------------- Ruby offers `dig` for traversing nested hashes and arrays. It is strict and will raise if an intermediary object does not support `dig`. In many cases we only want to attempt the lookup and return `nil` if it cannot be followed, without caring about the exact reason. **Example:** ```rb { a: "foo" }.dig(:a, :b) # TypeError: String does not have #dig method { a: "foo" }.try_dig(:a, :b) # => nil ``` This is especially useful when dealing with data from APIs or other inconsistent sources: ```rb api_response = { status: "ok" } api_response.try_dig(:status, :code) # => nil api_response = { status: { code: 200 } } api_response.try_dig(:status, :code) # => 200 ``` The name `try_dig` makes it clear that it behaves like `dig` but will never raise for structural mismatches. It complements `dig` and the proposed `dig!` ([#12282](https://bugs.ruby-lang.org/issues/12282), [#15563](https://bugs.ruby-lang.org/issues/15563)) by covering the tolerant lookup case. A possible sketch: ```rb class Object def try_dig(*path) current = self path.each do |key| return nil unless current.respond_to?(:dig) begin current = current.dig(key) rescue StandardError return nil end end current end end ``` **Advantages** - Simplifies tolerant lookups without repetitive rescue logic - Clear intent when the value is optional - Useful for working with inconsistent or partially known data structures - Complements `dig` and potential `dig!` by covering the tolerant case **Disatvantages** - May hide structural issues that should be noticed during development -- https://bugs.ruby-lang.org/

5 9

[ruby-core:123077] Your Meeting Link is Here
by Zoom lnvite 26 Aug '25

26 Aug '25

1 0

[ruby-core:123075] Bonus Payment For ruby-core@ruby-lang.org
by ruby-core＠ruby-lang.org 26 Aug '25

26 Aug '25

1 0

[ruby-core:123068] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by Eregon (Benoit Daloze) 25 Aug '25

25 Aug '25

Issue #12282 has been updated by Eregon (Benoit Daloze). Agreed `deep_fetch` is good. Also wanted to mention `dig_fetch` from https://bugs.ruby-lang.org/issues/14602#note-16, there is even [a blog post about it](https://shopify.engineering/dig-fetch-truffleruby) so I think that illustrates it's a common name for this functionality. What this issue wants is `dig` with `fetch` semantics instead of `[]` semantics, hence `dig_fetch`. `fetch_path` doesn't seem ideal to me because this method would also be used e.g. with arrays and `object.fetch_path(:foo, 2, :baz)` doesn't really sounds like a "path". Similarly, `deep_fetch` looks nice but doesn't make the relation to `dig` as clear as `dig_fetch`. It could be `obj.dig(:foo, 2, :baz, exception: true)` I guess, but that's very verbose. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114381 * 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