August 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: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) 14 Sep '25

14 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) 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:123122] [Ruby Feature#21556] Add true? and false? methods to NilClass, TrueClass, FalseClass, and String
by Phalado (Raphael Cordeiro) 14 Sep '25

14 Sep '25

Issue #21556 has been reported by Phalado (Raphael Cordeiro). ---------------------------------------- Feature #21556: Add true? and false? methods to NilClass, TrueClass, FalseClass, and String https://bugs.ruby-lang.org/issues/21556 * Author: Phalado (Raphael Cordeiro) * Status: Open ---------------------------------------- Sometimes we need to check for an exact `true` or `false` value. This can be a string or a boolean value. Usually, what I do to solve this is something like `value.to_s == true`, this way covering for strings, booleans, and nil values. The idea of these new methods is to check for the exact value, being it a String, a Boolean, or even a Nil value. This is the result obtained: ``` ruby # String 'true'.true? # true 'false'.true? # false ''.true? # false 'true'.false? # false 'false'.false? # true ''.false? # false # Boolean true.true? # true true.false? # false false.true? # false false.false? # true # Nil nil.true? # false nil.false? # false ``` -- https://bugs.ruby-lang.org/

4 8

[ruby-core:122899] [Ruby Bug#21528] SyntaxError#message may have broken encoding with multibyte source under Prism
by alpaca-tc (Hiroyuki Ishii) 13 Sep '25

13 Sep '25

Issue #21528 has been reported by alpaca-tc (Hiroyuki Ishii). ---------------------------------------- Bug #21528: SyntaxError#message may have broken encoding with multibyte source under Prism https://bugs.ruby-lang.org/issues/21528 * Author: alpaca-tc (Hiroyuki Ishii) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Since the introduction of Prism, when parsing Ruby source code that contains multibyte characters, SyntaxError#message can sometimes have invalid encoding. Here is a reproducible example: ``` begin RubyVM::InstructionSequence.compile(<<~CODE, nil, nil, 1) if a # 0000000000000ああああああ # CODE rescue SyntaxError => e $e = e puts e.message # string contains a multibyte character that is cut off mid-byte. \xE3 # <compiled>:3: syntax errors found # 1 | if a # > 2 | # 0000000000000あああああ\xE3 ... # | ^ expected an `end` to close the conditional clause # > 3 | # # | ^ unexpected end-of-input, assuming it is closing the parent top level context puts e.message.valid_encoding? #=> expected true, but got false end ``` This appears to be caused by a truncation process in prism's error message generating that does not consider multibyte character boundaries. See: The truncation logic around [prism_compile.c L10696-L10709](https://github.com/ruby/ruby//blob/30a20bc166bc37acd7dcb3788… I'm not sure how to correctly fix it due to lack of knowledge about safe byte truncation. I discovered this issue through irb, which attempts to display source code even when it contains syntax errors. Because irb uses `SyntaxError#message`, it raised an `ArgumentError: invalid byte sequence in UTF-8`. See: https://github.com/ruby/irb/blob/f60dfa8549f746f69e9a6d160604a7a4974ffac1/l… If this is considered an irb issue, I already have a patch for IRB that handles it. -- https://bugs.ruby-lang.org/

5 4

[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