October 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:115051] [Ruby master Feature#16294] Make MatchData frozen and forbid MatchData.allocate
by nobu (Nobuyoshi Nakada) 14 Oct '23

14 Oct '23

Issue #16294 has been updated by nobu (Nobuyoshi Nakada). At the latest dev-meeting, there was a suggestion that whereas `MatchData` cannot be dumped, `Regexp.allocate` might be used by serializer libraries. ---------------------------------------- Feature #16294: Make MatchData frozen and forbid MatchData.allocate https://bugs.ruby-lang.org/issues/16294#change-104925 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal ---------------------------------------- Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`. I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it. Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case. And Marshal can have special treatment to create an initialized MatchData directly. My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places: https://github.com/oracle/truffleruby/pull/1792/files Thoughts? Anyone against? cc @alanwu -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115035] [Ruby master Bug#19926] Range#size returns an incorrect result for ranges with a Rational endpoint
by kyanagi (Kouhei Yanagita) 14 Oct '23

14 Oct '23

Issue #19926 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19926: Range#size returns an incorrect result for ranges with a Rational endpoint https://bugs.ruby-lang.org/issues/19926 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12T17:32:45Z master 81399a5c46) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` % ~/tmp/ruby-master/bin/ruby -e '(1...3.1r).each { p _1 }' 1 2 3 ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (1...3.1r).size' 2 ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (1...3.1).size' 3 ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:115049] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by byroot (Jean Boussier) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by byroot (Jean Boussier). > I wouldn't expect a test framework to rescue OutOfMemoryError for example, Well Minitest does rescue Exception: https://github.com/minitest/minitest/blob/6719ad8d8d49779669083f5029ea9a042… Pretty sure RSpec does as well. It's one of the rare justifiable cases for doing so. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104923 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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:115048] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by tenderlovemaking (Aaron Patterson) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson). byroot (Jean Boussier) wrote in #note-10: > > since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class > > Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly. It is something I would like rescued broadly. For example if I'm test driving a concrete implementation, the test framework needs to specifically rescue `NotImplementedError` in order to report the error. I wouldn't expect a test framework to rescue OutOfMemoryError for example, but definitely rescue NotImplementedError. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104922 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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:115046] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by byroot (Jean Boussier) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by byroot (Jean Boussier). > since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104920 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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:115045] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Quintasan 13 Oct '23

13 Oct '23

Issue #18915 has been updated by Quintasan (Michał Zając). tenderlovemaking (Aaron Patterson) wrote in #note-8: > I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. Hence my proposal to introduce a new class. I didn't want to create a PR for either solution because I would welcome both of them. I'm slightly leaning towards a new exception class for this. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104919 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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:115043] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by tenderlovemaking (Aaron Patterson) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson). I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104917 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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:114782] [Ruby master Bug#19885] Invalid Warning for Default Gems That Will Move to Bundled Gems
by jeremyevans0 (Jeremy Evans) 13 Oct '23

13 Oct '23

Issue #19885 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19885: Invalid Warning for Default Gems That Will Move to Bundled Gems https://bugs.ruby-lang.org/issues/19885 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED ---------------------------------------- Starting in ruby 3.3.0-preview2, attempting to require bigdecimal, mutex_m, base64, or other libraries that will move to bundled gems in Ruby 3.4.0 results in a warning, even when bundler is not in use: ``` $ ruby33 -v -r bigdecimal -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` I think such warnings are bugs if bundler is not in use. When a library is moved from a default gem to a bundled gem, such code will work fine if not using bundler. It is only when using bundler where such code would have problems, and therefore, if Ruby warns at all, it should only warn when bundler is in use. The only time such a warning would make sense if bundler is not in use is if the library was not going to be a bundled gem. In that case, first the library should be moved from a default gem to a bundled gem, then the bundled gem that ships with Ruby should provide the warning, which you can avoid by installing an updated gem version. Note that you also get the warning when loading a gem that has bigdecimal as a runtime dependency (this example uses Sequel 5.72.0, which has a runtime dependency on bigdecimal as you can see at https://rubygems.org/gems/sequel/versions/5.72.0) ``` $ ruby33 -v -r sequel -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] /usr/local/lib/ruby/gems/3.3/gems/sequel-5.72.0/lib/sequel/core.rb:3: warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` This warning makes even less sense, because even if bigdecimal was removed as both a default gem and a bundled gem, installing Sequel 5.72.0 would install bigdecimal as a dependency. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115020] [Ruby master Bug#19923] Ractor / YJIT failures on PPC64LE
by vo.x (Vit Ondruch) 13 Oct '23

13 Oct '23

Issue #19923 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19923: Ractor / YJIT failures on PPC64LE https://bugs.ruby-lang.org/issues/19923 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master e029375a7d) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Let me share snippet of the log: ~~~ ... snip ... + DISABLE_TESTS= + MSPECOPTS= + DISABLE_TESTS=' -n !/TestYJIT#test_bug_19316/' + make -C redhat-linux-build check 'TESTS=-v --show-skip -n !/TestYJIT#test_bug_19316/' 'MSPECOPT=-fs ' make: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' BASERUBY = echo executable host ruby is required. use --with-baseruby option.; false CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -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 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -fPIC -m64 XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/powerpc64le-linux -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/include -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/prism -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/enc/unicode/15.0.0 CPPFLAGS = DLDFLAGS = -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-soname,libruby.so.3.3 -fstack-protector-strong -m64 SOLIBS = -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build/yjit/target/release/' /builddir/build/BUILD/ruby-3.3.0-e029375a7d/yjit/src/lib.rs gcc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. generating enc.mk making srcs under enc make[1]: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' ... snip ... make[1]: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' 2023-10-12 15:27:51 +0000 Driver is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] Target is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] test_attr.rb ... test_autoload.rb ........ test_block.rb .................................................... ...... test_class.rb ................................................ test_constant_cache.rb .......... test_env.rb .. test_eval.rb ........................................ test_exception.rb .................................. test_fiber.rb ..... test_finalizer.rb . test_flip.rb . test_flow.rb .................................................... .......... test_fork.rb .... test_gc.rb .. test_insns.rb .................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ................... test_io.rb .................. test_jump.rb ............................. test_literal.rb .................................................... ............................................................................... ......................... test_literal_suffix.rb ................................................ test_load.rb .. test_marshal.rb . test_massign.rb .................................. test_method.rb .................................................... ............................................................................... ............................................................................... ............. test_objectspace.rb ...... test_proc.rb ..................................... test_ractor.rb .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_7_1222.rb:2:in `<main>' .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_30_1224.rb:2:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_37_1225.rb:2:in `<main>' ... snip ... <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_391_1855.rb:3:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_401_1856.rb:2:in `<main>' .. Finished in 57.56 sec Fiber count: 10000 (skipping) #1222 test_ractor.rb:7: Ractor.new{}.class #=> "" (expected "Ractor") #1224 test_ractor.rb:30: r = Ractor.new name: 'test-name' do end r.name #=> "" (expected "test-name") ... snip ... #1856 test_yjit_rust_port.rb:401: r = Ractor.new do msg = Ractor.receive end r.send 'ok' r.take #=> "" (expected "ok") FAIL 95/1857 tests failed make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' make: *** [uncommon.mk:886: yes-btest-ruby] Error 1 ~~~ The full log is in attachment. ---Files-------------------------------- build.log (1.01 MB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114943] [Ruby master Bug#19910] Set#delete_if behavior inconsistent with Array/Hash
by segiddins (Samuel Giddins) 13 Oct '23

13 Oct '23

Issue #19910 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19910: Set#delete_if behavior inconsistent with Array/Hash https://bugs.ruby-lang.org/issues/19910 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given the following script: ```ruby #!/usr/bin/env ruby require 'set' def enum(collection) i = 0 collection.delete_if do i += 1 raise ArgumentError if i == 6 i.odd? end rescue ArgumentError return collection end pp enum([0, 1, 2, 3, 4, 5, 6, 7]) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_h { [_1, _1] }) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_set) ``` It results in: ``` [1, 3, 5, 6, 7] {1=>1, 3=>3, 5=>5, 6=>6, 7=>7} #<Set: {0, 1, 2, 3, 4, 5, 6, 7}> ``` As you can see, when an exception is raise inside `delete_if` on Hash/Array, the already-considered elements are still removed from the array. For `Set`, no elements are deleted (due to the implementation that builds up an intermediary list of elements to delete, then removes them from the underlying hash afterwards). It would be very helpful if `Set#delete_if` behaved consistently with other core collection types -- https://bugs.ruby-lang.org/

4 3