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

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 24 Sep '25

24 Sep '25

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

6 11

[ruby-core:123136] [Ruby Feature#21557] Ractor.shareable_proc to make sharable Proc objects, safely and flexibly
by Eregon (Benoit Daloze) 23 Sep '25

23 Sep '25

Issue #21557 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21557: Ractor.shareable_proc to make sharable Proc objects, safely and flexibly https://bugs.ruby-lang.org/issues/21557 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- Following #21039 and #21550, this is a complete proposal which does not require reading these previous proposals (since that caused some confusion). That way, it is hopefully as clear as possible. It also explains how it solves everything we discussed in the previous tickets. To use Ractor effectively, one needs to create Procs which are shareable between Ractors. Of course, such Procs must not refer to any unshareable object (otherwise the Ractor invariant is broken and segfaults follow). One key feature of blocks/Procs is to be able to capture outer variables, e.g.: ```ruby data = ... task = -> { do_work(data) } ``` Ractor shareable procs should be able to use captured variables, because this is one of the most elegant ways to pass data/input in Ruby. But there is a fundamental conflict there, reassigning captured variables cannot be honored by shareable procs, otherwise it breaks the Ractor invariant. So creating a shareable proc internally makes a shallow copy of the environment, to not break the Ractor invariant. We cannot prevent assigning local variables (i.e. raise an exception on `foo = value`), that would be way to weird. But we can raise an error when trying to create a shareable proc in an incompatible situation, that makes it safe by preventing the unsafe cases. ## Reassigning a captured variable inside the block Concretely, it seems we all already agree that this should be a `Ractor::IsolationError`: ```ruby def example a = 1 b = proc { v = a; a += 1; v } r = Ractor.shareable_proc(&b) # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned inside the block [b, r] end example.map(&:call) ``` And that's because without the error the result would be `[1, 1]` which is unexpected (it should be `[1, 2]`), `r.call` should have updated `a` to 2 but it only updated `a` in its environment copy. That basically breaks the lexical scoping of variables captured by blocks. We can check this by static analysis, in fact we already use static analysis for `Ractor.new`: `a = 0; Ractor.new { a = 2 }` which gives `can not isolate a Proc because it accesses outer variables (a). (ArgumentError)`. ## Reassigning a captured variable outside the block The second problematic case is: ```ruby # error: the code clearly assumes it can reassigns `a` but the `shareable_proc` would not respect it, i.e. `shareable_proc` would break Ruby block semantics # Also note the Ractor.shareable_proc call might be far away from the block, so one can't tell when looking at the block that it would be broken by `shareable_proc` (if no error for this case) def example a = 1 b = proc { a } Ractor.shareable_proc(&b) # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block a = 2 end ``` This is very similar (it is the symmetric case), the `shareable_proc` cannot honor the `a = 2` assignment, so it should not allow creating a `shareable_proc` in that context and should be `Ractor::IsolationError`. If you don't see the issue in that small example, let's use this example: ```ruby page_views = 0 background_jobs.schedule_every(5.seconds) { puts "#{page_views} page views so far" } threaded_webserver.on("/") do page_views += 1 "Hello" end ``` If `background_jobs` uses `Thread`, everything is fine. If it uses `Ractor`, it needs to make that `schedule_every` block shareable, and if we don't add this safety check then it will always incorrectly print `0 page views so far`. This is what I mean by breaking Ruby block semantics. In this proposal, we prevent this broken semantics situation by `Ractor::IsolationError` when trying to make that `schedule_every` block shareable. One more reason here to forbid this case is that a block that is made shareable is never executed immediately on the current Ractor, because there is no need to make it shareable for that case. And so it means the block will be executed later, by some other Ractor. And that block, if it expects to be executed later, then definitely expects to see up-to-date captured variables (as in the author of the block expects that). We would check this situation by static analysis. There are multiple ways to go about it with trade-offs between precision and implementation complexity. I think we could simplify to: disallow `Ractor.shareable_proc` for any block which captures a variable which is potentially reassigned. In other words, only allow `Ractor.shareable_proc` if all the variables it captures are assigned (exactly) once. More on that later in section `Edge Cases`. ## Ractor.new Note that everything about `Ractor.shareable_proc` should also apply to `Ractor.new`, that way it's convenient to pass data via captured variables for `Ractor.new` too, example: ```ruby x = ... y = ... Ractor.new { compute(x, y) } ``` Currently `Ractor.new` does not allow capturing outer variables at all and needs workarounds such as: ```ruby x = ... y = ... Ractor.new(x, y) { |x, y| compute(x, y) } ``` ## define_method `define_method` (and of course `define_singleton_method` too) have been an issue since the beginning of Ractors, because methods defined by `define_method` just couldn't be called from a Ractor (because the block/Proc wouldn't be shareable and so can't be called from other Ractors). A workaround is to make the block/Proc shareable, but this is inconvenient, verbose and shouldn't be necessary: ```ruby def new_ostruct_member!(name) # :nodoc: unless @table.key?(name) || is_method_protected!(name) if defined?(::Ractor) getter_proc = nil.instance_eval{ Proc.new { @table[name] } } setter_proc = nil.instance_eval{ Proc.new {|x| @table[name] = x} } ::Ractor.make_shareable(getter_proc) ::Ractor.make_shareable(setter_proc) else getter_proc = Proc.new { @table[name] } setter_proc = Proc.new {|x| @table[name] = x} end define_singleton_method!(name, &getter_proc) define_singleton_method!("#{name}=", &setter_proc) end end ``` Instead, this proposal brings the idea for `define_method` to automatically call `Ractor.shareable_proc` on the given block/Proc (and fallback to the original Proc if it would raise), as if it was defined like: ```ruby def define_method(name, &body) body = Ractor.shareable_proc(self: nil, body) rescue body Primitive.define_method(name, &body) end ``` (note that `define_method` knows the `body` Proc's `self` won't be the original `self` anyway, so it's fine to change it to `nil`) This way workarounds like above are no longer needed and the code can be as simple as it used to be: ```ruby def new_ostruct_member!(name) # :nodoc: unless @table.key?(name) || is_method_protected!(name) define_singleton_method!(name) { @table[name] } define_singleton_method!("#{name}=") { |x| @table[name] = x } end end ``` Much nicer, and solves a longstanding issue with Ractor. There should be no compatibility issue since the block is only made shareable when it's safe to do so. This is another argument for making `Ractor.shareable_proc` safe. ## Ractor.shareable_proc and Ractor.shareable_lambda I believe we don't need `Ractor.shareable_lambda` (mentioned in other tickets). `Ractor.shareable_proc` should always preserve the lambda-ness (`Proc#lambda?`) of the given Proc. The role of `Ractor.shareable_proc` is to make the Proc shareable, not change arguments handling. If one wants a shareable lambda they can just use `Ractor.shareable_proc(&-> { ... })`. BTW, the added value of `Ractor.shareable_proc(self: nil, &proc)` vs just `Ractor.make_shareable(proc, copy: true)` is that it enables changing the receiver of the Proc without needing `nil.instance_eval { ... }` around, and it is much clearer. `Ractor.make_shareable(proc)` should be an error [as mentioned here](https://bugs.ruby-lang.org/issues/21039#note-14), because it would mutate the proc inplace and that's too surprising and unsafe (e.g. it would break `Proc#binding` on that Proc instance). `Ractor.make_shareable(proc, copy: true)` can be the same as `Ractor.shareable_proc(self: self, &proc)` (only works if `self` is shareable then), or an error. ## Edge Cases For these examples I'll use `enqueue`, which defines a block to execute later, either in a Thread or Ractor. For the Ractor case, `enqueue` would make the block shareable and send it to a Ractor to execute it. This is a bit more realistic than using plain `Ractor.shareable_proc` instead of `enqueue`, since it makes it clearer the block won't be executed right away on the main Ractor but later on some other Ractor. ### Nested Block Cases If the assignment is in a nested block, it's an error (this case is already detected for `Ractor.new` BTW): ```ruby a = 1 enqueue { proc { a = 1 } } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned inside the block ``` Similarly, if the assignment is in an some block outside, it's the same as if it was assigned directly outside: ```ruby a = 1 p = proc { a = 2 } enqueue { a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block ``` ### Loop Cases This would be a `Ractor::IsolationError`, because `a` is reassigned. It would read a stale value and silently ignore reassignments if there was no `Ractor::IsolationError`. ```ruby a = 0 while condition enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block a += 1 end ``` This is the same case, using a rescue-retry loop: ```ruby begin enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside a += 1 raise rescue retry if condition end ``` A `for` loop is like a while `loop` because the LHS variable (`a`) and all variables in the loop body are actually declared outside (weird, but that's how it is). ```ruby for a in enum b = rand enqueue { p a } # Ractor::IsolationError: cannot isolate a block because it accesses outer variables (a) which are reassigned outside the block end binding.local_variables # => [:a, :b] ``` Any assignment inside one of these loops can potentially happen multiple times, so any variable assigned inside one of these loops cannot be captured by a shareable block (i.e., `Ractor::IsolationError` when trying to make a shareable block in such a case). We will need the static analysis to detect such loops. That probably doesn't need a full Control Flow Graph, we just need to determine if an assignment is "inside a while/for/retry" loop (up to a scope barrier like `def`/`class`/`module`). Regular "loops" using blocks are fine though, because they create a new environment/frame for each iteration. These 2 blocks will always see `[0, 1]` and `[0, 2]`, whether shareable or not: ```ruby a = 0 [1, 2].each do |e| enqueue { p [a, e] } # OK, each of these variables is assigned only once end ``` ### eval and binding Static analysis cannot detect `eval` or `binding`. In such an extreme and very rare case the fact that `shareable_proc` makes a copy of the environment is visible: ```ruby a = 1 b = proc { a } s = Ractor.shareable_proc(&b) eval("a = 2") # or binding.local_variable_set(:a, 2), or b.binding.local_variable_set(:a, 2) b.call # => 2 s.call # => 1 ``` This seems unavoidable, unless we prevent shareable procs to use captured variables at all (quite restrictive). BTW, `Proc#binding` is already not supported for a `shareable_proc`: ``` $ ruby -e 'nil.instance_exec { a = 1; b = proc { a }; b2 = Ractor.make_shareable(b); p b2.binding }' -e:1:in `binding': Can't create Binding from isolated Proc (ArgumentError) ``` So `binding`/`eval` is in general already not fully respected with Ractor anyway (and cannot be). ### Multiple Assignments Before This simple example assigns `a` twice. It would be safe because `a` is always assigned before (in execution, not necessarily in source order) creating the block instance/Proc instance, but it is not so easy to detect. Depending on how precise the static analysis is it might allow this case. We can always allow more and start with something simple. ```ruby a = 1 a = 2 Ractor.shareable_proc { a } # Ractor::IsolationError if using the single-assignment-only static analysis, seems OK because not so common ``` ### Error Message Differentiating `... which are reassigned inside/outside the block` might be needlessly complicated, in such a case I think it's fine to simplify the error message and omit the part after `... which are reassigned`. The important part is that the outer variable is reassigned, not whether it's inside or outside. ## Alternatives ### Relaxing the checks for literal blocks `Kernel#lambda` for example has behavior which depends on whether it's given a literal block or not: ```ruby lambda(&proc {}) # => the lambda method requires a literal block (ArgumentError) ``` We could have such a difference, but I don't think it's very useful, if a variable is reassigned, it seems a bad idea to capture and shallow-copy with a shareable proc (unclear, unsafe, etc). The semantics are also simpler if they are the same whether the block is literal or not. ### Removing the checks for reassigning a captured variable outside the block That's basically option 1 of #21550. This would allow known unsafe behavior and break the examples shown above (i.e. it would break code in a nasty way: some assignments are silently ignored, good luck to debug that). It would be hard to then forbid such cases later as it could then be considered incompatible. In my opinion we would commit a big language design mistake if we just give up and allow known unsafe cases like that, people wouldn't be able to trust that local variable assignments are respected (pretty fundamental, isn't it?) and that Ruby blocks behave as they always have been (with lexical scoping for local variables). It would also do nothing to help with `define_method`. `Ractor.shareable_proc(Proc)` is currently unsafe (the main point of #21039), let's address it, not ignore known problems, especially after a lot of discussion and thoughts on how to solve it properly. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122274] [Ruby Bug#21370] `it` can cause ISeq serialization failure
by byroot (Jean Boussier) 16 Sep '25

16 Sep '25

Issue #21370 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21370: `it` can cause ISeq serialization failure https://bugs.ruby-lang.org/issues/21370 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Originally reported at: https://github.com/rails/rails/issues/55108 ```ruby iseq = RubyVM::InstructionSequence.compile(<<~'RUBY') [1].each do rescue => e puts it end RUBY iseq.to_binary # CRASH ``` ``` miniruby(sigsegv) (null):0 miniruby(RB_FL_ANY_RAW+0x20) [0x1010ac504] internal/fl_type.h:507 miniruby(rbimpl_rstring_getmem+0x20) [0x101090674] internal/core/rstring.h:393 miniruby(rb_str_cmp+0x4c) [0x10109920c] string.c:4541 miniruby(outer_variable_cmp+0x3c) [0x100e43b64] compile.c:13381 miniruby(cmp_bsd_qsort+0x3c) [0x1010fe810] util.c:239 miniruby(ruby_qsort+0x5c) [0x1010fe7a8] util.c:248 miniruby(ibf_dump_outer_variables+0x150) [0x100e43708] compile.c:13402 miniruby(ibf_dump_iseq_each+0x19c) [0x100e423cc] compile.c:13527 miniruby(ibf_dump_iseq_list_i+0x38) [0x100e420fc] compile.c:13862 miniruby(apply_functor+0x40) [0x10107bad8] st.c:1644 ``` It is crashing while trying to sort outer variables, and `it` is anonymous. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:121865] [Ruby Bug#21313] `it` in rescue/ensure on prism
by ko1 (Koichi Sasada) 16 Sep '25

16 Sep '25

Issue #21313 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #21313: `it` in rescue/ensure on prism https://bugs.ruby-lang.org/issues/21313 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: prism * ruby -v: "ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [wasm32-wasi]" * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby 1.times do raise rescue p it #=> prism: false #=> parse.y: 0 end ``` `it` should return 0, shouldn't it? demo: parse.y: https://ruby.github.io/play-ruby/?code=p+RUBY_DESCRIPTION%0A%0A1.times+do%0… prism: https://ruby.github.io/play-ruby/?code=p+RUBY_DESCRIPTION%0A%0A1.times+do%0… Same on `ensure`. ```ruby 1.times do raise ensure p it #=> prism: false #=> parse.y: 0 end ``` ```ruby 1.times do begin raise ensure p it #=> prism: false #=> parse.y: 0 end end ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123113] [Ruby Feature#21555] Add support for predicate attribute reader names
by shan (Shannon Skipper) 16 Sep '25

16 Sep '25

Issue #21555 has been reported by shan (Shannon Skipper). ---------------------------------------- Feature #21555: Add support for predicate attribute reader names https://bugs.ruby-lang.org/issues/21555 * Author: shan (Shannon Skipper) * Status: Open ---------------------------------------- After manually aliasing predicate methods many times, I wanted to propose letting `attr_reader` take predicate method names that correspond to instance variables of the base name without a trailing question mark. https://github.com/ruby/ruby/pull/14391 If the base name method doesn't already exist, a predicate name defines a base name method attribute reader to alias then undefines the base name. For example, this creates an `enabled?` method that reads `@enabled`: ```ruby attr_reader :enabled? ``` This feature is only supported for `attr_reader` and `attr`, not `attr_writer` or `attr_accessor`, since setter methods cannot have question marks. Example: ```ruby class Example attr_reader :valid?, :meaning def initialize @valid = [true, false].sample @meaning = 42 end end Example.new.valid? #=> true ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122086] [Ruby Bug#21337] Using `not` on the RHS of a logical operator becomes valid syntax with Prism
by koic (Koichi ITO) 15 Sep '25

15 Sep '25

Issue #21337 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #21337: Using `not` on the RHS of a logical operator becomes valid syntax with Prism https://bugs.ruby-lang.org/issues/21337 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following syntax behavior differs between Ruby 3.3 (parse.y by default) and Ruby 3.4 (Prism by default). ```ruby if true && not true; end ``` ## Expected In Ruby 3.3 and earlier, the following code results in a syntax error. The default parser is `parse.y`. ```console $ ruby -vce 'if true && not true; end' ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-darwin24] -e:1: syntax error, unexpected `true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) ``` The key point is that `not` is used on the right-hand side of a logical operator. ## Actual When the default parser is switched to Prism, it is accepted as valid syntax with Ruby 3.4+ (Prism by default): ```console $ ruby -vce 'if true && not true; end' ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-darwin24] Syntax OK $ ruby -vce 'if true && not true; end' ruby 3.5.0dev (2025-05-13T02:05:19Z master 9b8c846bdf) +PRISM [x86_64-darwin24] Syntax OK ``` Specifying parse.y causes a syntax error, as before 3.3 (parse.y by default): ```console $ ruby -vce 'if true && not true; end' ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-darwin24] -e:1: syntax error, unexpected `true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) $ ruby --parser=parse.y -vce 'if true && not true; end' ruby 3.5.0dev (2025-05-13T02:05:19Z master 9b8c846bdf) [x86_64-darwin24] -e:1: syntax error, unexpected 'true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) ``` The behavior seen in the parse.y producing a syntax error might be probably the expected one. Any case, it is likely that users would not expect such a discrepancy between parsers. This issue was noticed in the context of the following RuboCop issue: https://github.com/rubocop/rubocop/issues/14177 -- https://bugs.ruby-lang.org/

7 6

[ruby-core:121390] [Ruby Bug#21188] PRISM does not end reading from tty with ^D twice
by nobu (Nobuyoshi Nakada) 15 Sep '25

15 Sep '25

Issue #21188 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21188: PRISM does not end reading from tty with ^D twice https://bugs.ruby-lang.org/issues/21188 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- When reading from tty, `^D` ends the text without the newline. ```console $ cat a ``` Typing `^D` here, only "a" is sent without a newline, and `cat` echos back it. Then by typing `^D` again, an empty read that means EOF causes `cat` to exit. `ruby --parser=parse.y` behaves in this manner: ```console $ ruby --parser=parse.y p __FILE__"-" ``` Typing `^D` twice just after `__FILE__`, and `p` prints `"-"`. However prism requires `^D` thrice. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122953] [Ruby Bug#21540] prism allows `foo && return bar` when parse.y doesn't
by Earlopain (Earlopain _) 15 Sep '25

15 Sep '25

Issue #21540 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21540: prism allows `foo && return bar` when parse.y doesn't https://bugs.ruby-lang.org/issues/21540 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Code such as `foo && return bar` has been disallowed in ruby since at least Ruby 2.0. Prism allows it though: ``` $ ruby -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) +PRISM [x86_64-linux] Syntax OK $ ruby --parser=parse.y -cve "a && return foo" ruby 3.5.0dev (2025-08-08T02:57:23Z master 3ad26d0501) [x86_64-linux] -e:1: syntax error, unexpected local variable or method, expecting end-of-input a && return foo ruby: compile error (SyntaxError) ``` The code seems to behave like I'd expect it to and I wouldn't mind it being accepted but it is inconsistent. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:122972] [Ruby Bug#21546] `prefix` in ruby.pc is wrong when `--enable-load-relative`
by nobu (Nobuyoshi Nakada) 13 Sep '25

13 Sep '25

Issue #21546 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21546: `prefix` in ruby.pc is wrong when `--enable-load-relative` https://bugs.ruby-lang.org/issues/21546 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- It is relocatable and should reflect the installed location. ```console $ export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH} $ pkg-config --variable=prefix ruby-3.5 /. ``` Currently `pkg-config --define-prefix` works because it overrides the `prefix` value. ```console $ pkg-config --variable=prefix --define-prefix ruby-3.5 /opt/local ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122501] [Ruby Bug#21402] ruby2_keywords affects methods/procs with post arguments
by jeremyevans0 (Jeremy Evans) 13 Sep '25

13 Sep '25

Issue #21402 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21402: ruby2_keywords affects methods/procs with post arguments https://bugs.ruby-lang.org/issues/21402 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- I believe this is an oversight. We forgot to consider post arguments during the development of `ruby2_keywords`. I believe we should not allow `ruby2_keywords` on methods/procs with post arguments. Example: ```ruby def a(*c, **kw) [c, kw] end def b(*a, b) a(*a, b) end ruby2_keywords(:b) b({foo: 1}, bar: 1) # Currently: [[{foo: 1}], {bar: 1}] # Expected: [[{foo: 1}, {bar: 1}], {}] ``` I think the current behavior is unexpected and undesired, because instead of flagging the last element in the splat array, it flags a post argument. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/13475 -- https://bugs.ruby-lang.org/

3 3