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

[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: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:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 13 Sep '25

13 Sep '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

3 2

[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:123175] [Ruby Bug#21561] Wrong encoding for File.dirname result on Windows
by thyresias (Thierry Lambert) 12 Sep '25

12 Sep '25

Issue #21561 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #21561: Wrong encoding for File.dirname result on Windows https://bugs.ruby-lang.org/issues/21561 * Author: thyresias (Thierry Lambert) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I placed the file containing the code below in a directory named "à_signaler" to show the effect on non-ascii characters: ```ruby def dirname_encoding(file) h = { "file" => file, "File.dirname(file)" => File.dirname(file), "File.expand_path(file)" => File.expand_path(file), "File.expand_path(File.dirname(file))" => File.expand_path(File.dirname(file)), "File.dirname(File.expand_path(file))" => File.dirname(File.expand_path(file)), } puts h.each do |name, value| puts "#{name} = #{value.inspect} (#{value.encoding})" end end dirname_encoding "foo.bar" dirname_encoding "foo/bar" ``` The result: ``` file = "foo.bar" (UTF-8) File.dirname(file) = "." (US-ASCII) File.expand_path(file) = "D:/à_signaler/foo.bar" (UTF-8) File.expand_path(File.dirname(file)) = "D:/\xE0_signaler" (US-ASCII) File.dirname(File.expand_path(file)) = "D:/à_signaler" (UTF-8) file = "foo/bar" (UTF-8) File.dirname(file) = "foo" (UTF-8) File.expand_path(file) = "D:/à_signaler/foo/bar" (UTF-8) File.expand_path(File.dirname(file)) = "D:/à_signaler/foo" (UTF-8) File.dirname(File.expand_path(file)) = "D:/à_signaler/foo" (UTF-8) ``` The source problem is the encoding US-ASCII for "." This may be linked to Bug #20699. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123234] [Ruby Feature#17398] SyntaxError in endless method
by kddnewton (Kevin Newton) 12 Sep '25

12 Sep '25

Issue #17398 has been updated by kddnewton (Kevin Newton). Status changed from Closed to Open Assignee deleted (prism) This is now fixed in prism, will need a fix for parse.y. ---------------------------------------- Feature #17398: SyntaxError in endless method https://bugs.ruby-lang.org/issues/17398#change-114565 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- This works: ```ruby def foo() = puts("bar") ``` This does not: ```ruby def foo() = puts "bar" # ^ syntax error, unexpected string literal, expecting `do' or '{' or '(' ``` Is this intentional or accidental? Not sure how it is reasoned. ---Files-------------------------------- allow-command-style-endless-method-def.patch (3.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123063] [Ruby Feature#21552] allow String.strip and similar to take a parameter similar to String.delete
by MSP-Greg (Greg L) 12 Sep '25

12 Sep '25

Issue #21552 has been reported by MSP-Greg (Greg L). ---------------------------------------- Feature #21552: allow String.strip and similar to take a parameter similar to String.delete https://bugs.ruby-lang.org/issues/21552 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Regrading `String.strip` (and `lstrip`, `rstrip`, and `!` versions) Some text data representations differentiate between what one might call vertical and horizontal white space, and the 'strip' methods currently strip both. It would be helpful if they had an optional parameter similar to `String.delete` with a one multi-character selector, so one could do: ```ruby t = str.strip " \t" ``` One can use a regex for this, but this much simpler. -- https://bugs.ruby-lang.org/

2 1

[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:123224] [Ruby Bug#21571] Ruby sporadically hanging on exit
by dmorner (Daniel Orner) 11 Sep '25

11 Sep '25

Issue #21571 has been reported by dmorner (Daniel Orner). ---------------------------------------- Bug #21571: Ruby sporadically hanging on exit https://bugs.ruby-lang.org/issues/21571 * Author: dmorner (Daniel Orner) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +YJIT +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This is my first bug report, so please let me know if there's anything I can do to improve it. We have a production-grade Rails app that's been running for many years. We recently moved to EKS and upgraded it to the latest Ruby and Rails. We have a number of delayed_job processes that fork on every job that comes in so that the OS can reclaim the memory used in executing it (we implemented this a long time ago because Ruby never gives up any memory that it takes, and some jobs use way more memory than others). In the last couple of weeks, we've noticed a rare occurrence where the delayed job hangs when exiting. The code looks like this: <pre> Process.fork do ActiveRecord::Base.establish_connection execute_job end Process.wait </pre> The forked child process doesn't exit when this bug occurs, it's just stuck forever, doing nothing. Obviously I don't have a way to reproduce this because it happens maybe once every few thousand jobs, and it happens across all job types. If I run gdb on the child process, I always see something that looks like this (note: I am a total gdb newbie): <pre> #0 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fb6af41400c, expected=expected@entry=3, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>, cancel=cancel@entry=false) at ./nptl/futex-internal.c:103 #1 0x00007fb6d5677f68 in __GI___futex_abstimed_wait64 (futex_word=futex_word@entry=0x7fb6af41400c, expected=expected@entry=3, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>) at ./nptl/futex-internal.c:128 #2 0x00007fb6d568138c in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, rwlock=0x7fb6af414000) at ./nptl/pthread_rwlock_common.c:730 #3 ___pthread_rwlock_wrlock (rwlock=0x7fb6af414000) at ./nptl/pthread_rwlock_wrlock.c:26 #4 0x00007fb6aee22989 in CRYPTO_THREAD_write_lock () at /lib/x86_64-linux-gnu/libcrypto.so.3 #5 0x00007fb6aee15c6a in () at /lib/x86_64-linux-gnu/libcrypto.so.3 #6 0x00007fb6aee15fa9 in OPENSSL_thread_stop () at /lib/x86_64-linux-gnu/libcrypto.so.3 #7 0x00007fb6aee153b5 in OPENSSL_cleanup () at /lib/x86_64-linux-gnu/libcrypto.so.3 #8 0x00007fb6d563055d in __run_exit_handlers (status=0, listp=0x7fb6d57c5820 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:116 #9 0x00007fb6d563069a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:146 #10 0x00007fb6d5ad3a80 in ruby_stop (ex=<optimized out>) at eval.c:290 #11 0x00007fb6d5bc47b4 in rb_f_fork (obj=<optimized out>) at process.c:4388 #12 rb_f_fork (obj=<optimized out>) at process.c:4378 #13 0x00007fb6d5cad5cc in vm_call_cfunc_with_frame_ (stack_bottom=<optimized out>, argv=<optimized out>, argc=0, calling=<optimized out>, reg_cfp=0x7fb6d4f68280, ec=0x7fb6d4e4d550) at /usr/src/ruby/vm_insnhelper.c:3794 #14 vm_call_cfunc_with_frame (ec=0x7fb6d4e4d550, reg_cfp=0x7fb6d4f68280, calling=<optimized out>) at /usr/src/ruby/vm_insnhelper.c:3840 #15 0x00007fb6d5cb3fef in vm_sendish (ec=0x7fb6d4e4d550, reg_cfp=0x7fb6d4f68280, cd=0x7fb69fb17650, block_handler=<optimized out>, method_explorer=mexp_search_method) at /usr/src/ruby/vm_callinfo.h:415 #16 0x00007fb6d5cc1e59 in vm_exec_core (ec=0x7fb6af41400c, ec@entry=0x7fb6d4e4d550) at /usr/src/ruby/insns.def:851 #17 0x00007fb6d5cc7ba9 in rb_vm_exec (ec=0x7fb6d4e4d550) at vm.c:2595 #18 0x00007fb6b13e73b9 in () #19 0x00007fb6d4f68328 in () ...etc, I can paste more if needed </pre> I can't seem to get `call rb_backtrace()` working in gdb, it never prints anything. This seems to indicate that there's some kind of thread lock when OpenSSL is shutting down. The crazy thing is that **there is only one thread** for most of the processes I inspect. Any help would be greatly appreciated! -- https://bugs.ruby-lang.org/

2 2