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

[ruby-core:115776] [Ruby master Bug#20071] Reading code from stdin SEGV's when `--parser=prism`
by eightbitraptor (Matthew Valentine-House) 18 Dec '23

18 Dec '23

Issue #20071 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #20071: Reading code from stdin SEGV's when `--parser=prism` https://bugs.ruby-lang.org/issues/20071 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following examples all SEGV on master. ``` ruby --parser=prism cat test_code.rb | ruby --parser=prism ruby --parser=prism < test_code.rb ``` This is because the prism setup code in `process_options` either assumes that a file has been passed or an explicit string with `-e` and does not handle the case where the input is expected to come from `stdin`. [This PR attempts to address this](https://github.com/ruby/ruby/pull/9282) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:115772] [Ruby master Feature#20070] commas in pattern match
by Dan0042 (Daniel DeLorme) 18 Dec '23

18 Dec '23

Issue #20070 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20070: commas in pattern match https://bugs.ruby-lang.org/issues/20070 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- In pattern matching, `case v; in 1,2,3` is a synonym for `case v; in [1,2,3]` This is the one thing that keeps confusing me, that I haven't been able to get used to. Because I'm used to `case v; when 1,2,3` it feels like `case v; in 1,2,3` should have a similar meaning. So it's possible to omit the square brackets but honestly I don't see much point for that, it just makes it look to me like something it is not. In other words, I feel it would be far more intuitive (at least to me) if ```ruby case v in 1,2,3 ``` was a synonym for ```ruby case v in 1 in 2 in 3 ``` or possibly a synonym for ```ruby case v in (1|2|3) ``` which would make it similar to the syntax in `rescue A, B, C => err` Is it too late to change this? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115582] [Ruby master Bug#20037] ractor related test failure on recent ruby3.3.0dev
by mtasaka (Mamoru Tasaka) 18 Dec '23

18 Dec '23

Issue #20037 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #20037: ractor related test failure on recent ruby3.3.0dev https://bugs.ruby-lang.org/issues/20037 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-03 master d4b1f56f50) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Creating ticket for tracking anyway: With commit:d4b1f56f50 ruby build on Fedora 40 sees test failure as: ``` .... (Up to 105, all of these are "Skipped") 106) Skipped: TestException#test_warn_deprecated_category [/builddir/build/BUILD/ruby-3.3.0-d4b1f56f50/test/ruby/test_exception.rb:1104]: no method to test 107) Skipped: TestException#test_warn_deprecated_backwards_compatibility_category [/builddir/build/BUILD/ruby-3.3.0-d4b1f56f50/test/ruby/test_exception.rb:1096]: no method to test 108) Failure: TestThreadInstrumentation#test_sleeping_inside_ractor [/builddir/build/BUILD/ruby-3.3.0-d4b1f56f50/test/-ext-/thread/test_instrumentation_api.rb:154]: <[:started, :ready, :resumed, :suspended, :ready, :resumed, :suspended, :exited]> expected but was <[:started, :ready, :resumed, :suspended, :ready, :resumed]>. 109) Failure: TestThreadInstrumentation#test_blocking_on_ractor [/builddir/build/BUILD/ruby-3.3.0-d4b1f56f50/test/-ext-/thread/test_instrumentation_api.rb:138]: Expected [] to not be empty?. Finished tests in 774.986093s, 34.2858 tests/s, 10368.6261 assertions/s. 26571 tests, 8035541 assertions, 2 failures, 0 errors, 107 skips ``` commit:715cf9b690 is test successful. There are only 2 commits between these. Github CI also seems to be failing on these 2 commits. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115768] [Ruby master Bug#19012] BasicSocket#recv* methods return an empty packet instead of nil on closed connections
by zverok (Victor Shepelev) 17 Dec '23

17 Dec '23

Issue #19012 has been updated by zverok (Victor Shepelev). Should the docs for [BasicSocket#recv_nonblock](https://docs.ruby-lang.org/en/master/BasicSocket… be updated? Now they state > When recvfrom(2) returns 0, Socket#recv_nonblock returns an empty string as data. The meaning depends on the socket: EOF on TCP, empty packet on UDP, etc. I am not sure whether the change affects all the cases (this thing about datagrams got me confused). Other affected methods don't have a similar clause, but this one seems to directly contradict the implemented behavior now. ---------------------------------------- Bug #19012: BasicSocket#recv* methods return an empty packet instead of nil on closed connections https://bugs.ruby-lang.org/issues/19012#change-105705 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `man recvmsg(2)` states: > Return Value > These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown. But somehow the entire `receiv` family of methods in Ruby seem to interpret `0` as empty string instead of "EOF". ```ruby require 'socket' puts "=== pipes ===" r, w = IO.pipe r.read_nonblock(1, exception: false) # => :wait_readable w.close r.read_nonblock(1, exception: false) # => nil (EOF) puts "=== sockets ====" r, w = UNIXSocket.socketpair r.read_nonblock(1, exception: false) # => :wait_readable r.recvmsg_nonblock(1, exception: false) # => :wait_readable r.recv_nonblock(1, exception: false) # => :wait_readable w.close r.read_nonblock(1, exception: false) # => nil (EOF) r.recvmsg_nonblock(1, exception: false) # => ["", #<Addrinfo: empty-sockaddr SOCK_STREAM>, 128]] r.recvmsg # => ["", #<Addrinfo: empty-sockaddr SOCK_STREAM>, 0]] r.recv_nonblock(1, exception: false) # => "" ``` ### Expected behavior I would expect `recvmsg_nonblock`, `recvmsg`, `recv_nonblock` and `recv` to return `nil` when the connection is closed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115688] [Ruby master Bug#20058] `warning: bigdecimal/util is found in bigdecimal` even if the gem spec has the `add_dependency "bigdecimal"` entry
by yahonda (Yasuo Honda) 16 Dec '23

16 Dec '23

Issue #20058 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #20058: `warning: bigdecimal/util is found in bigdecimal` even if the gem spec has the `add_dependency "bigdecimal"` entry https://bugs.ruby-lang.org/issues/20058 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-08T11:25:04Z master cc9826503d) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `warning: bigdecimal/util is found in bigdecimal` warning since https://github.com/ruby/ruby/commit/cc9826503d989df877adbcd94d39a6ff78d0b785 ### Steps to reproduce - `foo.rb` ``` # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" git_source(:github) { |repo| "https://github.com/#{repo}.git" } gem "rails", github: "rails/rails", branch: "main" end require "active_support" require "minitest/autorun" # https://github.com/minitest/minitest/commit/5f5c2111f36658fd2636b108b8327ce… will resolve `warning: mutex_m was loaded from the standard library,` # This require will raise `warning: bigdecimal/util is found in bigdecimal` require "bigdecimal/util" ``` ### Expected behavior No `warning: bigdecimal/util is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.` warnings because Rails has already has `add_dependency "bigdecimal"` https://github.com/rails/rails/blob/main/activesupport/activesupport.gemspe… ### Actual behavior `warning: bigdecimal/util is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.` appears. Note: `warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec.` will be addressed by minitest. ``` $ ruby -v ; ruby foo.rb ruby 3.3.0dev (2023-12-08T11:25:04Z master cc9826503d) [x86_64-linux] Fetching https://github.com/rails/rails.git Resolving dependencies... Fetching gem metadata from https://rubygems.org/.......... /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/bundler/gems/rails-89d8569abe25/activesupport/lib/active_support/core_ext/big_decimal/conversions.rb:4: warning: bigdecimal/util is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 37509 # Running: Finished in 0.001073s, 0.0000 runs/s, 0.0000 assertions/s. 0 runs, 0 assertions, 0 failures, 0 errors, 0 skips $ ``` -- https://bugs.ruby-lang.org/

4 9

[ruby-core:115760] [Ruby master Bug#20068] Strings equality doesn't imply hash equality
by glebpom (Gleb Pomykalov) 15 Dec '23

15 Dec '23

Issue #20068 has been reported by glebpom (Gleb Pomykalov). ---------------------------------------- Bug #20068: Strings equality doesn't imply hash equality https://bugs.ruby-lang.org/issues/20068 * Author: glebpom (Gleb Pomykalov) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It is well-known that the equality of two objects should lead to the equality of their' hashes (https://ruby-doc.org/3.2.2/Object.html#method-i-hash) Empty strings, where one encoding is not ASCII-compatible (UTF-16 in the following example), and another is ASCII-compatible don't follow this rule: ``` irb(main):038:0> l = "" => "" irb(main):039:0> r = l.encode('UTF-16LE') => "" irb(main):040:0> l.hash => 1212370190964414646 irb(main):041:0> r.hash => 1212370190964414642 irb(main):042:0> l.hash == r.hash => false irb(main):043:0> l.eql?(r) => true irb(main):044:0> l => "" irb(main):045:0> r => "" irb(main):046:0> [l,r].uniq => ["", ""] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115759] [Ruby master Feature#18083] Capture error in ensure block.
by Dan0042 (Daniel DeLorme) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by Dan0042 (Daniel DeLorme). > Giving `$!` dynamic scope mitigates the problem but still seems to encourage an approach that @matz has said he was against. Specifically, he was against `ensure => exception` and this is just a variant of that approach. I believe Matz said he was against adding extra **syntax**, and that he was open to experimenting with ko1's proposal. Giving $! dynamic scope is indeed likely to cause subtle bugs, just less than currently. I think that almost all code currently written with `$!` in the ensure clause assume the exception is triggered within the same begin-end block. Using a dynamic scope would "magically" fix all of this currently-incorrect code. So it's a net win. And considering backwards compatibility I think it's unrealistic to consider deprecation. `$!` is used fairly often in gems. I also use it fairly often in my code, usually in some variants of the form `expr rescue $!` ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105697 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115757] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Giving `$!` dynamic scope is equally likely to cause subtle bugs, so no matter what we do here, there is a chance to cause compatibility issues. Deprecation is explicit and gives people a chance to fix the code, which in most cases that I reviewed, is buggy. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105695 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115756] [Ruby master Feature#18083] Capture error in ensure block.
by jeremyevans0 (Jeremy Evans) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by jeremyevans0 (Jeremy Evans). ioquatix (Samuel Williams) wrote in #note-29: > In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". > > If the answer is YES, we should implement it. > > If the answer is NO, we should deprecate and remove `$!`. This perspective ignores backwards compatibility. If the answer is NO, we would still need to determine if the benefit of removing `$!` exceeds the cost of the loss of backwards compatibility. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105694 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115755] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). `$!` is non-trivial to implement - can have performance implications, and dynamic scope might make it more expensive. cc @Eregon @headius can we get your input? Giving `$!` dynamic scope mitigates the problem but still seems to encourage an approach that @matz has said he was against. Specifically, he was against `ensure => exception` and this is just a variant of that approach. In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". If the answer is YES, we should implement it. If the answer is NO, we should deprecate and remove `$!`. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105693 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0