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

[ruby-core:120733] [Ruby master Bug#21046] Backport: TLS fix for ARM64
by nobu (Nobuyoshi Nakada) 08 Mar '25

08 Mar '25

Issue #21046 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21046: Backport: TLS fix for ARM64 https://bugs.ruby-lang.org/issues/21046 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- commit:f7059af50a31a4d27a04ace0beadb60616f3f971 Use no-inline version `rb_current_ec` on Arm64 The TLS across .so issue seems related to Arm64, but not Darwin. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:116369] [Ruby master Feature#20202] Memoized endless method definitions
by matheusrich (Matheus Richard) 27 Feb '25

27 Feb '25

Issue #20202 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #20202: Memoized endless method definitions https://bugs.ruby-lang.org/issues/20202 * Author: matheusrich (Matheus Richard) * Status: Open * Priority: Normal ---------------------------------------- I propose introducing a shorthand for memoized endless method definitions: ```rb class Foo def bar ||= :memoized_value # It should behave like def bar = (@bar ||= :memoized_value) end ``` Not only is this shorter and (IMO) a natural follow-up for endless method definitions, but it's also a common pattern on Ruby codebases. It's very useful to decompose responsibilities into several objects: ```rb class User def notifications_enabled? = settings.notifications? def enable_notifications = (settings.notifications = true) def disable_notifications = (settings.notifications = false) private def settings = @settings ||= Settings.new(self) end class User::Settings attr_writer :notifications def initialize(user) @user = user @notifications = false end def notifications? = @notifications end u = User.new u.notifications_enabled? # => false u.enable_notifications u.notifications_enabled? # => true ``` In the example, the `settings` method could be rewritten as ```rb def settings ||= Settings.new(self) ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118682] [Ruby master Misc#20652] Memory allocation for gsub has increased from Ruby 2.7 to 3.3
by orisano (Nao Yonashiro) 24 Feb '25

24 Feb '25

Issue #20652 has been reported by orisano (Nao Yonashiro). ---------------------------------------- Misc #20652: Memory allocation for gsub has increased from Ruby 2.7 to 3.3 https://bugs.ruby-lang.org/issues/20652 * Author: orisano (Nao Yonashiro) * Status: Open ---------------------------------------- I recently upgraded from ruby 2.7.7 to 3.3.1 and noticed that the GC load increased. When I used the allocation profiler to investigate, I found that memory allocation from gsub had increased. The problem was code like this: ```ruby s = "foo " s.gsub(/ (\s+)/) { " #{' ' * Regexp.last_match(1).length}" } ``` When I compared the results of heap-profiler between 2.7.7 and 3.3.1, I found that MatchData was increasing. https://gist.github.com/orisano/98792dee260106e9b6fcb45bbabeb1e6 https://github.com/ruby/ruby/commit/abc0304cb28cb9dcc3476993bc487884c139fd11 I discovered that the cause is this commit, which stopped reusing backref to avoid race conditions. Is there a way to reuse backref while still avoiding race conditions? -- https://bugs.ruby-lang.org/

9 27

[ruby-core:120657] [Ruby master Misc#21035] Clarify or redefine Module#autoload? and Module#const_defined?
by fxn (Xavier Noria) 23 Feb '25

23 Feb '25

Issue #21035 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21035: Clarify or redefine Module#autoload? and Module#const_defined? https://bugs.ruby-lang.org/issues/21035 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The documentation for `Module#autoload?` says: > Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors. As a user, if I declare an autoload, I expect this API: ```ruby module M autoload :Foo, 'foo' constants # => [:Foo] const_defined?(:Foo) # => true autoload?(:Foo) # => 'foo' end ``` That it is indeed how it generally works. Even if the autoload path does not exist. But there is an edge case. While `constants` does include always `:Foo` as far as I can tell, the return value of `const_defined?` and `autoload?` depends on the stack of features being loaded: The autoload path is resolved and if seen to be in the stack of features being loaded, the predicates return `false` and `nil`, respectively. Do you think that is intuitive? I find that logic totally unexpected. I just defined an autoload, therefore, I think it would be natural for `autoload?` to return what I just configured. Why should `const_defined?` return nothing but `true`? And why is it not consistent with `constants`? To me, it would make more sense that in the previous example `const_defined?` returns `true`, and `autoload?` returns `foo` unconditionally (and instantly, nowadays it takes a relative long time due to the lookup). Now, if the autoload is triggered in a lookup **then** I would expect `Kernel#require` logic to apply. But not when calling some simple predicates. Please, note that the present behavior is not documented, so on paper the change would not be backwards incompatible. If, on the other side, it is preferred to keep the behavior as it is, I guess it should be documented with precision (accounting for symlinks, relative paths in `$LOAD_PATH`, etc.) -- https://bugs.ruby-lang.org/

4 27

[ruby-core:119142] [Ruby master Bug#20727] YJIT segmentation fault inside of invalidate_block_version
by jhawthorn (John Hawthorn) 18 Feb '25

18 Feb '25

Issue #20727 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20727: YJIT segmentation fault inside of invalidate_block_version https://bugs.ruby-lang.org/issues/20727 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For a while we've been seeing an occasional segfault in production inside of YJIT's invalidation code. It seems to happen most often when a invalidation on a widely used CME. ``` [BUG] Segmentation fault at 0x0000000000000014" "ruby 3.3.5 (2024-09-04 revision 4f143c3038) +YJIT [x86_64-linux]" null "-- Control frame information -----------------------------------------------" "c:0174 p:---- s:1247 e:001246 CFUNC :extend_object" "c:0173 p:---- s:1244 e:001243 CFUNC :extend" "c:0172 p:0049 s:1239 e:001238 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1467" "c:0171 p:0024 s:1233 e:001232 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1456" "c:0170 p:0055 s:1227 e:001226 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:170" "c:0169 p:0076 s:1219 e:001218 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:154" -----8<----- null "-- Threading information ---------------------------------------------------" "Total ractor count: 1" "Ruby thread count for this ractor: 19" null "-- Machine register context ------------------------------------------------" " RIP: 0x0000563c0aaccef7 RBP: 0x00007f481524f5f0 RSP: 0x00007fffe8631d70" " RAX: 0x0000000000000014 RBX: 0x0000000000000010 RCX: 0x000000000000000e" " RDX: 0x0000000002ff9bab RDI: 0x00007f4839357520 RSI: 0x0000000000000008" " R8: 0x00007f480cc0f5e0 R9: 0x0000000000000800 R10: 0x00007f48af4008c0" " R11: 0x0000000000000060 R12: 0x0000563c0ad93108 R13: 0x00007f4816abe260" " R14: 0x000000000000000e R15: 0x0000000002f9d50f EFL: 0x0000000000010206" null "-- C level backtrace information -------------------------------------------" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_print_backtrace+0x11) [0x563c0a9ff8df] vm_dump.c:820" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_vm_bugreport) vm_dump.c:1151" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x563c0abc2a1c] error.c:1065" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(sigsegv+0x4d) [0x563c0a94e02d] signal.c:926" "/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f48afba1420]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(0x563c0aaccef7) [0x563c0aaccef7]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}) yjit/src/core.rs:718" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(invalidate_block_version) yjit/src/core.rs:3237" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}+0xe6) [0x563c0aaf1586] yjit/src/invariants.rs:246" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_call<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(try<(), yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(catch_unwind<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>+0x8) [0x563c0aae2d68] /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/s> "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(with_vm_lock<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) yjit/src/cruby.rs:646" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_yjit_cme_invalidate+0x5c) [0x563c0aae6e0c] yjit/src/invariants.rs:243" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(vm_cme_invalidate+0x12) [0x563c0a9d78bd] vm_method.c:126" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_method_cache_by_id_in_class) vm_method.c:240" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_module_cache_i+0x13) [0x563c0ab2d263] class.c:1234" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_id_table_foreach+0x84) [0x563c0a9891c4] id_table.c:278" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_include_modules_at+0x16a) [0x563c0ab31a0a] class.c:1314" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(include_modules_at+0x1a) [0x563c0ab31f61] class.c:1370" -----8<----- ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120660] [Ruby master Bug#21036] Somewhat confusing behaviour between warning "block passed may be ignored", versus the responsible method triggering this warning already being faulty and can never be run successfully due to errors such as "wrong number of arguments" and/or recursive cal
by rubyFeedback (robert heiler) 18 Feb '25

18 Feb '25

Issue #21036 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Bug #21036: Somewhat confusing behaviour between warning "block passed may be ignored", versus the responsible method triggering this warning already being faulty and can never be run successfully due to errors such as "wrong number of arguments" and/or recursive cal https://bugs.ruby-lang.org/issues/21036 * Author: rubyFeedback (robert heiler) * Status: Open * ruby -v: ruby 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Today I was updating / porting some legacy code, to ruby 3.4.1. Ruby 3.4.1 changed a few things, including some warnings, which is actually quite useful in the long run, in my opinion - although right now requiring some changes, which takes time. One new warning or notification is this: warning: the block passed to 'Object#xyz' defined at bla.rb:5 may be ignored So ruby now warns the developer that a block argument may be ignored. This is new information, which is useful. However had, while it takes the brain to adjust to this slowly, I actually encountered a small situation where the ruby warning reported here is a little bit awkward. Let me show a minimal script that reproduces this issue, so you can copy / paste it quickly: #!/usr/bin/ruby -w # Encoding: UTF-8 # frozen_string_literal: true # =========================================================================== # def is_recursive_but_wrong abc = is_recursive_but_wrong(abc) { :automatic } return '' end is_recursive_but_wrong Don't worry about this example being nonsensical, I actually had two bugs in one go. :D When you run the above ruby code, from a .rb file, it will report something like this: huh.rb:6: warning: the block passed to 'Object#is_recursive_but_wrong' defined at huh.rb:5 may be ignored huh.rb:5:in 'is_recursive_but_wrong': wrong number of arguments (given 1, expected 0) (ArgumentError) from huh.rb:6:in 'Object#is_recursive_but_wrong' from huh.rb:10:in '<main>' In this aptly named file called huh.rb (capturing my surprise as filename), you can see two things: 1) the warning about the block being ignored, and 2) the wrong number of arguments given I actually accidentally copy/pasted code, and in another .rb file I had a method called "created_scrolled_window" to return a scrolled-window widget from ruby-gtk3, but I first focused on the block warning given. So the first focus I made was on the "ignored block parameter", as I tend to fix these quickly, first, due to them being fairly simple. I then realised I recursively called that method. So why do I think that behaviour is strange? Well - the to me surprising part has been that I get BOTH the warning AND the issue of a wrong number of arguments. In such a situation I would prefer the wrong number of arguments reported, but not the warning about "ignored block parameter given", as that latter is less problematic (which is ok as a warning, but it still takes my attention to it, since it is reported first). Only after the "wrong number of arguments" would I think is that warning ok, as ruby can not know whether the intent truly was to ignore the block, or whether prior to that, the method is already wrong. Interestingly when I changed the above code to this variant: #!/usr/bin/ruby -w # Encoding: UTF-8 # frozen_string_literal: true # =========================================================================== # def is_recursive_but_wrong abc = is_recursive_but_wrong(def) { :automatic } return '' end is_recursive_but_wrong Aka changing the second "abc" to "def", all not defined, I get a totally different error, which is even more confusing: huh.rb:6: warning: assigned but unused variable - abc huh.rb: --> huh.rb Unmatched keyword, missing `end' ? 5 def is_recursive_but_wrong > 6 abc = is_recursive_but_wrong(def) { :automatic } > 7 return '' 8 end huh.rb:6: syntax errors found (SyntaxError) 4 | # =========================================================================== # 5 | def is_recursive_but_wrong > 6 | ... ) { :automatic } | ^ unexpected ')', ignoring it | ^ expected a delimiter to close the parameters | ^ unexpected ')'; expected a method name | ^ expected a `=>` between the hash key and value | ^ unexpected '}'; expected a value in the hash literal 7 | return '' 8 | end 9 | > 10 | is_recursive_but_wrong | ^~~~~~~~~~~~~~~~~~~~~~ unexpected local variable or method, expecting end-of-input | ^~~~~~~~~~~~~~~~~~~~~~ unexpected local variable or method; expected a `)` to close the arguments | ^ expected an `end` to close the `def` statement | ^ unexpected end-of-input, assuming it is closing the parent top level context By the way I like the change to use a red arrows there, that is quite helpful. Now, the above error makes sense I suppose because the ruby parser has to be kept in a "flexible" state, to evaluate ruby code (the old parse versus prism), but to me all of the above is a bit confusing nonetheless. Or perhaps the priorities are different. It may be difficult for ruby and the parsers to evaluate the intent of the programmer, I get it, and people may write odd code and also odd-but-valid code, but at the least in example 1, I would reason that the "ignored block warning" should not be shown if the underlying error, within that same method, means it can never be truly evaluated. I think in such a case, perhaps say 99% of the situations, whether the block is evaluated or not, is irrelevant, because the method itself is faulty and can never be correct (in my case, both as recursive call to itself, and also wrong arguments actually). I have no good suggestion to fix this as perhaps this may be intended behaviour, but perhaps I am not the only one who may be confused about the above, so I'll report it just in case. Please feel free to close this issue at any moment in time; it may not be a bug, but I found it better to file it under "Bug" rather than issue request or misc. (Perhaps in the long run we may improve on the warnings-versus-error issue a little bit. I also don't have a good suggestion here, but I remember from issues in the past that warnings can be both helpful but also confusing or spammy to some users. Any simple but effective solution here in the long run may be useful for ruby developers in general.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120712] [Ruby master Bug#21043] Prism defined? has slight deviations from parse.y
by kddnewton (Kevin Newton) 14 Feb '25

14 Feb '25

Issue #21043 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21043: Prism defined? has slight deviations from parse.y https://bugs.ruby-lang.org/issues/21043 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED ---------------------------------------- ```ruby defined?((alias foo bar)) defined?((undef foo)) def foo(*) = defined?(foo(*)) def foo(**) = defined?(foo(**)) def foo(...) = defined?(foo(...)) def foo(&) = defined?(foo(&)) ``` and a couple others have slightly different behavior. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120628] [Ruby master Bug#21031] Incompatibility with prism and parse.y when eval'ing unnamed forwarding variables
by ksss (Yuki Kurihara) 14 Feb '25

14 Feb '25

Issue #21031 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Bug #21031: Incompatibility with prism and parse.y when eval'ing unnamed forwarding variables https://bugs.ruby-lang.org/issues/21031 * Author: ksss (Yuki Kurihara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-13T03:12:28Z master 384e6945ac) +PRISM [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Case 1 ```rb # t.rb def foo(*) eval("p(*)") end foo(1) ``` ``` $ ruby --parser=prism t.rb t.rb:4:in 'Kernel#eval': (eval at t.rb:4):1: syntax error found (SyntaxError) > 1 | p(*) | ^ unexpected `*`; no anonymous rest parameter from t.rb:4:in 'Object#foo' from t.rb:7:in '<main>' ``` ``` $ ruby --parser=parse.y t.rb 1 ``` ## Case 2 ```rb # t.rb def foo(**) eval("p(**)") end foo(a: 1) ``` ``` $ ruby --parser=prism t.rb t.rb:4:in 'Kernel#eval': (eval at t.rb:4):1: syntax error found (SyntaxError) > 1 | p(**) | ^~ unexpected `**`; no anonymous keyword rest parameter from t.rb:4:in 'Object#foo' from t.rb:7:in '<main>' ``` ``` $ ruby --parser=parse.y t.rb {a: 1} ``` ## Case 3 ```rb # t.rb def foo(&) eval("p(&)") end foo{} ``` ``` $ ruby --parser=prism t.rb t.rb:4:in 'Kernel#eval': (eval at t.rb:4):1: syntax error found (SyntaxError) > 1 | p(&) | ^ unexpected `&`; no anonymous block parameter from t.rb:4:in 'Object#foo' from t.rb:7:in '<main>' ``` ``` $ ruby --parser=parse.y t.rb ``` ## Case 4 ```rb # t.rb def foo(...) eval("p(...)") end foo(1, 2, 3) ``` ``` $ ruby --parser=prism t.rb t.rb:4:in 'Kernel#eval': (eval at t.rb:4):1: syntax error found (SyntaxError) > 1 | p(...) | ^~~ unexpected ... when the parent method is not forwarding from t.rb:4:in 'Object#foo' from t.rb:7:in '<main>' ``` ``` $ ruby --parser=parse.y t.rb 1 2 3 ``` I expect to the parse.y behavior. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:120335] [Ruby master Feature#20971] Deprecate `rb_path_check`
by Earlopain (Earlopain _) 14 Feb '25

14 Feb '25

Issue #20971 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #20971: Deprecate `rb_path_check` https://bugs.ruby-lang.org/issues/20971 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- With #16131, various code around $SAFE, taint, etc. has been deprecated and removed. GH PR https://github.com/ruby/ruby/pull/2476. Now, [`rb_path_check`] still exists as part of the public API, with Ruby itself never using or testing it. I believe it should have been deprecated and was simply missed. Should it be deprecated today or is that not worth the effort? Docs for it are pretty vague: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… > This function is mysterious. What it does is not immediately obvious. Also what it does seems platform dependent. [`rb_path_check`]: https://github.com/ruby/ruby/blob/33f95d632dce42fac35da29eaed33f0a5a4f0dcb/… -- https://bugs.ruby-lang.org/

5 12

[ruby-core:120409] [Ruby master Feature#20982] Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4
by herwin (Herwin W) 14 Feb '25

14 Feb '25

Issue #20982 has been reported by herwin (Herwin W). ---------------------------------------- Feature #20982: Inconsistency between Hash#inspect and ENV.inspect in Ruby 3.4 https://bugs.ruby-lang.org/issues/20982 * Author: herwin (Herwin W) * Status: Open ---------------------------------------- Ruby 3.4 changed the stringified output of Hash to add whitespace to the hashrockets ``` ruby -e 'p({"a"=>"b"})' {"a" => "b"} ``` The output of `ENV.inspect` is very similar to `Hash#inspect`, but does not include the whitespace ``` ruby -e 'p ENV' {"SHELL"=>"/bin/bash", [...] } ``` Adding the extra whitespace around the hashrockets would improve the readability, and make things more consistent. -- https://bugs.ruby-lang.org/

2 3