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

[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

[ruby-core:115925] [Ruby master Bug#20096] Ruby 3.2.2 win32/registry: Junk appended to Windows Registry String Value
by jay4rubydev (Jay M) 07 Mar '24

07 Mar '24

Issue #20096 has been reported by jay4rubydev (Jay M). ---------------------------------------- Bug #20096: Ruby 3.2.2 win32/registry: Junk appended to Windows Registry String Value https://bugs.ruby-lang.org/issues/20096 * Author: jay4rubydev (Jay M) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mswin64_140] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby Version: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mswin64_140] Compiler: MSVC 2019 - Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30147 for x64. Issue: win32/registry adds junk to Windows Registry String Value Code: require 'win32/registry' win_oracle_key = "SOFTWARE\\MicroSoft" reg=Win32::Registry::HKEY_LOCAL_MACHINE.open(win_oracle_key, Win32::Registry::KEY_ALL_ACCESS) inst_loc_key = "inst_loc" inv_dir="C:\\Program Files\\Tester\\ModuleInfo" reg[inst_loc_key] = inv_dir Result: Registry contains: C:\Program Files\Tester\ModuleInfo爀 Observation: Looks like memory overread Expected Result - without the junk: C:\Program Files\Tester\ModuleInfo After changing the code in registry.rb: From: def write(name, type, data) termsize = 0 case type when REG_SZ, REG_EXPAND_SZ data = data.encode(WCHAR) termsize = WCHAR_SIZE To: def write(name, type, data) termsize = 0 case type when REG_SZ, REG_EXPAND_SZ enc_data = data.encode(WCHAR) # Add NULL WCHAR for string data and don't set the termsize because # enc_data.bytesize will now include the size of the NULL character. enc_data += WCHAR_NUL # termsize = WCHAR_SIZE ... -- https://bugs.ruby-lang.org/

4 7

[ruby-core:117063] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 06 Mar '24

06 Mar '24

Issue #18035 has been updated by ioquatix (Samuel Williams). I encountered this issue recently: https://bugs.ruby-lang.org/issues/17159 I think immutability would cover these types of problems too. I think it would be worthwhile discussing the merits of shareability vs immutability as a baseline model that we expect people to build on. ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-107137 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117046] [Ruby master Bug#20323] Segmentation Fault in while working in Ruby 2.6.3
by sriram-ruby-dev (Sriram A) 04 Mar '24

04 Mar '24

チケット #20323 を sriram-ruby-dev (Sriram A) さんが作成しました。 ---------------------------------------- Bug #20323: Segmentation Fault in while working in Ruby 2.6.3 https://bugs.ruby-lang.org/issues/20323 * 作成者: sriram-ruby-dev (Sriram A) * ステータス: Open * ruby -v: 2.6.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am using Ruby 2.6.3 in my project. Suddenly my application raises segmentation fault issue, I have tried the solution mentioned in https://bugs.ruby-lang.org/issues/18555#note-6 the above issue, but it doesn't solve my problem. I have attached log of the error. ``` ruby 2023-08-09 12:44:32 /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383: [BUG] Illegal instruction at 0x0000ffff90d911a0 2023-08-09 12:44:32 ruby 2.6.3p62 (2019-04-16 revision 67580) [aarch64-linux] 2023-08-09 12:44:32 2023-08-09 12:44:32 -- Control frame information ----------------------------------------------- 2023-08-09 12:44:32 c:0046 p:---- s:0274 e:000273 CFUNC :syswrite_nonblock 2023-08-09 12:44:32 c:0045 p:0013 s:0268 e:000267 METHOD /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383 2023-08-09 12:44:32 c:0044 p:0021 s:0261 e:000260 BLOCK /usr/local/lib/ruby/2.6.0/net/protocol.rb:277 [FINISH] 2023-08-09 12:44:32 c:0043 p:---- s:0253 e:000252 IFUNC 2023-08-09 12:44:32 c:0042 p:---- s:0250 e:000249 CFUNC :each 2023-08-09 12:44:32 c:0041 p:---- s:0247 e:000246 CFUNC :each_with_index ``` ---ファイル--------------------------------- output.log (509 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117018] [Ruby master Feature#20317] Removing the `allocate` method should cause `new` to fail
by tenderlovemaking (Aaron Patterson) 04 Mar '24

04 Mar '24

Issue #20317 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #20317: Removing the `allocate` method should cause `new` to fail https://bugs.ruby-lang.org/issues/20317 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- When you remove the `allocate` method from a class the you can't allocate the class via the `allocate` method. However, you _can_ allocate the class via the `new` method: ```ruby class Foo; end Foo.singleton_class.undef_method(:allocate) begin Foo.allocate # doesn't work, of course rescue NoMethodError end begin Class.instance_method(:allocate).bind_call(Foo) # also doesn't work rescue TypeError end Foo.new # works? ``` I think that when we remove the `allocate` method, the `new` method should also fail as there is no `allocate` method for `new` to call. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116542] [Ruby master Misc#20232] Document Kernel#require and Module#autoload concurrency guarantees
by fxn (Xavier Noria) 04 Mar '24

04 Mar '24

Issue #20232 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #20232: Document Kernel#require and Module#autoload concurrency guarantees https://bugs.ruby-lang.org/issues/20232 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal ---------------------------------------- I'd like to document `Kernel#require` and `Module#autoload` concurrency guarantees. In the case of multiple threads loading the same file concurrently, `Kernel#require` will succeed in just one of them and the rest will wait and return false. If a constant that has an autoload is concurrently referenced, the same can be said. Assuming no errors, only one thread will succeed, and the rest wait. There will be no context switching in the middle of an autoload that will result in a `NameError` in other threads waiting for that constant. Now, I'd like to have a discussion about those guarantees with fibers. In the case of manually managed fibers, users can enter a deadlock by hand: ```ruby # This produces a deadlock. File.write('/tmp/bar.rb', <<~RUBY) Fiber.yield RUBY Fiber.new { require '/tmp/bar.rb' }.resume Fiber.new { require '/tmp/bar.rb' }.resume ``` If this is expected, I guess users should be told this is a possibility in the API dosc? Because from a user perspective, you don't really have elements to anticipate a deadlock there if the docs don't warn you. A similar deadlock can be triggered with an `autoload` instead of a `require`: ```ruby # This produces a deadlock. File.write('/tmp/bar.rb', <<~RUBY) Fiber.yield Bar = 1 RUBY autoload :Bar, '/tmp/bar.rb' Fiber.new { Bar }.resume Fiber.new { Bar }.resume ``` A different matter is fibers managed by fiber schedulers. I have not been able to enter a deadlock with the fiber schedulers I have tried, but from the point of view of the user, doing something like I/O or sleeping at the top-level is not unlike that manual `Fiber.yield` above. The contract for fiber schedulers is mostly an interface, but it does not address this, at least in an explicit way. Do fiber schedulers guarantee anything about this with the current contract? I'd be glad to volunteer docs with the conclusions of this thread. -- https://bugs.ruby-lang.org/

1 1