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

[ruby-core:121956] [Ruby Bug#21321] Namespaces do not support extending mixins
by fxn (Xavier Noria) 10 May '25

10 May '25

Issue #21321 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21321: Namespaces do not support extending mixins https://bugs.ruby-lang.org/issues/21321 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The program ```ruby module M end class C extend M end ``` fails under a namespace with error: ``` 'Kernel#extend': Cannot extend object with refinement (TypeError) ``` -- https://bugs.ruby-lang.org/

3 7

[ruby-core:121954] [Ruby Bug#21319] Namespaces do not support including mixins
by fxn (Xavier Noria) 10 May '25

10 May '25

Issue #21319 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21319: Namespaces do not support including mixins https://bugs.ruby-lang.org/issues/21319 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program ```ruby module M end class C include M end ``` fails under a namespace with error ``` 'Module#include': Cannot include refinement (TypeError) ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121949] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by headius (Charles Nutter) 09 May '25

09 May '25

Issue #15408 has been updated by headius (Charles Nutter). > The question is rather why you want _id2ref to be deprecated I want it removed, actually! 😀 You have seen all the reasons why it is problematic, but on top of all that it was never intended to be an official API in the first place (I'm not sure where but matz said so in some issue somewhere) which is why it's the only method in the API with a single leading underscore. Since this issue was filed, nearly all of my requirements have been met: * object_id is now monotonically increasing. * WeakMap is an official API. * Weakref is implemented in terms of WeakMap rather than _id2ref. * DRb had incorporated a WeakMap implementation. With no further need for _id2ref to exist, and numerous reasons to eliminate it, it's time to start that process. If you need the functionality of _id2ref, just put objects into a WeakMap with object_id as the key. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-113069 * Author: headius (Charles Nutter) * Status: Closed * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121948] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by Dan0042 (Daniel DeLorme) 09 May '25

09 May '25

Issue #15408 has been updated by Dan0042 (Daniel DeLorme). headius (Charles Nutter) wrote in #note-44: > I'd also like to know **why** you want `_id2ref` to stick around. I think that question is backwards. There is no need for any reason to keep existing functionality; backward compatibility should be the default. The question is rather **why** you want `_id2ref` to be deprecated, since the previous reason given was no longer applicable. I don't think the memory usage of the id-to-ref mapping is much of a concern, but I agree that the synchronization issue with Ractors explained in [1] makes it fairly reasonable to deprecate this API. I imagine `_id2ref` *could* be fixed to mostly avoid synchronization by using one lookup table per Ractor + one table for shareable objects, but that sounds like a fairly complex fix and probably not worth the trouble. [1]https://byroot.github.io/ruby/performance/2025/04/26/unlocking-ractors-object-id.html ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-113068 * Author: headius (Charles Nutter) * Status: Closed * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116085] [Ruby master Bug#20165] Ractors moving a Struct breaks beyond the first 3 fields
by codekitchen (Brian Palmer) 09 May '25

09 May '25

Issue #20165 has been reported by codekitchen (Brian Palmer). ---------------------------------------- Bug #20165: Ractors moving a Struct breaks beyond the first 3 fields https://bugs.ruby-lang.org/issues/20165 * Author: codekitchen (Brian Palmer) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Experimenting with Ractors on ruby 3.3.0, and I'm seeing a bug where if you move a struct between ractors, all but the first 3 fields are set to nil. ``` ruby Foo = Struct.new(:a,:b,:c,:d,:e,:f) r = Ractor.new { foo = Foo[0,0,0,0,0,0] p foo Ractor.yield(foo, move: true) } p r.take ``` ``` ❯ ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] ❯ ruby rbug.rb rbug.rb:3: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<struct Foo a=0, b=0, c=0, d=0, e=0, f=0> #<struct Foo a=0, b=0, c=0, d=nil, e=nil, f=nil> ``` This seems specific to moving, if I set `move: false` the struct makes it across OK. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119941] [Ruby master Bug#20897] resolv: not usable across ractors
by chucke (Tiago Cardoso) 09 May '25

09 May '25

Issue #20897 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #20897: resolv: not usable across ractors https://bugs.ruby-lang.org/issues/20897 * Author: chucke (Tiago Cardoso) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Using the `resolv` library in a non-main ractor is impossible, due to DNS resources being memoized in a mutable class variable. [This patch](https://github.com/ruby/resolv/pull/62) fixes it by storing resource information in static variables. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120840] [Ruby master Misc#21100] DevMeeting before or after RubyKaigi2025
by ko1 (Koichi Sasada) 09 May '25

09 May '25

Issue #21100 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #21100: DevMeeting before or after RubyKaigi2025 https://bugs.ruby-lang.org/issues/21100 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2025 will be at Matsuyama, Japan, Apr 16th - 18th. We would like to try to hold a face-to-face dev meeting at Matsuyama. (@matz will also participate!) * Date: 2025/04/15 (Tue.) 16:00-19:00 (The day before RubyKaigi) * Location: Ehime-ken Sogo Shakai Fukushi Kaikan, 3F Training room (in Japanese) 愛媛県総合社会福祉会館3F 研修室 ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please sign up on the doorkeeper page: https://rubyassociation.doorkeeper.jp/events/181721 The meeting will be held in a hackathon event. Please enjoy Ruby hacking with friends if you want before the meeting. Note: Do not forget to register RubyKaigi ticket too (see "[ruby-core:120816] Invitation to RubyKaigi 2025" from Akira). ### Program * 10:00am door open and start the Hackathon event * 3:00pm(?) Matz will arrive * 4:00pm opening and self introduction * 4:30pm discuss topics * 6:00pm closing and free time (closing time is depends on topics) * 7:00pm door close ### Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/04/10. I'll ask Matz which should be discussed on this meeting and reorder them. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:121931] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by byroot (Jean Boussier) 09 May '25

09 May '25

Issue #15408 has been updated by byroot (Jean Boussier). I was hoping for a removal timeline, but alright. I'll merge my PR. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-113041 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112091] [Ruby master Bug#19387] Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor
by luke-gru (Luke Gruber) 08 May '25

08 May '25

Issue #19387 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19387: Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor https://bugs.ruby-lang.org/issues/19387 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do receive # block, the problem is not the termination of the ractor but the starting end ObjectSpace.each_object(IO) { |io| p io # we get no objects } ``` -- https://bugs.ruby-lang.org/

6 8

[ruby-core:121927] [Ruby Bug#21314] Kernel#autoload requires the wrong file (?)
by mame (Yusuke Endoh) 08 May '25

08 May '25

Issue #21314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21314: Kernel#autoload requires the wrong file (?) https://bugs.ruby-lang.org/issues/21314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While discussing #21154 with some people at the dev meeting, I found a weird behavior of `Kernel#autoload` that's hard to explain. I haven't yet looked at it carefully, but I was asked to create a ticket anyway. ```ruby # main.rb autoload :A, "./a" autoload :B, "./b" p A # fires the autoload of A ``` ```ruby # a.rb p :A1 B # fires the autoload of B class A end ``` ```ruby # b.rb p :B1 class B p :B2 p A # expected: requires no file (because a.rb is already being require'ed), and raises a NameError # actual: the autoload of B is fired (not A!), recursively (not no-op!) p :B3 end ``` ``` $ ruby main.rb :A1 :B1 :B2 :B1 # What? :B2 :A1 :A2 :A3 A :B3 b.rb:17:in '<class:B>': uninitialized constant B::A (NameError) ``` By the way, in this case, a.rb and b.rb are considered dependent each other. We need to consider how autoload should behave in this case. If it is the user's responsibility to avoid such a situation, we would like to be able to clearly explain what kind of situation should be avoided. -- https://bugs.ruby-lang.org/

1 0