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

[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:122501] [Ruby Bug#21402] ruby2_keywords affects methods/procs with post arguments
by jeremyevans0 (Jeremy Evans) 14 Sep '25

14 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

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 13 Sep '25

13 Sep '25

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

8 11

[ruby-core:122315] [Ruby Bug#21378] variable pinning does not look for method arguments
by shyouhei (Shyouhei Urabe) 13 Sep '25

13 Sep '25

Issue #21378 has been reported by shyouhei (Shyouhei Urabe). ---------------------------------------- Bug #21378: variable pinning does not look for method arguments https://bugs.ruby-lang.org/issues/21378 * Author: shyouhei (Shyouhei Urabe) * Status: Open * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-01-23T15:24:35Z origin/7ed08c4fd31.. 7ed08c4fd3) +PRISM [wasm32-wasi] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Is this intentional? ``` irb(main):001> def x?(y, z) = y in { x: ^z } <internal:kernel>:168:in 'Kernel#loop': (irb):1: syntax error found (SyntaxError) > 1 | def x?(y, z) = y in { x: ^z } | ^ z: no such local variable from eval_async:132:in '<main>' from /bundle/gems/js-2.7.1/lib/js.rb:109:in 'Kernel.eval' from /bundle/gems/js-2.7.1/lib/js.rb:109:in 'block in JS.__eval_async_rb' from /bundle/gems/js-2.7.1/lib/js.rb:120:in 'block in JS.__async' ``` -- https://bugs.ruby-lang.org/

5 4

[ruby-core:120073] [Ruby master Feature#20925] Allow boolean operators at beginning of line to continue previous line
by Dan0042 (Daniel DeLorme) 12 Sep '25

12 Sep '25

Issue #20925 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20925: Allow boolean operators at beginning of line to continue previous line https://bugs.ruby-lang.org/issues/20925 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- I would like for this to become accepted syntax: condition1 || condition2 condition1 && condition2 condition1 or condition2 condition1 and condition2 This is similar to how method chaining on the second line was added in Ruby 1.9 expr .method And it has the same advantage: when you have a multi-line expression, instead of hunting for the dot or boolean operator at the end of line1, it's right there at the beginning of line2, making the structure very obvious and readable. Please contrast: request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? && request.use_authenticated_cookie_encryption request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? && request.use_authenticated_cookie_encryption The first expression must rely on indentation to communicate the multi-line nature of the condition, and even then it's not as immediately obvious as the second expression, where we can see easily and immediately that this is a multi-line `&&` condition. This syntax is also similar to how a trailing comma is allowed in arrays and hashes (and method calls since Ruby 1.9), with the same advantage. It makes for a cleaner diff when you add an element to the array/hash/conditional. Taking the previous example, imagine we are adding the condition `&& request.use_authenticated_cookie_encryption`. Now contrast the diff between the two styles: request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && - request.encrypted_cookie_salt.present? + request.encrypted_cookie_salt.present? && + request.use_authenticated_cookie_encryption request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? + && request.use_authenticated_cookie_encryption Based on the above I would say this syntax is natural and consistent with existing Ruby syntactical elements, and would greatly improve code readability. -- https://bugs.ruby-lang.org/

7 11

[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:117618] [Ruby master Feature#20437] Could be the licensing conditions be made less ambiguous?
by vo.x (Vit Ondruch) 02 Sep '25

02 Sep '25

Issue #20437 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #20437: Could be the licensing conditions be made less ambiguous? https://bugs.ruby-lang.org/issues/20437 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- # Current state The current [COPYING](https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88… file says the following: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or the conditions below: 1. You may make and give away verbatim copies of the source form of the ... snip ... ~~~ And this is quite ambiguous. Let me show a few examples: # Ambiguous examples ## lib/net/protocol.rb https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88bef56159/… ~~~ # This program is free software. You can re-distribute and/or # modify this program under the same terms as Ruby itself, # Ruby Distribute License or GNU General Public License. ~~~ So what is the license? Is it 2-clause BSDL + Ruby + GPL? Or is is just Ruby + GPL but not 2-clause BSDL? ## Racc https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd884ebcabf/… ~~~ Racc is distributed under the same terms of ruby. (see the file COPYING). ~~~ where the [COPYING](https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd8… contains just 2-clause BSDL. Not even mentioning that Ruby used to be GPLv2 licensed: https://github.com/ruby/racc/commit/cc7fe952a6b1fc2ef43477674fa13f2d9d99e818 ## Rubygems https://github.com/rubygems/rubygems/blob/master/LICENSE.txt The license is obviously modeled after Ruby COPYING file, but if it could say "licensed under MIT or Ruby", it would be much better. ## Gettext https://github.com/ruby-gettext/gettext/blob/8d84132efd888e68fffbce41331645… The license note is so old that it is not obvious what that means and what was the intention. Did the Ruby relicensing from "GPLv2 or Ruby" to "GPLv2 or BSD" influenced this project? ## SPDX https://spdx.org/licenses/Ruby.html It quotes just the "conditions below" as a Ruby license, while referring to [Ruby license file](https://www.ruby-lang.org/en/about/license.txt) mentioning also 2-clause BSDL # Proposal To me it seems that the whole world recognizes "Ruby" license, except Ruby. Therefore I think it would be nice if Ruby project recognized the "Ruby" license. There are two possibilities I can think of: ## Refer the license by name ~~~diff $ git diff diff --git a/COPYING b/COPYING index 48e5a96de7..a2d179a8a9 100644 --- a/COPYING +++ b/COPYING @@ -1,6 +1,6 @@ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the -2-clause BSDL (see the file BSDL), or the conditions below: +2-clause BSDL (see the file BSDL), or the conditions of the Ruby license below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the ~~~ ## Extract the "conditions below" into "Ruby" license file The "conditions below" text could be extracted into separate file (e.g. "RUBY_LICENSE") and the "COPYING" file rephrased to say: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or Ruby license (see the file RUBY_LICENSE) ~~~ -- https://bugs.ruby-lang.org/

2 5

[ruby-core:122797] [Ruby Feature#21515] Add `&return` as sugar for `x=my_calculation; return x if x`
by nhorton (Noah Horton) 28 Aug '25

28 Aug '25

Issue #21515 has been reported by nhorton (Noah Horton). ---------------------------------------- Feature #21515: Add `&return` as sugar for `x=my_calculation; return x if x` https://bugs.ruby-lang.org/issues/21515 * Author: nhorton (Noah Horton) * Status: Open ---------------------------------------- Let me preface this by saying I have no marriage to the exact keyword name of `&return`. # Problem It is very common to have an early return in code where you get some initial value and return it if it is non-null. i.e. ``` return my_calculation(input_a, input_b) if my_calculation(input_a, input_b) ``` That form on its own is verbose and one where you need to look at it for a moment to confirm it is the same code on either side of the if. If `my_calculation` is non-trivial at all, it normally gets turned into something with a variable: ``` my_calc = my_calculation(input_a, input_b) return my_calc if my_calc ``` That is now two lines. The worse scenario, however, is if the user did not bother doing that and my_calculation turned out to be expensive (and they did not know it). # Proposal I propose a syntax of `&return my_calculation(input_a, input_b)` where it will evaluate the argument and return it as the result of the method if it is non-nil, otherwise it will continue on. # Alternatives ## Do Nothing There is no way to work around this with rolling your own methods. You can't make a `returnif` method or something yourself since you can't do a return in the caller's scope. ## Different Name The best other name I saw were permutations of `returnif`. The biggest issue I see is the similarity of the following two statements: ``` return if foo returnif foo ``` Those are obviously very, very different statements, but are somewhat similar. However, things like this are common, and the code is still quite distinct on those, so I think it is acceptable. Ultimately, this feels so similar to the safe navigator that using `&` in this context feels appropriate. Thank you all for your consideration. -- https://bugs.ruby-lang.org/

9 12

[ruby-core:122665] [Ruby Bug#21503] \p{Word} does not match on \p{Join_Control} while docs say it does
by procmarco (Marco Concetto Rudilosso) 27 Aug '25

27 Aug '25

Issue #21503 has been reported by procmarco (Marco Concetto Rudilosso). ---------------------------------------- Bug #21503: \p{Word} does not match on \p{Join_Control} while docs say it does https://bugs.ruby-lang.org/issues/21503 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * ruby -v: 3.4.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- in the [docs](https://ruby-doc.org/3.4.1/Regexp.html#:~:text=/%5Cp%7B-,Word,-%7D/%3… it is mentioned that `\p{Word}` matches the equivalent of: `[\p{M}\p{Nd}\p{Pc}\p{Alpha}\p{Join_Control}]` as it's also defined in the [unicode spec](https://unicode.org/reports/tr18/#word) the issue is that it does not seem to be the case ``` irb(main):018> REGEX = /\p{Word}/u => /\p{Word}/ irb(main):019> "\u200D".gsub(REGEX, "-") => "‍" irb(main):020> REGEX2 = /\p{Join_Control}/u => /\p{Join_Control}/ irb(main):021> "\u200D".gsub(REGEX2, "-") => "-" ``` There's 2 solutions here, either we change the docs or the code. -- https://bugs.ruby-lang.org/

6 7