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

[ruby-core:115512] [Ruby master Bug#20025] Parsing identifiers/constants is case-folding dependent
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20025 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20025: Parsing identifiers/constants is case-folding dependent https://bugs.ruby-lang.org/issues/20025 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When CRuby parses identifiers, it is encoding-dependent. Once the identifier is found, it determines if it starts with a uppercase or lowercase codepoint. This determines if the identifier is a constant or not. The function is charge of this is `rb_sym_constant_char_p`. For non-unicode encodings where the leading byte has the top-bit set, this relies on onigmo's `mbc_case_fold` to determine if it is a constant or not (as opposed to `is_code_ctype`). This works for almost every single codepoint in every encoding, but has one very weird edge case. In the Windows-1253 encoding for the 0xB5 byte, it's the micro sign. The micro sign, when case folded, becomes the uppercase mu character, and then the lowercase mu character, or 0xEC. This means that even though 0xB5 reports itself as being a lowercase codepoint, it gets parsed as a constant. This example might make this more clear: ``` ruby class Context < BasicObject def method_missing(name, *) = :identifier def self.const_missing(name) = :constant end encoding = Encoding::Windows_1253 character = 0xB5.chr(encoding) source = "# encoding: #{encoding.name}\n#{character}\n" result = Context.new.instance_eval(source) puts "#{encoding.name} encoding of 0x#{character.ord.to_s(16).upcase}" puts " [[:alpha:]] => #{character.match?(/[[:alpha:]]/)}" puts " [[:alnum:]] => #{character.match?(/[[:alnum:]]/)}" puts " [[:upper:]] => #{character.match?(/[[:upper:]]/)}" puts " [[:lower:]] => #{character.match?(/[[:lower:]]/)}" puts " parsed as #{result}" ``` this results in the output of: ``` Windows-1253 encoding of 0xB5 [[:alpha:]] => true [[:alnum:]] => true [[:upper:]] => false [[:lower:]] => true parsed as constant ``` To be clear, I don't think the case-folding is incorrect here (and @duerst confirms that it is correct). I believe instead that it is incorrect to use case-folding here to determine if a codepoint is uppercase or not. Note that this only impacts this one codepoint in this one encoding, so I don't believe this is actually a large-scale problem. But I found it surprising, and think we should change it. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112301] [Ruby master Bug#19426] Endless `Range#step` of object with `#succ` method does not work
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #19426 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19426: Endless `Range#step` of object with `#succ` method does not work https://bugs.ruby-lang.org/issues/19426 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Consider this `c` object which hash `#succ` method. ```ruby c = Struct.new(:i) do def succ; self.class.new(i+1); end def <=>(other) i <=> other.i;end end.new(0) ``` This `Range#step` works. ```ruby (c..c.succ).step(1) do |d| p d.i # 0, 1 end ``` But it fails on an endless range. ```ruby (c..).step(1) do |d| p d.i break if d.i > 3 end ``` ``` -:3:in `<=>': undefined method `i' for nil:NilClass (NoMethodError) from -:10:in `step' from -:10:in `<main>' ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120637] [Ruby master Bug#21032] `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path
by byroot (Jean Boussier) 13 Mar '25

13 Mar '25

Issue #21032 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21032: `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path https://bugs.ruby-lang.org/issues/21032 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Reproduction script: ```ruby require 'benchmark' $LOAD_PATH << 'relative-path' autoload :FOO, '/tmp/foo.rb' puts Benchmark.realtime { 500_000.times do Object.autoload?(:FOO) end } ``` The above takes 2.5 to 3 seconds on my machine, but just removing `$LOAD_PATH << 'relative-path'` make it complete in 50ms. It's such a stark difference that I think it is a bug, and it cause Zeitwerk, a very popular gem, to be way slower than it should when the load path contains relative paths. I have a patch for it, that passes all tests, but I'd appreciate some eyes on it: https://github.com/ruby/ruby/pull/12562 cc @fxn -- https://bugs.ruby-lang.org/

5 8

[ruby-core:120949] [Ruby master Bug#21129] Backporting strscan fix in Ruby 3.2
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #21129 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21129: Backporting strscan fix in Ruby 3.2 https://bugs.ruby-lang.org/issues/21129 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.7 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- An `strscan` version shipped with Ruby 3.2 (`strscan` v3.0.5) has a bug. It was fixed long time ago in `strscan` v3.0.7 (in https://github.com/ruby/strscan/pull/61) but reported recently again in https://github.com/ruby/strscan/issues/132. Ruby 3.2 AFAIK is still normally supported. So does it make sense to have a new Ruby 3.2.x patch level release with `strscan` v3.0.7? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120232] [Ruby master Misc#20951] Confusing handling of timezone object's `#utc_to_local` results
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #20951 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #20951: Confusing handling of timezone object's `#utc_to_local` results https://bugs.ruby-lang.org/issues/20951 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- I am looking into the timezone object feature (that is supported by various Time class methods) now and I am confused by the current implementation. Specifically, how a time-like object **that is not inherited from the Time class** is handled. A time-like object is returned for instance from the timezone object's `#utc_to_local` method. The documentation states that: > A Time-like object is a container object capable of interfacing with timezone libraries for timezone conversion. Also > The zone value may be an object responding to certain timezone methods, an instance of Timezone and TZInfo for example. And indeed the `TZInfo::Timezone` class works as expected. But when I try to use for time-like objects a brand new class not inherited from Time - it works incorrectly. Let's consider an example with `TZInfo::Timezone`: ```ruby require 'tzinfo' zone = TZInfo::Timezone.get("Europe/Kiev") # UTC+2 time = Time.now.utc puts time.to_i # 1734107333 puts Time.now(in: zone) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time).to_i # 1734107333 ``` And now an example with a brand new class. I make an assumption, that as far as `zone.utc_to_local(time).to_i` doesn't change Unix timestamp (it equals `time.to_i`, that's 1734107333), so in a new class also `#utc_to_local` should return not modified value too. ```ruby TimeObj = Struct.new(:year, :mon, :mday, :hour, :min, :sec, :isdst, :to_i) zone_obj = Object.new def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i) # <=== adjust hours (`hours + 2`) to match "Europe/Kiev" timezone (that's UTC+2) end ``` Unfortunately it produces incorrect result: ```ruby puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0000 <====== wrong UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734107333> puts zone_obj.utc_to_local(time).to_i # 1734107333 <===== the same Unix timestamp ``` So now result time object has wrong utc offset - `+0000` instead of `+0200`. Okey, so probably Unix timestamp should be adjusted as well. Let's check: ```ruby def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i + 2 * 60 * 60) # <===== adjust #to_i as well so it returns timestamp + 2 hours end puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0200 <======= correct UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734114533> puts zone_obj.utc_to_local(time).to_i # 1734114533 <====== different Unix timestamp ``` Now we have correct UTC offset `+0200` despite `zone_obj.utc_to_local(time).to_i` returns not original offset but an adjusted one. I assume the difference is caused by a special treatment of time-like object inherited from the Time class. So its `utc_offset` property is used only. But for all the other classes the `#to_i` is used instead. ```ruby zone.utc_to_local(time).class.ancestors # => [TZInfo::TimeWithOffset, TZInfo::WithOffset, Time, Comparable, Object, PP::ObjectMixin, Kernel, BasicObject] ``` This difference is confusing so I think it makes sense either to document it (I mean to document that `#to_i` should return adjusted value for non-related to Time classes) in case it's intentional or to change behaviour for non-related to Time classes and rely not on `#to_i` to calculate UTC offset but on difference in `sec`/`min`/`hours` values otherwise. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:121093] [Ruby master Bug#21146] VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report
by luke-gru (Luke Gruber) 11 Mar '25

11 Mar '25

Issue #21146 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21146: VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report https://bugs.ruby-lang.org/issues/21146 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- test.rb: ```ruby rs = 100.times.map do Ractor.new do cnt = rand 3 cnt += 1 if cnt.zero? sleep cnt 100.times do |i| if i != 0 && i % 50 == 0 Ractor.fail_assert end end end end ``` ractor.rb: ```ruby def self.fail_assert __builtin_cexpr! %q{ VM_ASSERT(0), Qfalse } end ``` > make run I would like to be able to see the bug report for the first failed assertion, without any output from the other ractors. -- https://bugs.ruby-lang.org/

2 3

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