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

[ruby-core:123205] [Ruby Bug#21567] Crash when $LOADED_FEATURES is modified during require
by peterzhu2118 (Peter Zhu) 14 Sep '25

14 Sep '25

Issue #21567 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21567: Crash when $LOADED_FEATURES is modified during require https://bugs.ruby-lang.org/issues/21567 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- When we require an object that is not a string, it will attempt to convert it to a string by calling to_str on it. If we modify the $LOADED_FEATURES array while it calls to_str, Ruby can crash because it can end up inserting the string in the wrong index in the array. For example, the following script crashes: ```ruby require "tempfile" class MyString def initialize(path) @path = path end def to_str $LOADED_FEATURES.clear @path end def to_path = @path end def create_ruby_file = Tempfile.create(["test", ".rb"]).path require MyString.new(create_ruby_file) $LOADED_FEATURES.unshift(create_ruby_file) $LOADED_FEATURES << MyString.new(create_ruby_file) require create_ruby_file ``` Crash log: ``` test.rb:21: [BUG] Segmentation fault at 0x0000000000000004 ruby 3.5.0dev (2025-09-09T09:29:35Z master ce94add7fb) +PRISM [arm64-darwin24] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :require c:0002 p:0076 s:0006 e:000005 EVAL test.rb:21 [FINISH] c:0001 p:0000 s:0003 E:0001b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:21:in '<main>' test.rb:21:in 'require' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000004 x1: 0x000000000000c800 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000205 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000001 x18: 0x0000000000000000 x19: 0x0000000209dfc0b0 x20: 0x0000000209dfc018 x21: 0x000000016ee8ab58 x22: 0x0fffffff0009d71d x23: 0x0000000209dfc018 x24: 0x0000000209dfc150 x25: 0x000000016ee8acc0 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 lr: 0x0000000101244140 fp: 0x000000016ee887f0 sp: 0x000000016ee887d0 -- C level backtrace information ------------------------------------------- miniruby(rb_print_backtrace+0x24) [0x101317b08] vm_dump.c:843 miniruby(rb_print_backtrace) (null):0 miniruby(rb_vm_bugreport+0x26c) [0x101317d94] vm_dump.c:1175 miniruby(rb_bug_for_fatal_signal+0xa4) [0x10105ddac] error.c:1130 miniruby(sig_do_nothing+0x0) [0x1012278c0] signal.c:948 miniruby(sigsegv) (null):0 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19c1216a4] miniruby(rb_str_new_frozen+0x1c) [0x101244140] string.c:1495 miniruby(rb_check_realpath_internal+0x68) [0x101077804] file.c:4679 miniruby(rb_check_realpath+0x2c) [0x101077aa4] file.c:4765 miniruby(get_loaded_features_index+0x37c) [0x1010f9c94] load.c:467 miniruby(rb_feature_p+0xd0) [0x1010f8174] load.c:582 miniruby(search_required+0xac) [0x1010f6ad4] load.c:1193 miniruby(require_internal+0x274) [0x1010f7518] load.c:1424 miniruby(rb_require_string_internal+0x94) [0x1010f6830] load.c:1571 miniruby(rb_require_string+0x58) [0x1010f66e8] load.c:1557 miniruby(rb_f_require+0x1c) [0x1010f6684] load.c:1150 miniruby(ractor_safe_call_cfunc_1+0x38) [0x101306c28] vm_insnhelper.c:3696 miniruby(vm_call_cfunc_with_frame_+0x250) [0x1012f857c] vm_insnhelper.c:3873 miniruby(vm_call_cfunc_with_frame+0x6c) [0x1012f8834] vm_insnhelper.c:3919 miniruby(vm_sendish+0x1a8) [0x1012c990c] vm_insnhelper.c:6087 miniruby(vm_exec_core+0x4050) [0x1012cfb48] insns.def:900 miniruby(vm_exec_loop+0x80) [0x1012e5448] vm.c:2666 miniruby(rb_vm_exec+0x134) [0x1012c9b40] vm.c:2645 miniruby(rb_iseq_eval_main+0x34) [0x1012e5628] vm.c:2919 miniruby(rb_ec_exec_node+0xe4) [0x10106d094] eval.c:282 miniruby(ruby_run_node+0x94) [0x10106cf64] eval.c:320 miniruby(rb_main+0x40) [0x100f7499c] main.c:42 miniruby(main+0x60) [0x100f74928] main.c:62 ``` -- https://bugs.ruby-lang.org/

3 2

[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: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: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: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