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

[ruby-core:121118] [Ruby master Feature#21148] Class proposal: IndefiniteNumeric < Numeric
by Student (Nathan Zook) 11 Mar '25

11 Mar '25

Issue #21148 has been reported by Student (Nathan Zook). ---------------------------------------- Feature #21148: Class proposal: IndefiniteNumeric < Numeric https://bugs.ruby-lang.org/issues/21148 * Author: Student (Nathan Zook) * Status: Open ---------------------------------------- Suppose someone deals five cards face down from a regulation poker deck, and we wish to reason about the number of aces. We know that that number is one of zero, one, two, three, or four. Therefore, if someone asks "is this number larger than negative one?", the answer is yes even without ever needing to resolve the actual value. This proposal is inspired by the proposed `Enumerable::Lazy::Length` class of Kevin Newton in response to #21135 The `IndefiniteNumeric` class would serve as a base class for such values. In particular, it relies on a subclass to define `#value`, which returns a definite `Numeric`. ```ruby class IndefiniteNumeric < Numeric def coerce(other) = value.coerce(other) def +(other) = value + other def -(other) = value - other def *(other) = value * other def /(other) = value / other def <=>(other) = value <=> other end ``` It is expected that in particular, `<=>` will be overridden for subclasses where `#value` might be slow to return. Usually, we will know more than just that the value in question is `Numeric`. It seems appropriate have `IndefiniteInteger` and so forth. What is not clear to me is if `IndefiniteInteger` should be a subclass of `IndefiniteNumeric` or of `Integer`. (Such a thing does not appear to be currently possible.) If subclassing cannot be, what about defining `#kind_of?(Integer)` to be `true`? Note: with the length of an `Enumerable` as inspiration, I would argue that an `IndefiniteInteger` might actually value to `Float::INFINITY`, so it should NOT define `<=>` against plus or minus `Float::INFINITY`. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121101] [Ruby master Bug#21147] [Breaking changes or Bug] DateTime Range#to_a behaves different between 3.3.7 and 3.4.1
by jamesst20 (James St-Pierre) 11 Mar '25

11 Mar '25

Issue #21147 has been reported by jamesst20 (James St-Pierre). ---------------------------------------- Bug #21147: [Breaking changes or Bug] DateTime Range#to_a behaves different between 3.3.7 and 3.4.1 https://bugs.ruby-lang.org/issues/21147 * Author: jamesst20 (James St-Pierre) * Status: Open * ruby -v: ruby 3.3.7 (2025-01-15 revision be31f993d7) [arm64-darwin24], ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby a = Time.zone.now.to_date b = Time.zone.now.to_date # Ruby 3.3.7 (a..b).to_a => [Tue, 18 Feb 2025] # Ruby 3.4.1 (a..b).to_a => [] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 11 Mar '25

11 Mar '25

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

5 6

[ruby-core:120817] [Ruby master Bug#21096] Ruby hangs up when compiling for bytecode on AArch64 emulated by QEMU
by midnight (Sarun R) 11 Mar '25

11 Mar '25

Issue #21096 has been reported by midnight (Sarun R). ---------------------------------------- Bug #21096: Ruby hangs up when compiling for bytecode on AArch64 emulated by QEMU https://bugs.ruby-lang.org/issues/21096 * Author: midnight (Sarun R) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello, We are experiencing issues when using [Bootsnap](https://github.com/Shopify/bootsnap) for production container image building, specifically when running `bundle exec bootsnap precompile --gemfile` on an emulated ARM64 environment on AMD64 hosts. Here are more details: * Bootsnap is a Ruby gem for bytecode caching, which speeds up loading times. It achieves this by calling `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.load_from_binary`. * When running `bundle exec bootsnap precompile --gemfile` in the environment described (using QEMU to emulate the AArch64 instruction set), the process can compile and generate some bytecode but eventually hangs. * The hang seems random, occurring at different points during the process. * According to [a Rails GitHub issue](https://github.com/rails/rails/issues/54039), the issue affects both `Docker` and `containerd`, as well as native Linux and macOS environments. * From [a Bootsnap GitHub issue](https://github.com/Shopify/bootsnap/issues/495), the problem likely doesn't occur in Ruby `3.2.6` but appears in later versions. * So far, the common factors observed are: * Emulated ARM64 on AMD64 CPUs (likely using QEMU) * Newer Ruby versions (e.g., 3.3 and 3.4) As a user, I don't have the expertise to debug the issue but am willing to gather more information if provided with sufficient instructions. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:120878] [Ruby master Bug#21112] Type in error message when an incorrect key is used with WeakKeyMap
by andrykonchin (Andrew Konchin) 08 Mar '25

08 Mar '25

Issue #21112 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21112: Type in error message when an incorrect key is used with WeakKeyMap https://bugs.ruby-lang.org/issues/21112 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The `ObjectSpace::WeakKeyMap#[]=` method raises exception when key is either Symbol, Numeric or true/false/nil but error message looks like a bit incorrect: ```ruby m = ObjectSpace::WeakKeyMap.new m[:a] = 1 # 'ObjectSpace::WeakKeyMap#[]=': WeakKeyMap must be garbage collectable (ArgumentError) ``` The error message `WeakKeyMap must be garbage collectable` looks like should be `WeakKeyMap key must be garbage collectable`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120811] [Ruby master Bug#21095] Prefer `uname -n` over `hostname` in tests.
by ioquatix (Samuel Williams) 08 Mar '25

08 Mar '25

Issue #21095 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21095: Prefer `uname -n` over `hostname` in tests. https://bugs.ruby-lang.org/issues/21095 * Author: ioquatix (Samuel Williams) * Status: Closed * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- It turns out that `hostname`, while a defacto standard, is not actually a standard in any official sense. On Linux, it's distributed as part of the `inettools` package, and while generally available on other platforms (BSD, Windows, MacOS), it isn't actually part of any standard. The `name(1)` system call and `uname(2)` command ARE standardised by POSIX and the Open Group, and are included in most base systems without the need to install extra packages (e.g. `inettools` on Linux). As such, I was requested by the Arch Linux Ruby maintainer, to prefer using `uname -n` as they would like to drop the dependency on `inettools`. See <https://gitlab.archlinux.org/archlinux/packaging/packages/inetutils/-/issue…> for more context. I've been asked if this can be back ported to 3.3 and 3.4 and while it's not strictly a bug, it will reduce friction in the distribution channels, so I'd like to propose that we backport to 3.4 and if possible 3.3 too. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:120733] [Ruby master Bug#21046] Backport: TLS fix for ARM64
by nobu (Nobuyoshi Nakada) 08 Mar '25

08 Mar '25

Issue #21046 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21046: Backport: TLS fix for ARM64 https://bugs.ruby-lang.org/issues/21046 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- commit:f7059af50a31a4d27a04ace0beadb60616f3f971 Use no-inline version `rb_current_ec` on Arm64 The TLS across .so issue seems related to Arm64, but not Darwin. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121201] [Ruby master Bug#21162] Regexp casefold mismatch for latin1 supplemental chars
by headius (Charles Nutter) 07 Mar '25

07 Mar '25

Issue #21162 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21162: Regexp casefold mismatch for latin1 supplemental chars https://bugs.ruby-lang.org/issues/21162 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Originally reported to joni repo with a possible fix here: https://github.com/jruby/joni/pull/20 From that PR: > When a character is less than or equal to single byte size (0xff), > yet it takes more than 1 byte in the current encoding, the > case folding code incorrectly put it in bitset instead of code > range. As a result, for utf8 encoding, casefold works incorrectly > on characters in range \u0080 to \u00ff (latin1 supplement). > > Before fix: > > "\u00c2" [\u00e0-\u00e5] returns false > "\u00c2" [\u00e2] returns false > "\u00c2" \u00e2 returns true As a Ruby example: ``` $ ruby -v -e 'p(/[\u00e0-\u00e5]/i =~ "\u00c2")' ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] nil ``` The PR above was rebased in https://github.com/jruby/joni/pull/85. When that patch is incorporated into JRuby, it behaves as expected: ``` $ ruby -v -e 'p(/[\u00e0-\u00e5]/i =~ "\u00c2")' jruby 10.0.0.0-SNAPSHOT (3.4.0) 2025-02-27 c0e5008419 OpenJDK 64-Bit Server VM 21.0.5+11-LTS on 21.0.5+11-LTS +indy +jit [arm64-darwin] 0 ``` This bug may affect other casefold situations. As I am not very familiar with this code in CRuby (other than from maintaining the port in joni) I would like others to evaluate this fix and help find other places it is needed. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:121172] [Ruby master Feature#21157] Comparison operator <>
by lpogic 05 Mar '25

05 Mar '25

Issue #21157 has been reported by lpogic (Łukasz Pomietło). ---------------------------------------- Feature #21157: Comparison operator <> https://bugs.ruby-lang.org/issues/21157 * Author: lpogic (Łukasz Pomietło) * Status: Open ---------------------------------------- I propose introducing a comparison operator *<>* which would give the following results: ```ruby 1 <> 2 # => -1 2 <> 1 # => 1 1 <> 1 # => false 1 <> "a" # => true ``` With the help of the new operator, complex ordering expressions could be written explicitly. For example: ```ruby Point = Struct.new(:x, :y) array = [Point.new(1, 2), Point.new(6, 4), Point.new(2, 2), Point.new(5, 2)] array.sort{|a, b| a.y <> b.y || b.x <> a.x || 0 } # => [#<struct Point x=5, y=2>, #<struct Point x=2, y=2>, #<struct Point x=1, y=2>, #<struct Point x=6, y=4>] ``` The *<>* notation may look familiar to sql users, where it means 'not equal'. Defined in the form given it will retain this meaning to some extent: ```ruby a = b = 1 a_not_equal_b if a <> b a_equal_b unless a <> b ``` -- https://bugs.ruby-lang.org/

5 10

[ruby-core:121193] [Ruby master Bug#21161] Crash when locale is set to Turkish tr_TR.UTF-8
by srbaker (Steven Baker) 04 Mar '25

04 Mar '25

Issue #21161 has been reported by srbaker (Steven Baker). ---------------------------------------- Bug #21161: Crash when locale is set to Turkish tr_TR.UTF-8 https://bugs.ruby-lang.org/issues/21161 * Author: srbaker (Steven Baker) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- TL;DR this bug was reported in our tracker, and I'm pushing it upstream: https://bugzilla.opensuse.org/show_bug.cgi?id=1237861 When the locale is set to `tr_TR.UTF-8`, there is an encoding error. It has been narrowed down specifically to setting `LC_CTYPE`. To reproduce simply run `LC_CTYPE=tr_TR.UTF-8 ruby -e "puts 42"` Example from a fresh 3.4.2 install: ``` shell srbaker@geekopad:~> LC_CTYPE=tr_TR.UTF-8 ruby -e "puts 42" /home/srbaker/.local/share/mise/installs/ruby/3.4.2/lib64/ruby/3.4.0/rubygems.rb:9:in 'Kernel#require': /home/srbaker/.local/share/mise/installs/ruby/3.4.2/lib64/ruby/3.4.0/x86_64-linux/rbconfig.rb:1: unknown or invalid encoding in the magic comment (ArgumentError) > 1 | # encoding: ascii-8bit | ^~~~~~~~~~ 2 | # frozen-string-literal: false 3 | # from /home/srbaker/.local/share/mise/installs/ruby/3.4.2/lib64/ruby/3.4.0/rubygems.rb:9:in '<top (required)>' from <internal:gem_prelude>:2:in 'Kernel#require' from <internal:gem_prelude>:2:in '<internal:gem_prelude>' ``` This reproduces across multiple installs of ruby: from our packages, locally built on both GNU/Linux and macOS. It looks like it's related to some normalisation on lowercase i, which in Turkish appears to produce a lowercase i without a dot, and the string. Details in our bug linked above. -- https://bugs.ruby-lang.org/

3 5