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

[ruby-core:116610] [Ruby master Misc#20242] `--parser=prism_without_warning`
by kddnewton (Kevin Newton) 14 Feb '24

14 Feb '24

Issue #20242 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20242: `--parser=prism_without_warning` https://bugs.ruby-lang.org/issues/20242 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I was hoping to add another option to `--parser` which would be `--parser=prism_without_warning`. The issue is that it's making it hard to run the tests/specs that test against the output of stderr. This would do the exact same thing as `--parser=prism` it just wouldn't warn. (The name is derived from `--dump=insns_without_opt`, but I'm okay with anything. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:116696] [Ruby master Bug#20264] Segfault installing RMagick on M1 Mac
by andy＠andyjeffries.co.uk (Andy Jeffries) 14 Feb '24

14 Feb '24

Issue #20264 has been reported by andy(a)andyjeffries.co.uk (Andy Jeffries). ---------------------------------------- Bug #20264: Segfault installing RMagick on M1 Mac https://bugs.ruby-lang.org/issues/20264 * Author: andy(a)andyjeffries.co.uk (Andy Jeffries) * Status: Open * Priority: Normal * ruby -v: 3.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I raised a bug at RMagick, they said to go to pkg-config. I raised a bug there, and they said to raise it here. Hopefully this is the right place... https://github.com/ruby-gnome/pkg-config/issues/24 Simplest reproduction steps (although a full backtrace of a Rails app trying to do it is at the link above): ``` $ docker run -it --platform=linux/arm64 registry.docker.com/library/ruby:3.3-slim bash root@163711a82570:/# apt-get update root@163711a82570:/# apt-get install --no-install-recommends -y build-essential pkg-config libmagickwand-dev root@163711a82570:/# gem install rmagick ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:116631] [Ruby master Bug#20247] net/http/header limits are too low
by dpsi (Darien Imai) 14 Feb '24

14 Feb '24

Issue #20247 has been reported by dpsi (Darien Imai). ---------------------------------------- Bug #20247: net/http/header limits are too low https://bugs.ruby-lang.org/issues/20247 * Author: dpsi (Darien Imai) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) +YJIT [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hello, some of my HTTP tests are failing on Ruby 3.3 due to ArgumentError too long. I am trying to update from Ruby 2.7. I did not see any mention of this change in the net/http changelog, but looking at git history, the limit was added between gem versions 0.3.2 and 0.4.0. https://github.com/ruby/ruby/commit/d8b8294c28a09278de357c26b291abf1b9f3cc5d I send HTTP requests with long header keys in my testing suite. Many webservers such as apache, nginx, IIS permit the total length of HTTP headers to be 8K or longer. Tomcat for example allows 48K. I am trying to send a request with a header key length of 24K. I think the limit of 1K is too low. There was not a clear reason for the change, so I request that it gets reverted. Alternatively the limit could be configurable. The code being affected by the limit was written for Ruby 1.8, so I am surprised such longstanding behaviour was removed without being listed in the changelog. -- https://bugs.ruby-lang.org/

3 3

[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:116738] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by naruse (Yui NARUSE) 14 Feb '24

14 Feb '24

Issue #18576 has been updated by naruse (Yui NARUSE). byroot (Jean Boussier) wrote in #note-33: > I'd like to change `Encoding::BINARY.inspect` from `"#<Encoding:ASCII-8BIT>"` to `"#<Encoding:ASCII-8BIT (BINARY)>"`. > > Would that be acceptable? I agree the idea. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106757 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[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:116729] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by matz (Yukihiro Matsumoto) 14 Feb '24

14 Feb '24

Issue #19117 has been updated by matz (Yukihiro Matsumoto). I am OK with adding method owner. I am against removing quote signs. Matz. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106748 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116728] [Ruby master Feature#16495] Inconsistent quotes in error messages
by matz (Yukihiro Matsumoto) 14 Feb '24

14 Feb '24

Issue #16495 has been updated by matz (Yukihiro Matsumoto). I am positive. I'd say go. We need to experiment anyway. Matz. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106747 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

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

14 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