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

[ruby-core:117734] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Quintasan 28 Apr '24

28 Apr '24

Issue #18915 has been updated by Quintasan (Michał Zając). nithinbekal (Nithin Bekal) wrote in #note-18: > > What name candidate do you have? > > What do you think about the name `SubclassResponsibilityError`? As @citizen428 explains [here](https://ruby.social/@citizen428@chaos.social/112239323523258221): > > > Smalltalk had the idiom of implementing abstract methods with the body `self subclassResponsibility` which raises an error. > > The name gives a pretty clear indication of what is wrong, and it seems fitting considering Ruby's Smalltalk heritage. I like this as well as `AbstractMethodError` ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-108140 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117732] [Ruby master Bug#20460] Ripper `eval` option
by kddnewton (Kevin Newton) 27 Apr '24

27 Apr '24

Issue #20460 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20460: Ripper `eval` option https://bugs.ruby-lang.org/issues/20460 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There are a couple of differences when producing syntax trees from the parser/ripper when compiling for eval. Namely, for the eval case it does not raise a syntax error for invalid jumps. It would be nice to be able to pass an `eval: true/false` option to `Ripper.sexp`/`Ripper.sexp_raw`/`Ripper.new` to tell it to parse as if it were an `eval`. Because of some new syntax errors, this had led to bugs like https://bugs.ruby-lang.org/issues/20186. If we provide such an option, it could also be useful for debugging purposes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116802] [Ruby master Misc#20272] Ambiguity around Ractor message sending FIFO semantics
by forthoney (Seong-Heon Jung) 26 Apr '24

26 Apr '24

Issue #20272 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Misc #20272: Ambiguity around Ractor message sending FIFO semantics https://bugs.ruby-lang.org/issues/20272 * Author: forthoney (Seong-Heon Jung) * Status: Open * Priority: Normal ---------------------------------------- The docs should explicitly state the semantics/properties of Ractor message, especially when it comes to FIFO. For example, assume I have two Ractors, Ractor A and Ractor B. Ractor A sends two messages `"hello"` and `"world"` in this order to Ractor B. If I call `Ractor.receive` on Ractor B, am I guaranteed to see `"hello"` and then `"world"` or is it possible the messages are delivered out of order? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117646] [Ruby master Bug#20444] Kernel#loop: returning the "result" value of StopIteration doesn't work when raised directly
by esad (Esad Hajdarevic) 26 Apr '24

26 Apr '24

Issue #20444 has been reported by esad (Esad Hajdarevic). ---------------------------------------- Bug #20444: Kernel#loop: returning the "result" value of StopIteration doesn't work when raised directly https://bugs.ruby-lang.org/issues/20444 * Author: esad (Esad Hajdarevic) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There was a https://bugs.ruby-lang.org/issues/11498 a while ago which was merged in, but I was surprised to find out that raising `StopIteration` in a loop like `loop { raise StopIteration.new(3) }` returns nil and not 3. -- https://bugs.ruby-lang.org/

3 8

