- ruby-core - ml.ruby-lang.org

[ruby-core:122773] [Ruby Feature#21513] Raise on converting endless range to set
by viralpraxis (Iaroslav Kurbatov) 15 Jul '25

15 Jul '25

Issue #21513 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21513: Raise on converting endless range to set https://bugs.ruby-lang.org/issues/21513 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Converting endless range to array raises: ``` shell ruby -e '(1..).to_a' -e:1:in 'Range#to_a': cannot convert endless range to an array (RangeError) from -e:1:in '<main>' ``` but converting to set does not: ``` shell ruby -e '(1..).to_set # hangs' ``` I think it makes to raise in both cases for consistency. Something like this should do the trick: ``` diff diff --git i/prelude.rb w/prelude.rb index f49cada637..11bfa3fc95 100644 --- i/prelude.rb +++ w/prelude.rb @@ -30,6 +30,10 @@ module Enumerable # Makes a set from the enumerable object with given arguments. # Passing arguments to this method is deprecated. def to_set(*args, &block) + if self.class == Range && self.end.nil? + raise RangeError, "cannot convert endless range to a set" + end + klass = if args.empty? Set else diff --git i/test/ruby/test_range.rb w/test/ruby/test_range.rb index f875c0ab40..27b968641b 100644 --- i/test/ruby/test_range.rb +++ w/test/ruby/test_range.rb @@ -1541,4 +1541,11 @@ def test_overlap? assert_not_operator((1...3), :overlap?, (3..4)) assert_not_operator((...3), :overlap?, (3..)) end + + def test_to_set + assert_equal(Set[], (1..-1).to_set) + assert_equal(Set[1, 2, 3], (1..3).to_set) + + assert_raise(RangeError) { (239..).to_set } + end end ``` If this patch is accepted, I'll open a PR. ``` shell ./ruby -v ruby 3.5.0dev (2025-07-14T20:34:32Z master a6d483971a) +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

8 27

[ruby-core:122782] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #17473 has been updated by Eregon (Benoit Daloze). I have merged https://github.com/ruby/pathname/pull/53, it is clearly better for the maintenance of the gem at least. Now we need to figure out if we want to keep the copy in core in sync with the gem or not (if not it's going to be a "fun" gotcha that the pathname gem is faster than core Pathname). ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114061 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122781] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #17473 has been updated by Eregon (Benoit Daloze). Discussion at https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeeting-2025-07… I am disappointed, https://github.com/ruby/pathname/pull/53 makes the code clearly more maintainable and a lot easier to read, there is no value to have it in C. I don't see much value to have Pathname as a core class, `require "pathname"` is no big deal and since it depends on other gems & stdlib it's awkward. Having a partially-defined Pathname in core (missing some methods) seems the worst outcome. As pathname is already a gem, it also means we'll have two unsynchronized copies of the code, and with enough time maybe subtle behavior differences, this seems something nobody wants. @matz this decision is adding a lot of work to CRuby, and other Ruby implementations. Pathname or most of it should be defined in Ruby, having multiple copies of it in C, Java, Ruby, etc means useless duplication and things will get out of sync needlessly. > @nobu: if Pathname is embeded to the core, I prefer the C implementation to Ruby impl. Why? I see only disadvantages to that. > @ioquatix for the purpose of JIT isn't it better to write more Ruby in Ruby? > @shyouhei nobody wants to JIT a path manipulation. https://github.com/ruby/pathname/pull/53#issuecomment-2989134661 shows the Ruby code is faster than the C extension for Pathname. Even from a performance point of view it's bad to implement Pathname methods in C (for most methods). ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114060 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122742] [Ruby Bug#21512] Socket.tcp_with_fast_fallback('example.com', 80, '127.0.0.1') fails with unknown socket domain: ipv4 (SocketError)
by osyoyu (Daisuke Aritomo) 15 Jul '25

15 Jul '25

Issue #21512 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21512: Socket.tcp_with_fast_fallback('example.com', 80, '127.0.0.1') fails with unknown socket domain: ipv4 (SocketError) https://bugs.ruby-lang.org/issues/21512 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-07-13T04:37:15Z master f03cc0b514) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following code is expected to open a socket bound to the local IPv4 interface, but raises an SocketError. ```ruby require 'socket' Socket.tcp_with_fast_fallback('localhost', 8080, '127.0.0.1') ``` Expected behavior: Returns a `Socket` object Actuai behavior: Causes a SocketError (unknown socket domain: ipv4) I believe this is because Socket.tcp_with_fast_fallback is calling Addrinfo.getaddrinfo with `:ipv4` / `:ipv6` as its third argument, instead of `Socket::AF_INET` / `Socket::AF_INET6`. https://github.com/ruby/ruby/blob/b2a7b7699261d2a4ef8a9d5d38d3fb9dc99c8253/… -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122777] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by deivid 15 Jul '25

15 Jul '25

Issue #17473 has been updated by deivid (David Rodríguez). Would it make sense to make `find`, `fileutils`, and `tmpdir` also builtin, given that `pathname` depends on them? ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114055 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122776] [Ruby Feature#17473] Make Pathname to embedded class of Ruby
by hsbt (Hiroshi SHIBATA) 15 Jul '25

15 Jul '25

Issue #17473 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I made `Pathname` to embedded core class now. * https://github.com/ruby/ruby/pull/13873 * https://github.com/ruby/ruby/pull/13885 * https://github.com/ruby/ruby/pull/13887 `Pathname#find`, `Pathname#mkpath`, `Pathname#rmtree` and `Pathname.mktmpdir` is remained on `lib/pathname.rb`. So, the users need to require `pathname.rb` for that methods. We should migrate them to `pathname_builtin.rb` or `pathname.c` without extra dependencies. ---------------------------------------- Feature #17473: Make Pathname to embedded class of Ruby https://bugs.ruby-lang.org/issues/17473#change-114054 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- pathname is one of most useful utility class of Ruby. I'm happy to use Pathname without require it. Any thought? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122548] [Ruby Bug#21441] SEGV during thread cleanup if profiler calls thread_profiles_frames at wrong time
by luke-gru (Luke Gruber) 14 Jul '25

14 Jul '25

Issue #21441 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21441: SEGV during thread cleanup if profiler calls thread_profiles_frames at wrong time https://bugs.ruby-lang.org/issues/21441 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- During thread cleanup, if a ruby sampling profiler calls `thread_profile_frames` at just the wrong time, the ec's stack is cleared but the CFP still exists on the EC, so `thread_profile_frames` assumes it can walk the stack and crashes. In `rb_ec_clear_vm_stack`, it should set `cfp` to `NULL` before clearing the stack. If during `rc_ec_clear_vm_stack` the process gets a signal and this thread handles it and calls `thread_profile_frames`, the early return check of `if (!cfp)` fails, it continues and crashes in this function. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122516] [Ruby Bug#21437] Date#hash may return different values for equal dates with large years
by Stranger6667 (Dmitry Dygalo) 14 Jul '25

14 Jul '25

Issue #21437 has been reported by Stranger6667 (Dmitry Dygalo). ---------------------------------------- Bug #21437: Date#hash may return different values for equal dates with large years https://bugs.ruby-lang.org/issues/21437 * Author: Stranger6667 (Dmitry Dygalo) * Status: Open * ruby -v: 3.2.8 - 3.4.4 (and older versions too) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Parsing the same date string allocates new large integer objects with different pointer addresses, which then affects the hash value due to `d_lite_hash` behavior. ```ruby require 'date' # Small year - consistent hashes Date.strptime('2024-5-9', '%Y-%m-%d').hash #=> 3287407234087466140 Date.strptime('2024-5-9', '%Y-%m-%d').hash #=> 3287407234087466140 # BUG - Large year - different hashes for identical date strings Date.strptime('3171505571716611468830131104691-5-9', '%Y-%m-%d').hash #=> 3525034678868094350 Date.strptime('3171505571716611468830131104691-5-9', '%Y-%m-%d').hash #=> 2502076152602341316 # Different hash for same date! ``` In [ext/date/date_core.c](https://github.com/ruby/ruby/blob/v3_4_4/ext/date/dat…: ```c static VALUE d_lite_hash(VALUE self) { st_index_t v, h[4]; get_d1(self); h[0] = m_nth(dat); // Could be different for equal large integers // ... v = rb_memhash(h, sizeof(h)); return ST2FIX(v); } ``` Each call to `Date.strptime` with a large year allocates a new large integer for `m_nth(dat)`. The hash function uses this pointer address directly in `rb_memhash`, so equal dates parsed separately get different hashes. This breaks the hash contract that equal objects must have equal hashes. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122523] [Ruby Bug#21440] Cannot create instances of frozen Data subclasses
by jeremyevans0 (Jeremy Evans) 14 Jul '25

14 Jul '25

Issue #21440 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21440: Cannot create instances of frozen Data subclasses https://bugs.ruby-lang.org/issues/21440 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- This fails since Data was added in Ruby 3.2: ```ruby Class.new(Data.define(:a)).freeze.new # can't modify frozen #<Class:#<Class:0x000079cf41253160>>: #<Class:0x000079cf41253160> (FrozenError) ``` Note that the error occurs even before the ArgumentError due to the missing argument to `new`. This doesn't happen on classes created with `Data.define` (only subclasses of those classes): ```ruby Data.define(:a).freeze.new # missing keyword: :a (ArgumentError) ``` -- https://bugs.ruby-lang.org/

4 3