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

[ruby-core:121702] [Ruby Bug#21280] StringIO#set_encoding warns when backed by chilled string literal
by jeremyevans0 (Jeremy Evans) 13 May '25

13 May '25

Issue #21280 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21280: StringIO#set_encoding warns when backed by chilled string literal https://bugs.ruby-lang.org/issues/21280 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `StringIO#set_encoding` changes the underlying string encoding if the string is not frozen, but does not change the underlying string encoding if the string is frozen. In Ruby 3.4, this results in a warning for chilled literal strings: ``` $ ruby34 -w -r stringio -e "StringIO.new('').set_encoding('binary')" -e:1: warning: literal string will be frozen in the future (run with --debug-frozen-string-literal for more information) ``` I believe Ruby should emit this warning only for cases that will break when string literals are frozen. This is not one of those cases, so Ruby should not emit the warning. To avoid emitting the warning, I think `StringIO#set_encoding` should not set the encoding on the underlying string for chilled literal strings. I submitted a pull request to avoid changing the encoding of the underlying string: https://github.com/ruby/stringio/pull/128 However, @rhenium said that he thought the encoding of the underlying string should still be changed, and the warning should be emitted (https://github.com/ruby/stringio/pull/128#issuecomment-2818362875) For some history, before Ruby 2.3, `StringIO#set_encoding` used to always set the encoding of the underlying string. This was changed in #11827, when the encoding was not set on the underlying string if the string was frozen (commit:3e1c01ae463a8c9d8bbe9050251a2538ddb0292f). In https://bugs.ruby-lang.org/issues/11827#note-3, @nurse wrote: > Away from the case and thinking ideal behavior, StringIO should be a view of given source string and set_encoding shouldn't change source encoding. > But I'm not sure that it is worth breaking the compatibility. I think this means that ideally, absent backwards compatibility issues, StringIO#set_encoding should never change the underlying string encoding. In https://bugs.ruby-lang.org/issues/11827#note-4, @shugo gave an example from @nobu that open-uri depends on the current behavior: ```ruby enc = Encoding::ASCII_8BIT unless enc if self.respond_to? :force_encoding self.force_encoding(enc) elsif self.respond_to? :string self.string.force_encoding(enc) else # Tempfile self.set_encoding enc end end ``` However, as `StringIO#string` is defined, this will call `self.string.force_encoding(enc)` and not `self.set_encoding enc`, so I'm not sure why a change to `String#set_encoding` would affect the behavior of this example. @rhenium pointed out that this issue affects `StringIO#binmode` and `StringIO#set_encoding_by_bom` as well as `StringIO#encoding`. How do we want to handle this case? Should this result in a warning (current behavior), or is it safe to avoid changing the encoding of the underlying string for chilled strings (as is done for frozen strings)? -- https://bugs.ruby-lang.org/

4 12

[ruby-core:121745] [Ruby Bug#21286] Windows - MSYS2 just updated to GCC 15.1.0, builds failing
by MSP-Greg (Greg L) 13 May '25

13 May '25

Issue #21286 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21286: Windows - MSYS2 just updated to GCC 15.1.0, builds failing https://bugs.ruby-lang.org/issues/21286 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- MSYS2 just updated to GCC 15.1.0, and the ruby-loco builds failed to compile. See [MinGW](https://github.com/MSP-Greg/ruby-loco/actions/runs/14693708990/job/4… & [UCRT](https://github.com/MSP-Greg/ruby-loco/actions/runs/14693775816/job/41… Also, I compiled mswin locally with the recent VS 'preview' release, and the bug has been fixed. -- https://bugs.ruby-lang.org/

10 14

[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) 12 May '25

12 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) 10 May '25

10 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) 10 May '25

10 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