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

[ruby-core:121804] [Ruby Bug#21302] Remove or Fix Set#to_h
by jeremyevans0 (Jeremy Evans) 13 May '25

13 May '25

Issue #21302 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21302: Remove or Fix Set#to_h https://bugs.ruby-lang.org/issues/21302 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When backwards-compatible marshalling support for Set was added in commit:926411171d296859839745a536aa86bc1e18aa76, Set#to_h was added. I'm not sure if intentionally or accidentally (@nobu knows). The method is not backwards compatible with the previous Set#to_h method (Enumerable#to_h), so it should be fixed or removed. Since it is a new method added to a core class, it should be officially approved if we want to keep it. I would prefer removing it. Users that want a `true`-valued hash can use `to_h { [it, true] }` instead of `to_h`. I have submitted a pull request to remove it: https://github.com/ruby/ruby/pull/13247 However, if we want to keep it, we should fix it to be backwards compatible and add tests and documentation. I have submitted a pull request for that as well: https://github.com/ruby/ruby/pull/13248 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122017] [Ruby Bug#21328] Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
by fagrela (Felipe Agrela) 11 May '25

11 May '25

Issue #21328 has been reported by fagrela (Felipe Agrela). ---------------------------------------- Bug #21328: Gem::Ext::BuildError: ERROR: Failed to build gem native extension. https://bugs.ruby-lang.org/issues/21328 * Author: fagrela (Felipe Agrela) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We are facing an issue that starts in 05/03/2025 We have an Azure Devops Pipeline that build and test a project, but in the test step we have the following error: Gem::Ext::BuildError: ERROR: Failed to build gem native extension. C:/hostedtoolcache/windows/Ruby/3.3.8/x64/lib/ruby/gems/3.3.0/gems/ffi-1.16.3/ext/ffi_c '/c/hostedtoolcache/windows/Ruby/3.3.8/x64/lib/ruby/gems/3.3.0/gems/ffi-1.16.3/ext/ffi_c/libffi-x64-mingw-ucrt' 2025-05-08T20:17:16.1292182Z compiling AbstractMemory.c 2025-05-08T20:17:16.1293918Z AbstractMemory.c: In function 'rbffi_AbstractMemory_Init': 2025-05-08T20:17:16.1379827Z AbstractMemory.c(816,49): error G9F317667: passing argument 3 of 'rb_define_method' from [C:\Users\VssAdministrator\.nuget\packages\gcm.msbuild.sdk\8.0.10-platform-debuggi0004\build\Chef\ChefDependencies.proj] [D:\a\1\s\Tests\ChefUnitTests\ChefUnitTests.csproj] 2025-05-08T20:17:16.1382541Z incompatible pointer type [-Wincompatible-pointer-types] 2025-05-08T20:17:16.1384491Z 816 | rb_define_method(classMemory, "put_" #type, memory_put_##type, 2); \ 2025-05-08T20:17:16.1386316Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1388056Z | | 2025-05-08T20:17:16.1389784Z | VALUE (*)(VALUE, VALUE, 2025-05-08T20:17:16.1391627Z VALUE) {aka long long unsigned int (*)(long long unsigned int, long long 2025-05-08T20:17:16.1393395Z unsigned int, long long unsigned int)} 2025-05-08T20:17:16.1395349Z AbstractMemory.c:833:5: note: in expansion of macro 'INT' 2025-05-08T20:17:16.1397142Z 833 | INT(int8); 2025-05-08T20:17:16.1398853Z | ^~~ 2025-05-08T20:17:16.1400582Z In file included from 2025-05-08T20:17:16.1402347Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/internal/anyargs.h:78, 2025-05-08T20:17:16.1404181Z from 2025-05-08T20:17:16.1406077Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/ruby.h:27, 2025-05-08T20:17:16.1407838Z from 2025-05-08T20:17:16.1409590Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby.h:38, 2025-05-08T20:17:16.1411368Z from AbstractMemory.c:40: 2025-05-08T20:17:16.1413229Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/internal/method.h:99:61: 2025-05-08T20:17:16.1415037Z note: expected 'VALUE (*)(void)' {aka 'long long unsigned int (*)(void)'} but 2025-05-08T20:17:16.1417112Z argument is of type 'VALUE (*)(VALUE, VALUE, VALUE)' {aka 'long long unsigned 2025-05-08T20:17:16.1419032Z int (*)(long long unsigned int, long long unsigned int, long long unsigned 2025-05-08T20:17:16.1420785Z int)'} 2025-05-08T20:17:16.1422532Z 99 | void rb_define_method(VALUE klass, const char *mid, VALUE 2025-05-08T20:17:16.1424350Z (*func)(ANYARGS), int arity); 2025-05-08T20:17:16.1427260Z | 2025-05-08T20:17:16.1429021Z ~~~~~~~~^~~~~~~~~~~~~~ 2025-05-08T20:17:16.1430845Z AbstractMemory.c:96:1: note: 'memory_put_int8' declared here 2025-05-08T20:17:16.1432652Z 96 | memory_put_##name(VALUE self, VALUE offset, VALUE value) \ 2025-05-08T20:17:16.1434412Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1436168Z AbstractMemory.c:259:1: note: in expansion of macro 'NUM_OP' 2025-05-08T20:17:16.1438040Z 259 | NUM_OP(int8, int8_t, NUM2INT, INT2NUM, NOSWAP); 2025-05-08T20:17:16.1439757Z | ^~~~~~ 2025-05-08T20:17:16.1446346Z AbstractMemory.c(817,49): error G9F317667: passing argument 3 of 'rb_define_method' from [C:\Users\VssAdministrator\.nuget\packages\gcm.msbuild.sdk\8.0.10-platform-debuggi0004\build\Chef\ChefDependencies.proj] [D:\a\1\s\Tests\ChefUnitTests\ChefUnitTests.csproj] 2025-05-08T20:17:16.1448813Z incompatible pointer type [-Wincompatible-pointer-types] 2025-05-08T20:17:16.1450695Z 817 | rb_define_method(classMemory, "get_" #type, memory_get_##type, 1); \ 2025-05-08T20:17:16.1452471Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1454208Z | | 2025-05-08T20:17:16.1455919Z | VALUE (*)(VALUE, VALUE) 2025-05-08T20:17:16.1457703Z {aka long long unsigned int (*)(long long unsigned int, long long unsigned 2025-05-08T20:17:16.1459434Z int)} 2025-05-08T20:17:16.1461252Z AbstractMemory.c:833:5: note: in expansion of macro 'INT' 2025-05-08T20:17:16.1463024Z 833 | INT(int8); 2025-05-08T20:17:16.1464707Z | ^~~ Any ideas or how can we fix that? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121951] [Ruby Bug#21317] Namespaces leak with object IDs
by fxn (Xavier Noria) 10 May '25

10 May '25

Issue #21317 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21317: Namespaces leak with object IDs https://bugs.ruby-lang.org/issues/21317 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program ```ruby if mod1.object_id == mod2.object_id mod1.constants == mod2.constants end ``` because it may fail for `mod1 = Object; mod2 = ns::Object`, which have the same object ID. -- https://bugs.ruby-lang.org/

3 5

[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