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

[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

[ruby-core:120992] [Ruby master Feature#21135] Feature request: Enumerable.compare_count
by Student (Nathan Zook) 17 Feb '25

17 Feb '25

Issue #21135 has been reported by Student (Nathan Zook). ---------------------------------------- Feature #21135: Feature request: Enumerable.compare_count https://bugs.ruby-lang.org/issues/21135 * Author: Student (Nathan Zook) * Status: Open ---------------------------------------- Enumerables at times can be quite expensive to complete expand. If all is desired is to compare the count, we can terminate the enumeration once the result is known. The functionality that I envision, if implemented in ruby, might look like this: ```ruby module Enumerable def compare_count(operation, standard, &blk) case operation when :< compare_count_lt(standard, &blk) when :>= !compare_count_lt(standard, &blk) when :> compare_count_spaceship(standard, &blk) == 1 when :<= compare_count_spaceship(standard, &blk) != 1 when :== compare_count_spaceship(standard, &blk) == 0 when :!= compare_count_spaceship(standard, &blk) != 0 end end def compare_count_lt(standard, &blk) truncate_count(standard - 1, &blk) < standard end def compare_count_spaceship(standard, &blk) truncate_count(standard, &blk) <=> standard end def truncate_count(limit, &blk) return 0 if limit < 0 found = 0 each do |ele| found += 1 unless blk && !yield(ele) break if found > limit end found end end class Demo include Enumerable attr_reader :capacity attr_reader :cnt def initialize(capacity) @capacity = capacity end def each @cnt = 0 while cnt < capacity @cnt += 1 yield cnt end end end %i{< <= >= > == !=}.each do |op| d = Demo.new(3) (-1..5).each do |x| puts [op, x, d.compare_count(op, x), d].inspect end end require 'prime' %i{< <= >= > == !=}.each do |op| d = Demo.new(6) (-1..5).each do |x| puts [op, x, d.compare_count(op, x){|p| Prime.prime?(p)} , d].inspect end end ``` ``` [:<, -1, false, #<Demo:0x034d567c @capacity=3>] [:<, 0, false, #<Demo:0x034d567c @capacity=3>] [:<, 1, false, #<Demo:0x034d567c @capacity=3, @cnt=1>] [:<, 2, false, #<Demo:0x034d567c @capacity=3, @cnt=2>] [:<, 3, false, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<, 4, true, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<, 5, true, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<=, -1, false, #<Demo:0x034d512c @capacity=3>] [:<=, 0, false, #<Demo:0x034d512c @capacity=3, @cnt=1>] [:<=, 1, false, #<Demo:0x034d512c @capacity=3, @cnt=2>] [:<=, 2, false, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 3, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 4, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 5, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:>=, -1, true, #<Demo:0x034d4d44 @capacity=3>] [:>=, 0, true, #<Demo:0x034d4d44 @capacity=3>] [:>=, 1, true, #<Demo:0x034d4d44 @capacity=3, @cnt=1>] [:>=, 2, true, #<Demo:0x034d4d44 @capacity=3, @cnt=2>] [:>=, 3, true, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>=, 4, false, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>=, 5, false, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>, -1, true, #<Demo:0x034d4998 @capacity=3>] [:>, 0, true, #<Demo:0x034d4998 @capacity=3, @cnt=1>] [:>, 1, true, #<Demo:0x034d4998 @capacity=3, @cnt=2>] [:>, 2, true, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 3, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 4, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 5, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:==, -1, false, #<Demo:0x034d4600 @capacity=3>] [:==, 0, false, #<Demo:0x034d4600 @capacity=3, @cnt=1>] [:==, 1, false, #<Demo:0x034d4600 @capacity=3, @cnt=2>] [:==, 2, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 3, true, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 4, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 5, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:!=, -1, true, #<Demo:0x034d4268 @capacity=3>] [:!=, 0, true, #<Demo:0x034d4268 @capacity=3, @cnt=1>] [:!=, 1, true, #<Demo:0x034d4268 @capacity=3, @cnt=2>] [:!=, 2, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 3, false, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 4, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 5, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:<, -1, false, #<Demo:0x00007f64147c37e0 @capacity=6>] [:<, 0, false, #<Demo:0x00007f64147c37e0 @capacity=6>] [:<, 1, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=2>] [:<, 2, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=3>] [:<, 3, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=5>] [:<, 4, true, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=6>] [:<, 5, true, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=6>] [:<=, -1, false, #<Demo:0x00007f64147c21d8 @capacity=6>] [:<=, 0, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=2>] [:<=, 1, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=3>] [:<=, 2, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=5>] [:<=, 3, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:<=, 4, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:<=, 5, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:>=, -1, true, #<Demo:0x00007f64147c0860 @capacity=6>] [:>=, 0, true, #<Demo:0x00007f64147c0860 @capacity=6>] [:>=, 1, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=2>] [:>=, 2, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=3>] [:>=, 3, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=5>] [:>=, 4, false, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=6>] [:>=, 5, false, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=6>] [:>, -1, true, #<Demo:0x00007f64147df260 @capacity=6>] [:>, 0, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=2>] [:>, 1, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=3>] [:>, 2, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=5>] [:>, 3, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:>, 4, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:>, 5, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:==, -1, false, #<Demo:0x00007f64147dd898 @capacity=6>] [:==, 0, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=2>] [:==, 1, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=3>] [:==, 2, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=5>] [:==, 3, true, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:==, 4, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:==, 5, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:!=, -1, true, #<Demo:0x00007f64147dbf20 @capacity=6>] [:!=, 0, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=2>] [:!=, 1, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=3>] [:!=, 2, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=5>] [:!=, 3, false, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] [:!=, 4, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] [:!=, 5, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121072] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set
by greggzst (Grzegorz Jakubiak) 15 Feb '25

15 Feb '25

Issue #16993 has been updated by greggzst (Grzegorz Jakubiak). nobu (Nobuyoshi Nakada) wrote in #note-5: > This kind of extensions should be done in the corresponding library side, set.rb. Thanks for pointing that out. Here's the PR https://github.com/ruby/set/pull/40 Dan0042 (Daniel DeLorme) wrote in #note-6: > I like the concept but I'm going to bikeshed the naming: by itself "key_set" is unclear if you don't already know what it does. It sounds like the purpose is to set a key (like instance_variable_set). I'd prefer something a bit more descriptive like "keys_to_set" Good point I addressed that ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-111989 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0