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

[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: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

[ruby-core:121141] [Ruby master Bug#21153] ::Foo ||= p 1 should parse
by qnighy (Masaki Hara) 03 Mar '25

03 Mar '25

Issue #21153 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #21153: ::Foo ||= p 1 should parse https://bugs.ruby-lang.org/issues/21153 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-02-22T15:11:40Z master fd882fb681) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- There is an inconsistency between how `Foo` and `::Foo` are handled: ```console % ./miniruby --parser=parse.y -e "Foo ||= p 1" 1 % ./miniruby --parser=parse.y -e "::Foo ||= p 1" -e:1: syntax error, unexpected integer literal, expecting 'do' or '{' or '(' ::Foo ||= p 1 ./miniruby: compile error (SyntaxError) ``` Note that `Object::Foo` also parses. Prism successfully parses both, which is what I expect. ```console % ./miniruby --parser=prism -e "Foo ||= p 1" 1 % ./miniruby --parser=prism -e "::Foo ||= p 1" 1 ``` To fix this, you should probably handle all tOP_ASGNs in the op_asgn rule. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121090] [Ruby master Bug#21145] Prism accepts newlines in-between curly unicode escape
by kddnewton (Kevin Newton) 03 Mar '25

03 Mar '25

Issue #21145 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21145: Prism accepts newlines in-between curly unicode escape https://bugs.ruby-lang.org/issues/21145 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED ---------------------------------------- For example: ```ruby p "\u{ 61}" ``` -- https://bugs.ruby-lang.org/

2 2