March 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:113966] [Ruby master Bug#19742] Introduce `Module#anonymous?`
by ioquatix (Samuel Williams) 12 Mar '24

12 Mar '24

Issue #19742 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19742: Introduce `Module#anonymous?` https://bugs.ruby-lang.org/issues/19742 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As a follow-on <from https://bugs.ruby-lang.org/issues/19521>, I'd like propose we introduce `Module#anonymous?`. In some situations, like logging/formatting, serialisation/deserialization, debugging or meta-programming, we might like to know if a class is a proper constant or not. However, this brings about some other issues which might need to be discussed. After assigning a constant, then removing it, the internal state of Ruby still believes that the class name is permanent, even thought it's no longer true. e.g. ``` m = Module.new m.anonymous? # true M = m m.anonyomous # false Object.send(:remove_const, :M) M # uninitialized constant M (NameError) M.anonymous? # false ``` Because RCLASS data structure is not updated after the constant is removed, internally the state still has a "permanent class name". I want to use this proposal to discuss this issue and whether there is anything we should do about such behaviour (or even if it's desirable). Proposed PR: https://github.com/ruby/ruby/pull/7966 cc @fxn -- https://bugs.ruby-lang.org/

9 46

[ruby-core:117112] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by byroot (Jean Boussier) 12 Mar '24

12 Mar '24

Issue #13557 has been updated by byroot (Jean Boussier). @ko1 all the same use cases arrays of strings are currently used for: E.g. raising an error with an existing backtrace: ```ruby raise NicerError, "some message", original_error.backtrace_locations ``` Or with some frames skipped: ```ruby raise SomeError, "some message", caller_locations(2) # skip 2 frames ``` Creating an exception with a thread backtrace: ```ruby async_error = SomeError.new("thread timed out") async_error.set_backtrace(other_thread.backtrace_locations) report(async_error) ``` And probably plenty others I'm not thinking of. This is only an improved version of passing `set_backtrace(exc.backtrace)`. ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-107188 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Open ---------------------------------------- When re-raising exceptions, it is sometimes useful to "massage" the backtrace (especially in DSLs). There is currently no way to do it using only backtrace locations. This causes the new exception to have #backtrace_locations return nil, and thus makes backtrace_locations unreliable as a whole. Example: ~~~ruby def test raise ArgumentError, "", caller_locations end begin test rescue ArgumentError => e p e.backtrace_locations end ~~~ attempting to pass `caller_location` to `Kernel#raise` in the `test` method fails with ``bla.rb:2:in `set_backtrace': backtrace must be Array of String (TypeError)`` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117036] [Ruby master Bug#20321] `require': cannot load such file
by Justman10000 (Justin Nogossek) 12 Mar '24

12 Mar '24

Issue #20321 has been reported by Justman10000 (Justin Nogossek). ---------------------------------------- Bug #20321: `require': cannot load such file https://bugs.ruby-lang.org/issues/20321 * Author: Justman10000 (Justin Nogossek) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, have this, when i would compile Ruby: > internal:<RUBY_PATH>/lib/rubygems/core_ext/kernel_require.rb:9:in `require': cannot load such file -- monitor (LoadError) -- https://bugs.ruby-lang.org/

3 13

[ruby-core:116829] [Ruby master Bug#20277] Remove stale `String` test conditionals
by nobu (Nobuyoshi Nakada) 12 Mar '24

12 Mar '24

Issue #20277 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20277: Remove stale `String` test conditionals https://bugs.ruby-lang.org/issues/20277 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found three instance variables in `TestString`. These select assertions: + `@aref_re_nth = true` Enables `String#[regexp, index]` assertions. + `@aref_re_silent = false` Assignment to unmatched region silently fails, if true. + `@aref_slicebang_silent = true` Out of range argument to `String#slice!` returns `nil`, not raising an exception. These instance variables for conditional execution have remained unchanged for nearly twenty years, since YARV merger. It is questionable whether these behaviors can be changed anymore. So I propose to remove these conditionals. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117106] [Ruby master Feature#14066] Add CAA DNS RR on Resolv
by hsbt (Hiroshi SHIBATA) 12 Mar '24

12 Mar '24

Issue #14066 has been updated by hsbt (Hiroshi SHIBATA). Note: https://github.com/ruby/resolv/pull/48 has been merged for this request. ---------------------------------------- Feature #14066: Add CAA DNS RR on Resolv https://bugs.ruby-lang.org/issues/14066#change-107181 * Author: aeris (Nicolas Vinot) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- Hi here, Here is a small PR to add CAA DNS RR on Revolv https://github.com/ruby/ruby/pull/1732 Regards, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117105] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by ko1 (Koichi Sasada) 12 Mar '24

12 Mar '24

Issue #13557 has been updated by ko1 (Koichi Sasada). I'm not against but could you summarize usages? ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-107179 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Open ---------------------------------------- When re-raising exceptions, it is sometimes useful to "massage" the backtrace (especially in DSLs). There is currently no way to do it using only backtrace locations. This causes the new exception to have #backtrace_locations return nil, and thus makes backtrace_locations unreliable as a whole. Example: ~~~ruby def test raise ArgumentError, "", caller_locations end begin test rescue ArgumentError => e p e.backtrace_locations end ~~~ attempting to pass `caller_location` to `Kernel#raise` in the `test` method fails with ``bla.rb:2:in `set_backtrace': backtrace must be Array of String (TypeError)`` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117096] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by Dan0042 (Daniel DeLorme) 10 Mar '24

10 Mar '24

Issue #15554 has been updated by Dan0042 (Daniel DeLorme). Eregon (Benoit Daloze) wrote in #note-19: > It would need to warn by default to address that. Or you need to use $VERBOSE, or it could be a new category like `Warning[:strict]`. But it only indicates a *possible* problem, not *definitely* a problem. At the very least I'd make it a verbose warning during 1-2 years so that gems have the time to update. When gems output warnings and there's no fix available, it can be quite annoying, as experienced during the 2.7 migration. Even more so if those warnings are false positives. ko1 (Koichi Sasada) wrote in #note-14: > We found issues with this warning system, like: https://github.com/ruby/ruby/commit/8316cb213c This is fairly conclusive evidence that the warning is helpful. Will no one add it to the next dev meeting agenda? ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-107169 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117085] [Ruby master Bug#20328] optparse omits the option's description in the --help output if the description is an Array
by postmodern (Hal Brodigan) 08 Mar '24

08 Mar '24

Issue #20328 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Bug #20328: optparse omits the option's description in the --help output if the description is an Array https://bugs.ruby-lang.org/issues/20328 * Author: postmodern (Hal Brodigan) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If you define an option using `OptionParser#on`, but give the option's description as a multi-line Array, then the option's description is omitted from the `--help` output. ## Steps To Reproduce ```ruby #!/usr/bin/env ruby require 'optparse' optparser = OptionParser.new do |opts| opts.banner = 'usage: test.rb [options]' opts.on('-o', '--opt [OPT]', 'Line one') do |opt| end opts.on('-m', '--multiline-opt', ['Line one', 'Line two']) do |test| end opts.on('-h', '--help', 'Prints this help') do puts opts exit end end optparser.parse(['--help']) ``` ### Expected result ``` usage: test.rb [options] -o, --opt [OPT] Line one -m, --multiline-opt Line one Line two -h, --help Prints this help ``` ### Actual Result ``` usage: test.rb [options] -o, --opt [OPT] Line one -m, --multiline-opt -h, --help Prints this help ``` or an `ArgumentError` should be raised if Array descriptions are not allowed/supported. ## Version Info Tested against optparse 0.1.0, 0.2.0, 0.3.1, and the master branch. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117067] [Ruby master Feature#20326] Add an `undefined` for use as a default argument.
by shan (Shannon Skipper) 07 Mar '24

07 Mar '24

Issue #20326 has been reported by shan (Shannon Skipper). ---------------------------------------- Feature #20326: Add an `undefined` for use as a default argument. https://bugs.ruby-lang.org/issues/20326 * Author: shan (Shannon Skipper) * Status: Open ---------------------------------------- Variations around `UNDEFINED = Object.new` are a fairly common pattern to see used as default arguments to distinguish between `nil` and no argument provided. For example, a Ruby implementation of Array#count might look something like: ``` ruby class Array UNDEFINED = Object.new def UNDEFINED.inspect = 'UNDEFINED' UNDEFINED.freeze def count(item = UNDEFINED) if item == UNDEFINED # ... end end end ``` I'd like to propose adding an `undefined` module function method on Kernel to remove the boilerplate for this fairly common use case. An `__undefined__` method or `__UNDEFINED__` keyword would be alternatives to `undefined`. An `undefined?` helper would also be an optional nicety: ``` ruby class Array def count(item = undefined) if item.undefined? # ... end end end ``` A Ruby implementation might look like: ``` ruby module Kernel UNDEFINED = Object.new def UNDEFINED.inspect = -'undefined' UNDEFINED.freeze private_constant :UNDEFINED def undefined? = self == UNDEFINED module_function def undefined = UNDEFINED end ``` -- https://bugs.ruby-lang.org/

6 6

[ruby-core:117056] [Ruby master Bug#20325] Enumerator.product.size bug with zero * infinite enumerators
by marcandre (Marc-Andre Lafortune) 07 Mar '24

07 Mar '24

Issue #20325 has been reported by marcandre (Marc-Andre Lafortune). ---------------------------------------- Bug #20325: Enumerator.product.size bug with zero * infinite enumerators https://bugs.ruby-lang.org/issues/20325 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Target version: 3.4 * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` ruby Enumerator.product([], 1..).to_a # => [] (OK) Enumerator.product([], 1..).size # => Infinity (Should be 0) ``` -- https://bugs.ruby-lang.org/

3 3