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

[ruby-core:117734] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

by Quintasan

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 week

1
0
0 0

[ruby-core:117732] [Ruby master Bug#20460] Ripper `eval` option

by kddnewton (Kevin Newton)

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 week, 1 day

1
0
0 0

[ruby-core:117674] [Ruby master Bug#20450] Ruby 3.1.1 broken with bootsnap

by philippe.bs.noel＠tutanota.com (Philippe Noel)

Issue #20450 has been reported by philippe.bs.noel(a)tutanota.com (Philippe Noel). ---------------------------------------- Bug #20450: Ruby 3.1.1 broken with bootsnap https://bugs.ruby-lang.org/issues/20450 * Author: philippe.bs.noel(a)tutanota.com (Philippe Noel) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The issue looks like https://bugs.ruby-lang.org/issues/20060 With the new release of ruby 3.1.1, bootsnap does not work anymore. ``` bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." ^^^^^^^^^^ /usr/local/bundle/gems/bootsnap-1.18.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require' ``` It's working with DISABLE_BOOTSNAP=1 with the following message : `warning: parser/current is loading parser/ruby33, which recognizes 3.3.0-compliant syntax, but you are running 3.3.1.` -- https://bugs.ruby-lang.org/

1 week, 1 day

5
7
0 0

[ruby-core:116802] [Ruby master Misc#20272] Ambiguity around Ractor message sending FIFO semantics

by forthoney (Seong-Heon Jung)

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/

1 week, 2 days

2
1
0 0

[ruby-core:117727] [Ruby master Bug#20459] Ractor.select() deadlock?

by esad (Esad Hajdarevic)

Issue #20459 has been reported by esad (Esad Hajdarevic). ---------------------------------------- Bug #20459: Ractor.select() deadlock? https://bugs.ruby-lang.org/issues/20459 * Author: esad (Esad Hajdarevic) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin20] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When I run this script ``` echo = Ractor.new { Ractor.receive } Thread.new { puts Ractor.select(echo).inspect } sleep 0.1 echo.send "test" ``` the script never terminates. If I change thread body to ``` Thread.new { puts echo.take.inspect } ``` or introduce a small delay before #select like: ``` Thread.new { sleep 1; puts Ractor.select(echo).inspect } ``` then it works/terminates. -- https://bugs.ruby-lang.org/

1 week, 2 days

2
1
0 0

[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)

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/

1 week, 2 days

3
8
0 0

[ruby-core:117711] [Ruby master Bug#20456] Hash can get stuck marked as iterating through process forking

by blowfishpro (Talia Wong)

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/

1 week, 2 days

4
6
0 0

[ruby-core:117715] [Ruby master Bug#20458] OpensSSL::SSL::SSLContext#min_version= and #max_version no longer accept Symbol values

by postmodern (Hal Brodigan)

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 week, 3 days

1
2
0 0

[ruby-core:117710] [Ruby master Bug#20455] rb_errinfo() inconsistent with $! in the caller Ruby code

by Eregon (Benoit Daloze)

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 week, 3 days

1
1
0 0

[ruby-core:117657] [Ruby master Bug#20447] Ruby 3.3.1 broken on i686

by vo.x (Vit Ondruch)

Issue #20447 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20447: Ruby 3.3.1 broken on i686 https://bugs.ruby-lang.org/issues/20447 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [i686-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ~~~ gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fPIC -m32 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/i386-linux -I/builddir/build/BUILD/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1/enc/unicode/15.0.0 -o time.o -c /builddir/build/BUILD/ruby-3.3.1/time.c make: Leaving directory '/builddir/build/BUILD/ruby-3.3.1/redhat-linux-build' /builddir/build/BUILD/ruby-3.3.1/time.c: In function ‘zone_timelocal’: /builddir/build/BUILD/ruby-3.3.1/time.c:2345:35: error: passing argument 3 of ‘split_second’ from incompatible pointer type [-Wincompatible-pointer-types] 2345 | split_second(tobj->timew, &t, &s); | ^~ | | | wideval_t * {aka long long unsigned int *} /builddir/build/BUILD/ruby-3.3.1/time.c:616:58: note: expected ‘VALUE *’ {aka ‘long unsigned int *’} but argument is of type ‘wideval_t *’ {aka ‘long long unsigned int *’} 616 | split_second(wideval_t timew, wideval_t *timew_p, VALUE *subsecx_p) | ~~~~~~~^~~~~~~~~ make: *** [Makefile:447: time.o] Error 1 make: *** Waiting for unfinished jobs.... make: Entering directory '/builddir/build/BUILD/ruby-3.3.1/redhat-linux-build' ~~~ This is presumably due to #20327 / https://github.com/ruby/ruby/pull/10332. There seems to be medicine in master commit:git|055613fd868a8c94e43893f8c58a00cdd2a81f6d or maybe the whole https://github.com/ruby/ruby/pull/10332, not sure -- https://bugs.ruby-lang.org/

1 week, 3 days

3
5
0 0

2024

2023

2022

ruby-core ----- 2024 ----- May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023 November 2023 October 2023 September 2023 August 2023 July 2023 June 2023 May 2023 April 2023 March 2023 February 2023 January 2023 ----- 2022 ----- December 2022 November 2022

ruby-core