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

[ruby-core:120856] [Ruby master Feature#21105] Improve Ruby Stack Trace to Include Exact Error Position (Column Number)
by ennder 25 Feb '25

25 Feb '25

Issue #21105 has been reported by ennder (Jérôme BATAILLE). ---------------------------------------- Feature #21105: Improve Ruby Stack Trace to Include Exact Error Position (Column Number) https://bugs.ruby-lang.org/issues/21105 * Author: ennder (Jérôme BATAILLE) * Status: Open ---------------------------------------- h2. Subject Improve Ruby Stack Trace to Include Exact Error Position (Column Number) h2. Description Currently, when an exception occurs in Ruby, the stack trace provides the file name and line number but does not indicate the exact position (column number) where the error occurred within the line. This lack of precision can make debugging more challenging, especially in cases where multiple method calls or expressions are present on the same line. h2. Example <pre><code class="ruby"> class Example def self.run nil.some_method_call # Error occurs here end end Example.run </code></pre> h2. Expected Behavior The stack trace should include the column number where the error occurred, e.g.: <pre><code> trace.rb:4:10:in `run': undefined method `some_method_call' for nil:NilClass (NoMethodError) </code></pre> h2. Benefits More precise debugging. Easier identification of errors in complex one-liner expressions. Better tooling support for editors and debuggers. h2. Additional Notes Would it be possible to add this enhancement in a future Ruby version? Thank you for considering this request! -- 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:121148] [Ruby master Feature#21155] File scoped namespace declarations as in C#
by artur86 (Artur *) 24 Feb '25

24 Feb '25

Issue #21155 has been reported by artur86 (Artur *). ---------------------------------------- Feature #21155: File scoped namespace declarations as in C# https://bugs.ruby-lang.org/issues/21155 * Author: artur86 (Artur *) * Status: Open ---------------------------------------- Given there is a class that needs to be namespaced. `module` requires indenting the class by one level: ```ruby module MyNamespace class MyClass; end end ``` Scope resolution operator (`::`) does not require it, but it works differently than using `module` and repeating module name for every class inside seems tedious and verbose to me: ```ruby class MyNamespace::MyClass; end class MyNamespace::MyAnotherClass; end class MyNamespace::OneMoreClass; end end ``` What if something similar to [File Scoped Namespaces in C#](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/prop… would be implemented in Ruby? The concept basically states as "everything in this file should be in some module", as it is formulated in [a question on StackOverflow](https://stackoverflow.com/q/40809717/2987689). -- https://bugs.ruby-lang.org/

2 3

[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:121137] [Ruby master Bug#16145] regexp match error if mixing /i, character classes, and utf8
by mjrzasa 21 Feb '25

21 Feb '25

Issue #16145 has been updated by mjrzasa (Maciek Rząsa). Fix: https://github.com/ruby/ruby/pull/12787 ---------------------------------------- Bug #16145: regexp match error if mixing /i, character classes, and utf8 https://bugs.ruby-lang.org/issues/16145#change-112069 * Author: zenspider (Ryan Davis) * Status: Open * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- (reported on behalf of mage(a)mage.gold -- there appears to be an error in registration or login): See: ruby-talk @ X-Mail-Count: 440336 2.6.3 :049 > 'SHOP' =~ /[xo]/i => 2 2.6.3 :050 > 'CAFÉ' =~ /[é]/i => 3 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => nil 2.6.3 :052 > 'CAFÉ' =~ /[xÉ]/i => 3 Expected result: 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => 3 I tested it on random regex online pages. It does not match on https://regex101.com/ It matches on: https://regexr.com/ https://www.regextester.com/ https://www.freeformatter.com/regex-tester.html (Ignore case turned on). The reason I suppose it’s more like a bug than a feature is the fact that /[é]/i matches 'CAFÉ'. If the //i didn’t work for UTF-8 characters then the /[é]/i wouldn’t match it either. For example, [é] does not match 'CAFÉ' on https://regex101.com/ I could not find a page or a system that behaves the same way as Ruby does. For example, it matches in PostgreSQL 10 (under FreeBSD 12) too: # select 'CAFÉ'~ '[xé]'; ?column? ---------- f (1 row) # select 'CAFÉ' ~* '[xé]'; ?column? ---------- t (1 row) Tested it in IRB on macOS and FreeBSD. $ uname -a && ruby -v && locale Darwin xxx 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" $ uname -a && ruby -v && locale FreeBSD xxx 12.0-RELEASE-p9 FreeBSD 12.0-RELEASE-p9 GENERIC amd64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-freebsd12.0] LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 I installed Ruby with RVM. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121127] [Ruby master Bug#21150] Segfault in Ractor messes up libunwind (c backtrace info)
by luke-gru (Luke Gruber) 20 Feb '25

20 Feb '25

Issue #21150 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21150: Segfault in Ractor messes up libunwind (c backtrace info) https://bugs.ruby-lang.org/issues/21150 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Macos Arm64 with llvm18, libunwind fails with SEGV when called within a Ractor. So, the bug report fails with a SEGV and quits right before giving C backtrace information. It looks like: ``` -- Ruby level backtrace information ---------------------------------------- ../ruby/test.rb:49:in 'block in <main>' <internal:ractor>:902:in 'fail_assert' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- <internal:ractor>:902: [BUG] Segmentation fault at 0xfffffffffffffff8 ``` It tried to dereference the value -8, it looks like. ### To reproduce: `test.rb`: ```ruby r = Ractor.new do Ractor.fail_assert # to produce a bug report end r.take ``` `ractor.rb`: ```ruby def self.fail_assert __builtin_cexpr! %q{ VM_ASSERT(0), Qfalse } end ``` ### System info: `clang --version`: Homebrew clang version 18.1.8 Target: arm64-apple-darwin24.3.0 Thread model: posix `otool -L miniruby`: /opt/homebrew/opt/llvm(a)18/lib/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0) I haven't tried to reproduce it on another system, but I did try with clang 16 and got the same results. ### Possible Causes This is just a guess, but I think the coroutine context switching is messing up libunwind's stack unwinding heuristic. ### Other issues that this causes Right now, if ruby receives a SEGV in a ractor, it tries to print the bug report and then receives another SEGV when running the libunwind code. This hangs the program because the sigaction for the SEGV signal was installed without SA_NODEFER, so that SEGV is blocked (masked) by the running handler. The program can't make any forward progress, so it hangs. The solution here is just to install the fatal handlers with SA_NODEFER. There is code already that checks if the bug report has already been called and it just aborts the process. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121121] [Ruby master Bug#21149] Strange behavior of ObjectSpace.each_object after Ractor.new
by wanabe (_ wanabe) 19 Feb '25

19 Feb '25

Issue #21149 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #21149: Strange behavior of ObjectSpace.each_object after Ractor.new https://bugs.ruby-lang.org/issues/21149 * Author: wanabe (_ wanabe) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I found the strange behavior of `ObjectSpace.each_object`. It misses some objects after `Ractor.new`. ``` $ ruby -ve 'class Foo; end; foo = Foo.new; Ractor.new do buz = Foo.new end.take; bar = Foo.new; p [ObjectSpace.each_object(Foo).to_a, foo.class, bar.class]' ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [[], Foo, Foo] ``` Of course it works well without `Ractor.new`. ``` $ ruby -ve 'class Foo; end; foo = Foo.new; bar = Foo.new; p [ObjectSpace.each_object(Foo).to_a, foo.class, bar.class]' ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] [[#<Foo:0x00007fa84f4b26d0>, #<Foo:0x00007fa84f4b27c0>], Foo, Foo] ``` -- https://bugs.ruby-lang.org/

3 3

[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:120743] [Ruby master Bug#21049] Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables`
by mame (Yusuke Endoh) 18 Feb '25

18 Feb '25

Issue #21049 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21049: Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables` https://bugs.ruby-lang.org/issues/21049 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, `Binding#local_variable*` APIs wrongly handles the numbered parameters. ```ruby # Binding#local_variables includes numbered parameters that should not be visible "foo".tap do _1 "bar".tap do p binding.local_variables #=> expected: [], actual: [:_1] end end # Binding#local_variable_get can read numbered parameters that should not be readable "foo".tap do _1 "bar".tap do p binding.local_variable_get(:_1) #=> expected: NameError, actual: "foo" end end # Binding#local_variable_set can update numbered parameter "foo".tap do p _1 #=> "foo" binding.local_variable_set(:_1, "bar") # expected: NameError, actual: updates _1 p _1 #=> "bar" end ``` My proposal is to stop handling numbered parameters and "it" parameter in `Binding#local_variable*` APIs. ```ruby "foo".tap do _1 binding.local_variables #=> proposed: [] binding.local_variable_get(:_1) #=> proposed: NameError end ``` Here is a proof-of-concept patch. https://github.com/ruby/ruby/pull/12601 It would be theoretically possible to fix `Binding#local_variable*` APIs to handle numbered parameters while maintaining compatibility as much as possible. However, I think the implicit “it” parameter introduced in Ruby 3.4 poses a spec-level problem. This is because there is no way to distinguish between the implicit “it” parameter and a true local variable named "it". Also, I don't think numbered parameters are local variables, so I feel uncomfortable handling them by `Binding#local_variable*` APIs. If it is absolutely necessary to access numbered parameters or "it" parameter via binding, it would be good to introduce dedicated APIs for the purpose, as: * Binding#numbered_parameters #=> [:_1, :_2, :_3, ...] * Binding#numbered_parameter_get(:_1) #=> obj * Binding#numbered_parameter_defined?(:_1) #=> true or false * Binding#it_get #=> obj * Binding#it_defined? #=> true or false Personally, however, I do not see the need for these APIs currently. I implemented them as proof-of-concept in PR, but I am okay that they are not introduced. -- https://bugs.ruby-lang.org/

2 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