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

[ruby-core:115744] [Ruby master Bug#20065] cannot require "net/smtp" with Ruby3.3.0-rc1 and bundler 2.5.0.dev
by s3fxn (s3 fxn) 19 Dec '23

19 Dec '23

Issue #20065 has been reported by s3fxn (s3 fxn). ---------------------------------------- Bug #20065: cannot require "net/smtp" with Ruby3.3.0-rc1 and bundler 2.5.0.dev https://bugs.ruby-lang.org/issues/20065 * Author: s3fxn (s3 fxn) * Status: Open * Priority: Normal * ruby -v: 3.3.0-rc1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- $ ruby -v ruby 3.3.0rc1 (2023-12-11 master a49643340e) [x86_64-linux] $ bundle -v Bundler version 2.5.0.dev $ bundle init $ bundle add net-smtp $ bundle exec ruby -e 'require "net/smtp"' -e:1: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. $ tail -1 Gemfile gem "net-smtp", "~> 0.4.0" -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115598] [Ruby master Bug#20044] Add runtime flag and environment variable for prism
by HParker (Adam Hess) 19 Dec '23

19 Dec '23

Issue #20044 has been reported by HParker (Adam Hess). ---------------------------------------- Bug #20044: Add runtime flag and environment variable for prism https://bugs.ruby-lang.org/issues/20044 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- To enable prism to be used as the parser when running Ruby code, I would like to add a runtime flag and environment variable that allow it to be enabled. The flags could be, ``` ruby --prism test.rb ``` and the environment variable could be, ``` RUBY_PRISM=1 ruby test.rb ``` Previously implemented here: https://github.com/ruby/ruby/pull/9115, but merged before discussion could happen. Things to be sure to discuss mentioned by @mame, > * What to do with the command-line option when prism becomes the default parser in the future. > ** Just remove it, or leave it as a "do nothing" option? > * What are the appropriate names. > ** In Ruby, not absolutely but the names of features for professional use tend to be long and verbose, while those used by ordinary users tend to be short. > * Whether to print a warning when this mode is used. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:115644] [Ruby master Misc#20046] DevMeeting-2023-12-20
by mame (Yusuke Endoh) 18 Dec '23

18 Dec '23

Issue #20046 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20046: DevMeeting-2023-12-20 https://bugs.ruby-lang.org/issues/20046 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/12/20 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/12/17. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 2

[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) 16 Dec '23

16 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