[ruby-core:117711] [Ruby master Bug#20456] Hash can get stuck marked as iterating through process forking
by blowfishpro (Talia Wong) 26 Apr '24

26 Apr '24

Issue #20456 has been reported by blowfishpro (Talia Wong). ---------------------------------------- Bug #20456: Hash can get stuck marked as iterating through process forking https://bugs.ruby-lang.org/issues/20456 * Author: blowfishpro (Talia Wong) * Status: Open * ruby -v: 3.3.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- # Steps to Reproduce 1. Iterate over a hash 1. While that iteration is happening, fork the process a. This should be done in a way that causes the iteration to never finish from the child process's view, e.g. fork with a block, or iteration is happening in a different thread than fork 1. Attempt to add a new key to the hash in the child process a. This can be before or after the iteration finishes in the parent process, doesn't matter # Observed Behavior The child process can never add a new key to the hash, always fails with `RuntimeError: can't add a new key into hash during iteration` # Desired The hash is no longer iterating in the child process, so it can be modified as needed # Examples ## With threads: ```ruby h = { a: 1 } t = Thread.new do sleep 0.05 pid = fork do sleep 0.1 puts 'child: before' h[:b] = 2 puts 'child: after' end Process.wait2(pid) end puts 'parent: before' h.each do sleep 0.1 end puts 'parent: after' puts t.join.value.inspect ``` produces: ``` parent: before parent: after child: before can't add a new key into hash during iteration (RuntimeError) [34450, #<Process::Status: pid 34450 exit 1>] ``` ## Without threads: ``` ruby h = { a: 1 } pid = nil puts 'parent: before' h.each do pid = fork do sleep 0.05 puts 'child: before' h[:b] = 2 puts 'child: after' end end puts 'parent: after' puts Process.wait2(pid).inspect ``` produces: ``` parent: before parent: after child: before can't add a new key into hash during iteration (RuntimeError) [17809, #<Process::Status: pid 17809 exit 1>] ``` # Platform information This behavior has been observed in the following environments - Ruby 3.3.0 on Mac OS 14.4.1 (Apple M1 Max) installed via [asdf](https://asdf-vm.com/) - Ruby 2.7.5 on Mac OS 14.4.1 (Apple M1 Max) installed via [asdf](https://asdf-vm.com/) - Ruby 3.2.3 on RockyLinux 8.4 (x86_64) installed from [Fullstaq](https://fullstaqruby.org/) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:117715] [Ruby master Bug#20458] OpensSSL::SSL::SSLContext#min_version= and #max_version no longer accept Symbol values
by postmodern (Hal Brodigan) 25 Apr '24

25 Apr '24

Issue #20458 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Bug #20458: OpensSSL::SSL::SSLContext#min_version= and #max_version no longer accept Symbol values https://bugs.ruby-lang.org/issues/20458 * Author: postmodern (Hal Brodigan) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It appears that `OpenSSL::SSL::SSLContext#min_version=` and `#max_version=` no longer accept Symbol values, contrary to their [documentation](https://docs.ruby-lang.org/en/master/OpenSSL/SSL/SSLContext.…. Instead it appears they are being converted to Strings. ## Steps To Reproduce ```ruby require 'openssl' context = OpenSSL::SSL::SSLContext.new context.min_version = :TLSv1 ``` ```ruby require 'openssl' context = OpenSSL::SSL::SSLContext.new context.max_version = :TLSv1_2 ``` ### Expected Results Sets `min_version` and `max_version` to the according `OpenSSL::SSL::TLS1_VERSION` and `OpenSSL::SSL::TLS1_2_VERSION` values, respectively. ### Actual Results ``` /usr/share/ruby/openssl/ssl.rb:179:in `set_minmax_proto_version': unrecognized version "TLSv1" (ArgumentError) set_minmax_proto_version(version, @max_proto_version ||= nil) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ from /usr/share/ruby/openssl/ssl.rb:179:in `min_version=' ``` ``` /usr/share/ruby/openssl/ssl.rb:191:in `set_minmax_proto_version': unrecognized version "TLSv1_2" (ArgumentError) set_minmax_proto_version(@min_proto_version ||= nil, version) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ from /usr/share/ruby/openssl/ssl.rb:191:in `max_version=' ``` ### Version Info Tested on: * `ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]` and `openssl` gem version `3.1.0` * `ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux]` and `openssl` gem version `3.2.0` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:117710] [Ruby master Bug#20455] rb_errinfo() inconsistent with $! in the caller Ruby code
by Eregon (Benoit Daloze) 25 Apr '24

25 Apr '24

Issue #20455 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20455: rb_errinfo() inconsistent with $! in the caller Ruby code https://bugs.ruby-lang.org/issues/20455 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.4.0dev (2024-04-25T08:12:47Z master 64bd8e41df) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This (slightly modified for clarity) test in ruby/spec demonstrates the unexpected result: ```ruby describe "rb_errinfo" do def err $! end it "is cleared when entering a C method" do begin raise StandardError rescue $!.class.should == StandardError err.class.should == StandardError @s.rb_errinfo().should == nil end end ``` Why does `rb_errinfo()` return nil there, when $! is set in the caller (and $! isn't per frame but per thread, as shown with `err`)? Is this bug? If not, what is the logic and reason for clearing `$!` when calling a method defined in C? -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116218] [Ruby master Bug#20186] Ripper does not generate AST for some keywords in Ruby 3.3
by kzkn (Kazuki Nishikawa) 24 Apr '24

24 Apr '24

Issue #20186 has been reported by kzkn (Kazuki Nishikawa). ---------------------------------------- Bug #20186: Ripper does not generate AST for some keywords in Ruby 3.3 https://bugs.ruby-lang.org/issues/20186 * Author: kzkn (Kazuki Nishikawa) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ripper does not generate AST for the below keyword: - break - next - redo - retry - yield Ruby 3.2 ``` $ ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] $ ruby -rripper -e "p Ripper.sexp('break')" [:program, [[:break, []]]] $ ruby -rripper -e "p Ripper.sexp('next')" [:program, [[:next, []]]] $ ruby -rripper -e "p Ripper.sexp('redo')" [:program, [[:redo]]] $ ruby -rripper -e "p Ripper.sexp('retry')" [:program, [[:retry]]] $ ruby -rripper -e "p Ripper.sexp('yield')" [:program, [[:yield0]]] ``` Ruby 3.3 ``` $ ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] $ ruby -rripper -e "p Ripper.sexp('break')" nil $ ruby -rripper -e "p Ripper.sexp('next')" nil $ ruby -rripper -e "p Ripper.sexp('redo')" nil $ ruby -rripper -e "p Ripper.sexp('retry')" nil $ ruby -rripper -e "p Ripper.sexp('yield')" nil ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116687] [Ruby master Bug#20262] Regex mismatch between Ruby 3.2.2 and 3.3.0
by weilandia (Nick Weiland) 24 Apr '24

24 Apr '24

Issue #20262 has been reported by weilandia (Nick Weiland). ---------------------------------------- Bug #20262: Regex mismatch between Ruby 3.2.2 and 3.3.0 https://bugs.ruby-lang.org/issues/20262 * Author: weilandia (Nick Weiland) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This might be a duplicate of https://bugs.ruby-lang.org/issues/20098, but I cannot make it match with the backref so maybe not. Below example matches in 3.2.2 but not in 3.3.0 ``` ruby str = "------------abcdefg------------#3895912" re = /()\1\b\w*[a-zA-Z-]*\d+[\w-]{3,}\w+\b/ re.match?(str) ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117670] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by ko1 (Koichi Sasada) 24 Apr '24

24 Apr '24

Issue #15554 has been updated by ko1 (Koichi Sasada). Status changed from Closed to Assigned BTW on our application I found the following issue on RSpec tests on strict mode. ``` it ... do subject do ... end # this subject ignores the block end ``` This kind of issue can not be checked with current relax mode (because `subject{}` works outside of `it` block). I feel this kind of information is useful if developers have (1) effective warning filtering mechanism and (2) a tool to list the suspicious methods by analyzing the acquired warnings. For (1), at least application authors doesn't need gem's warning. For (2), false positive will be ignored easily (as https://bugs.ruby-lang.org/issues/15554#note-57) Also I'm afraid that if we introduce strict mode option (like environment variable), people can believe duck typing methods should make explicit for accepting block or not. It is what Matz does not like (*now*). ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-108080 * Author: ko1 (Koichi Sasada) * Status: Assigned * 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