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

[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:121293] [Ruby master Bug#21181] LoadError in P4Ruby on Windows (MSYS2) After Ruby Security Update
by hjain (Himanshu Jain) 12 Mar '25

12 Mar '25

Issue #21181 has been reported by hjain (Himanshu Jain). ---------------------------------------- Bug #21181: LoadError in P4Ruby on Windows (MSYS2) After Ruby Security Update https://bugs.ruby-lang.org/issues/21181 * Author: hjain (Himanshu Jain) * Status: Open * ruby -v: 3.0.7, 3.1.5, 3.2.4, 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## After updating to Ruby versions 3.0.7, 3.1.5, 3.2.4, and 3.3.1, P4Ruby fails to load with the following error: ***<internal:c:/Ruby/x64/ruby-3.0.7-devkit/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': 126: The specified module could not be found. - C:/build/p4ruby/lib/P4.so (LoadError)** *** This issue started occurring after the release of CVE-2024-27282: Arbitrary memory address read vulnerability with Regex search. The same P4Ruby build worked on earlier Ruby versions but now consistently fails. Environment: * OS: Windows 10/11 * Ruby Versions Affected: 3.0.7, 3.1.5, 3.2.4, 3.3.1 * MSYS2 Version: mingw-w64-x86_64 toolchain * Perforce P4Ruby Version: Latest from source * Compiler Used: x86_64-w64-mingw32-gcc (from MSYS2) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121299] [Ruby master Feature#21182] Add Hash#rename
by calebm (Caleb Meyer) 12 Mar '25

12 Mar '25

Issue #21182 has been reported by calebm (Caleb Meyer). ---------------------------------------- Feature #21182: Add Hash#rename https://bugs.ruby-lang.org/issues/21182 * Author: calebm (Caleb Meyer) * Status: Open ---------------------------------------- Abstract: Implement Hash#rename which takes as arguments a from key and a to key and renames the from key to the new name. Background: One of the most common data transformations for a hash (in my experience) is renaming a single key. You can do this with the existing hash methods (e.g. `hash['new'] = hash.delete('old')` or `hash.transform_keys('old' => 'new')`) but they feel a bit clunky. Proposal: Add a new method to Hash, something like this: ```ruby class Hash # usage { old: 'value' }.rename(:old, to: :new) # => { new: 'value' } def rename(from, to:) transform_keys(from => to) end def rename!(from, to:) transform_keys!(from => to) end end ``` -- https://bugs.ruby-lang.org/

2 1

[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:121276] [Ruby master Bug#21177] Sometimes Ruby can create and delete long paths, but cannot traverse them
by deivid 11 Mar '25

11 Mar '25

Issue #21177 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #21177: Sometimes Ruby can create and delete long paths, but cannot traverse them https://bugs.ruby-lang.org/issues/21177 * Author: deivid (David Rodríguez) * Status: Open * ruby -v: 3.4.2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the GitHub Actions environment provided by `ruby/setup-ruby` with `os: windows-2022`, one can create directories with long names with no issues. Similarly, one can create files inside these directories, and delete these files and directories explicitly without issues. However, one cannot traverse these directories (`Dir.children`), and as a result, one cannot delete these directories recursively. This is a small script to reproduce the problem: ```ruby require "fileutils" longest_possible_component = "b" * 255 # Can create directories with long names FileUtils.mkdir_p "D:/a/#{longest_possible_component}" puts "FileUtils.mkdir_p ok" # Can create files inside them FileUtils.touch "D:/a/#{longest_possible_component}/c" puts "FileUtils.touch ok" # Can delete files inside them File.delete "D:/a/#{longest_possible_component}/c" puts "File.delete ok" # Can delete them Dir.rmdir "D:/a/#{longest_possible_component}" puts 'Dir.rmdir ok' FileUtils.mkdir_p "D:/a/#{longest_possible_component}" FileUtils.touch "D:/a/#{longest_possible_component}/c" Dir.children "D:/a/#{longest_possible_component}" # FileUtils.rm_r "D:/a" raises too ``` It fails with the following output: ``` $ ruby windows-bug.rb <internal:dir>:184:in 'Dir.open': Filename too long @ dir_initialize - D:/a/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (Errno::ENAMETOOLONG) from windows-bug.rb:24:in 'Dir.children' from windows-bug.rb:24:in '<main>' FileUtils.mkdir_p ok FileUtils.touch ok File.delete ok Dir.rmdir ok ``` Note that `FileUtils.rm_rf` does not raise here because it swallows errors (see https://bugs.ruby-lang.org/issues/18784) but fails to remove the directory too due to this bug. Looking at sources, I wonder if the explicit raise of `ENAMETOOLONG` should be removed from here: https://github.com/ruby/ruby/blob/e418ba0928ab96ac645ab42d77af34806d74c20e/…, and let the system calls themselves raise it if really necessary? -- https://bugs.ruby-lang.org/

1 1

[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:121271] [Ruby master Bug#21176] Regression in case-insensitive matching for single-byte encodings
by ima1zumi (Mari Imaizumi) 11 Mar '25

11 Mar '25

Issue #21176 has been reported by ima1zumi (Mari Imaizumi). ---------------------------------------- Bug #21176: Regression in case-insensitive matching for single-byte encodings https://bugs.ruby-lang.org/issues/21176 * Author: ima1zumi (Mari Imaizumi) * Status: Open * ruby -v: ruby 3.5.0dev (2025-02-28T09:32:36Z master db4ea95219) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In Ruby 3.4.2, case-insensitive regex matching (`/i`) worked as expected for single-byte encodings like ISO-8859-x. However, in Ruby 3.5.0dev, characters such as `\u00F3 (ó)` and `\u00D3 (Ó)` are no longer considered equivalent under case-insensitive matching, causing the match to fail. The likely cause is #16145 , which appears to have broken handling of `0x80–0xFF` in single-byte encodings. ## Reproduction ```ruby enc = Encoding::ISO_8859_1 o_acute_lower = "\u00F3".encode(enc) # ó o_acute_upper = "\u00D3".encode(enc) # Ó puts /[x#{o_acute_lower}]/i =~ "abc#{o_acute_upper}" ``` - Ruby 3.4.2: outputs 3 (match successful) - Ruby 3.5.0dev: outputs nil (match fails) - ruby 3.5.0dev (2025-02-28T09:32:36Z master db4ea95219) +PRISM [arm64-darwin24] I will submit PR to fix this. -- https://bugs.ruby-lang.org/

1 1

[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:121277] [Ruby master Bug#21178] Socket fails in Ractor
by getajobmike (Mike Perham) 10 Mar '25

10 Mar '25

Issue #21178 has been reported by getajobmike (Mike Perham). ---------------------------------------- Bug #21178: Socket fails in Ractor https://bugs.ruby-lang.org/issues/21178 * Author: getajobmike (Mike Perham) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I think these structures need to be frozen. ``` /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:1043:in 'Socket::HostnameResolutionStore#get_addrinfo': can not access non-shareable objects in constant Socket::HostnameResolutionStore::PRIORITY_ON_V6 by non-main ractor. (Ractor::IsolationError) from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:724:in 'block in Socket.tcp_with_fast_fallback' from <internal:kernel>:168:in 'Kernel#loop' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:720:in 'Socket.tcp_with_fast_fallback' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp' ``` -- https://bugs.ruby-lang.org/

2 1