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

[ruby-core:116516] [Ruby master Bug#20229] Empty keyword splat in array not removed in ARGSPUSH case
by jeremyevans0 (Jeremy Evans) 20 Feb '24

20 Feb '24

Issue #20229 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20229: Empty keyword splat in array not removed in ARGSPUSH case https://bugs.ruby-lang.org/issues/20229 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For the following code: ```ruby a = [] kw = {} [*a, **kw] ``` Ruby 2.0-3.3 return `[{}]`, when the desired result (since 2.7) is `[]`. I discovered this while working on an optimization for the ARGSCAT case, where `[*a, 1, **kw]` allocates two arrays instead of a single array. My optimization fixes that by adding a `pushtoarraykwsplat` instruction as a replacement for `newarraykwsplat`. I've used `pushtoarraykwsplat` in the ARGSPUSH case to fix this bug. My pull request for the bug fix and optimization: https://github.com/ruby/ruby/pull/9766 -- https://bugs.ruby-lang.org/

1 2

[ruby-core:115678] [Ruby master Bug#20055] Ripper seems to skip some checks like `void value expression` and `duplicated variable name`
by tompng (tomoya ishida) 20 Feb '24

20 Feb '24

Issue #20055 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20055: Ripper seems to skip some checks like `void value expression` and `duplicated variable name` https://bugs.ruby-lang.org/issues/20055 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-08T07:01:01Z master f2c84c4884) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These are syntax error ~~~ruby return + return # void value expression 1 in [a, a] # duplicated variable name 1 + (1 => [a, a]) # both ~~~ But Ripper.sexp returns S-expression, not nil ~~~ruby Ripper.sexp 'return + return' # => [:program, [[:return, [:args_add_block, [[:unary, :+@, [:return0]]], false]]]] Ripper.sexp '1 in [a, a]' # => [:program, [[:case, [:@int, "1", [1, 0]], [:in, [:aryptn, nil, [[:var_field, [:@ident, "a", [1, 6]]], [:var_field, [:@ident, "a", [1, 9]]]], nil, nil], nil, nil]]]] Ripper.sexp '1 + (1 => [a, a]) # both' # => [:program, [[:binary, [:@int, "1", [1, 0]], :+, [:paren, [[:case, [:@int, "1", [1, 5]], [:in, [:aryptn, nil, [[:var_field, [:@ident, "a", [1, 11]]], [:var_field, [:@ident, "a", [1, 14]]]], nil, nil], nil, nil]]]]]]] ~~~ -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111965] [Ruby master Bug#19365] Ractors can access non-shareable values through enumerators
by luke-gru (Luke Gruber) 16 Feb '24

16 Feb '24

Issue #19365 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19365: Ractors can access non-shareable values through enumerators https://bugs.ruby-lang.org/issues/19365 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I don't think enumerators should be able to be passed to `Ractor.new` ```ruby obj = Object.new # unshareable value p obj Ractor.new([obj].each) {|f| p f.first }.take ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:112155] [Ruby master Bug#19395] Process forking within non-main Ractor creates child stuck in busy loop
by luke-gru (Luke Gruber) 16 Feb '24

16 Feb '24

Issue #19395 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19395: Process forking within non-main Ractor creates child stuck in busy loop https://bugs.ruby-lang.org/issues/19395 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby def test_fork_in_ractor r2 = Ractor.new do pid = fork do exit Ractor.count end pid end pid = r2.take puts "Process #{Process.pid} waiting for #{pid}" _pid, status = Process.waitpid2(pid) # stuck forever if status.exitstatus != 1 raise "status is #{status.exitstatus}" end end test_fork_in_ractor() ``` $ top # shows CPU usage is high for child process -- https://bugs.ruby-lang.org/

2 5

[ruby-core:115864] [Ruby master Feature#20080] Implement #begin_and_end method on Range
by stuyam (Stuart Yamartino) 15 Feb '24

15 Feb '24

Issue #20080 has been reported by stuyam (Stuart Yamartino). ---------------------------------------- Feature #20080: Implement #begin_and_end method on Range https://bugs.ruby-lang.org/issues/20080 * Author: stuyam (Stuart Yamartino) * Status: Open * Priority: Normal ---------------------------------------- Followup Reference: #20027 This feature request is to implement a method called `#begin_and_end` on `Range` that returns an array of the first and last value stored in a range: ```ruby (1..300).begin_and_end #=> [1, 300] first, last = (300..1).begin_and_end first #=> 300 last #=> 1 ``` I believe this would be a great addition to Ranges as they are often used to pass around a single object used to hold endpoints, and this allows easier retrieval of those endpoints. This would allow easier deconstruction into start and end values using array deconstruction as well as a simpler way to serialize to a more primitive object such as an array for database storage. This implementation was suggested by @mame in my initial feature suggestion regarding range deconstruction: https://bugs.ruby-lang.org/issues/20027 This implementation would work similar to how `#minmax` works where it returns an array of two numbers, however the difference is that `#minmax` doesn't work with reverse ranges as @Dan0042 pointed out in the link above: ```ruby (1..42).minmax #=> [1, 42] (42..1).minmax #=> [nil, nil] ``` -- https://bugs.ruby-lang.org/

9 16

[ruby-core:116220] [Ruby master Bug#20187] Bundled gems at Ruby 3.3
by hsbt (Hiroshi SHIBATA) 15 Feb '24

15 Feb '24

Issue #20187 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20187: Bundled gems at Ruby 3.3 https://bugs.ruby-lang.org/issues/20187 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This ticket is for tracking bundled gems status at Ruby 3.4. I added warnings for bundled gems of Ruby 3.3 at https://bugs.ruby-lang.org/issues/19351 and https://bugs.ruby-lang.org/issues/19776. I started to extract(promote) target libraries to bundled gems. These are: * abbrev * base64 * bigdecimal * csv * drb * getoptlong * mutex_m * nkf * observer * resolv-replace * rinda * syslog -- https://bugs.ruby-lang.org/

2 6

[ruby-core:116435] [Ruby master Misc#20210] Invalid source encoding raises ArgumentError, not SyntaxError
by kddnewton (Kevin Newton) 14 Feb '24

14 Feb '24

Issue #20210 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20210: Invalid source encoding raises ArgumentError, not SyntaxError https://bugs.ruby-lang.org/issues/20210 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I was hoping we could change the error that is raised when an invalid source encoding is found from an ArgumentError to a SyntaxError. First let me say, if this isn't possible for backward compatibility, I understand. Please do not take this as me not caring about backward compatibility. Right now, if you have the script `# encoding: foo\n"bar"`, it will raise an ArgumentError, not a SyntaxError. If there are other syntax errors in the file, there's no way to concat them together to give feedback to the user. If a user wants to consistently handle the errors coming back from a parse, they currently have to rescue ArgumentError and SyntaxError. Ideally it would all be SyntaxError, so we could handle them consistently and append all errors together. -- https://bugs.ruby-lang.org/

6 7

[ruby-core:115991] [Ruby master Bug#20111] `defined?` returns `expression` for assignment operators combined with fully qualified constants
by andrykonchin (Andrew Konchin) 14 Feb '24

14 Feb '24

Issue #20111 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20111: `defined?` returns `expression` for assignment operators combined with fully qualified constants https://bugs.ruby-lang.org/issues/20111 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `defined?` doesn't consider &&=, ||= and other ...= operators as `assignment`: ```ruby defined?(A::B += 1) # => "expression" defined?(A::B &&= true) # => "expression" defined?(A::B ||= true) # => "expression" ``` But consider as `assignment` ordinal assignment: ```ruby defined?(A::B = 1) # => "assignment" ``` Wondering if it's expected behaviour. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116065] [Ruby master Feature#20160] rescue keyword for case expressions
by lloeki (Loic Nageleisen) 14 Feb '24

14 Feb '24

Issue #20160 has been reported by lloeki (Loic Nageleisen). ---------------------------------------- Feature #20160: rescue keyword for case expressions https://bugs.ruby-lang.org/issues/20160 * Author: lloeki (Loic Nageleisen) * Status: Open * Priority: Normal ---------------------------------------- It is frequent to find this piece of hypothetical Ruby code: ``` case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) end ``` What if we need to handle `parse` raising a hypothetical `ParseError`? Currently this can be done in two ways. Either option A, wrapping `case .. end`: ``` begin case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) # ... end rescue ParseError # ... end ``` Or option B, guarding before `case`: ``` begin parsed = parse(input) rescue ParseError # ... end case parsed when Integer then handle_int(parsed) when Float then handle_float(parsed) # ... end ``` The difference between option A and option B is that: - option A `rescue` is not localised to parsing and also covers code following `when` (including calling `===`), `then`, and `else`, which may or may not be what one wants. - option B `rescue` is localised to parsing but moves the definition of the variable (`parsed`) and the call to what is actually done (`parse(input)`) far away from `case`. With option B in some cases the variable needs to be introduced even though it might not be needed in `then` parts (e.g if the call in `case` is side-effectful or its value simply leading to branching decision logic). The difference becomes important when rescued exceptions are more general (e.g `Errno` stuff, `ArgumentError`, etc..), as well as when we consider `ensure` and `else`. I feel like option B is the most sensible one in general. I would like to suggest a new syntax: ``` case (parsed = parse(input)) when Integer then handle_int(parsed) when Float then handle_float(parsed) rescue ParseError # ... rescue ArgumentError # ... else # ... fallthrough for all rescue and when cases ensure # ... called always end ``` If more readability is needed as to what these `rescue` are aimed to handle one could optionally write like this: ``` case (parsed = parse(input)) rescue ParseError # ... rescue ArgumentError # ... when Integer then handle_int(parsed) when Float then handle_float(parsed) ... else # ... ensure # ... end ``` Examples: - A made-up pubsub streaming parser with internal state, abstracting away reading from source: ``` parser = Parser.new(io) loop do case parser.parse # blocks for reading io in chunks rescue StandardError => e if parser.can_recover?(e) # tolerate failure, ignore next else emit_fail(e) end when :integer emit_integer(parser.last) when :float emit_float(parser.last) when :done # e.g EOF reached, IO closed, YAML --- end of doc, XML top-level closed, whatever makes sense emit_done break else parser.rollback # e.g rewinds io, we may not have enough data ensure parser.checkpoint # e.g saves io position for rollback end end ``` - Network handling, extrapolated from [ruby docs](https://ruby-doc.org/stdlib-2.7.1/libdoc/net/http/rdoc/Net/HTTP.html#…: ``` case (response = Net::HTTP.get_response(URI(uri_str)) rescue URI::InvalidURIError # handle URI errors rescue SocketError # handle socket errors rescue # other general errors when Net::HTTPSuccess response when Net::HTTPRedirection then location = response['location'] warn "redirected to #{location}" fetch(location, limit - 1) else response.value ensure @counter += 1 end ``` Credit: the idea initially came to me from [this article](https://inside.java/2023/12/15/switch-case-effect/), and thinking how it could apply to Ruby. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:116315] [Ruby master Misc#20193] DevMeeting-2024-02-14
by mame (Yusuke Endoh) 13 Feb '24

13 Feb '24

Issue #20193 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20193: DevMeeting-2024-02-14 https://bugs.ruby-lang.org/issues/20193 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2024/02/14 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 2024/02/11. 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/

12 15