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

[ruby-core:121829] [Ruby Feature#21308] Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm
by watson1978 (Shizuo Fujita) 13 May '25

13 May '25

Issue #21308 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Feature #21308: Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm https://bugs.ruby-lang.org/issues/21308 * Author: watson1978 (Shizuo Fujita) * Status: Open ---------------------------------------- This is a feature request to replace Ruby's `Float#to_s` implementation with a modern high-performance float-to-string conversion algorithm such as Grisu. Currently, `Float#to_s` in Ruby uses the BSD-derived implementation in [missing/dtoa.c](https://github.com/ruby/ruby/blob/master/missing/dtoa.c). Meanwhile, `json` gem has adopted a Grisu-based implementation in [ruby/json#768](https://github.com/ruby/json/pull/768), it has been improve the performance of float-to-string conversion dramatically. It appears to have brought about a 10 times improvement in performance. However, the improvement is limited to the `json` gem. If we can use the same implementation in `Float#to_s`, it will introduce the improvement in all float-to-string conversion cases. (In additional, it would be better if an API could be added that could be called directly from the C extension library, it will reduce the overhead of the call.) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118467] [Ruby master Feature#20610] Float::INFINITY as IO.select timeout argument
by akr (Akira Tanaka) 13 May '25

13 May '25

Issue #20610 has been reported by akr (Akira Tanaka). ---------------------------------------- Feature #20610: Float::INFINITY as IO.select timeout argument https://bugs.ruby-lang.org/issues/20610 * Author: akr (Akira Tanaka) * Status: Open ---------------------------------------- I propose IO.select accepts Float::INFINITY as a timeout argument. It behaves the same as nil which means IO.select will block indefinitely. Motivation: Currently, the Ruby convention to indicate no timeout is using nil. This practice often forces us to treat the nil case separately. Conceptually, no timeout can be thought of as an infinite timeout. So I propose to accept Float::INFINITY as a timeout. It makes us less conditionals when we need to calculate or compare timeouts. Assume `now` method as follows to read the following examples. ``` def now = Process.clock_gettime(Process::CLOCK_MONOTONIC) ``` Example 1: absolute timeout Sometimes we maintain timeout as an absolute clock. The following method takes a relative timeout as an argument. It invokes IO.select several times and raises if the timeout is reached. Assuming a user must specify a finite timeout, the following definition is possible. ``` # user_timeout is the required argument def method(..., user_timeout) abs_timeout = now + user_timeout loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Consider we need to make user_timeout optional. If user_timeout is not given, no timeout occurs. The implementation is as follows. I think the following implementation is typical. It needs 3 more conditionals than the above. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : nil loop { IO.select(rs, ws, es, user_timeout ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout && (abs_timeout < now) ... } end ``` It is possible to reduce a conditional if we use Float::INFINITY. (`abs_timeout && (abs_timeout < now)` is changed to `abs_timeout < now`) ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, abs_timeout != Float::INFINITY ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout < now ... } end ``` If IO.select accepts Float::INFINITY as a timeout argument (this proposal), we can reduce one more conditional as follows. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Example 2: minimum of timeouts Sometimes we need to choose the minimum of several timeouts. I think many event-driven programs use this strategy to determine the timeout for select function. If "no timeout" is represented as nil, `[t1, t2, t3, ...].compact.min` is the minimum. If "no timeout" is represented as Float::INFINITY, we can remove `compact`: `[t1, t2, t3, ...].min` However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Example 3: maximum of timeouts Sometimes we need to choose the maximum of several timeouts. We encountered this situation with a Happy Eyeballs implementation. There are two timeouts for getaddrinfo and connect. We need to wait the longer timeout because a timeout for one doesn't stop another. Also, we don't ignore results after a timeout as long as the algorithm waits for something. If "no timeout" is represented as nil, `ts = [t1, t2, t3, ...]; ts.include?(nil) ? nil : ts.max` is the maximum. If "no timeout" is represented as Float::INFINITY, we can compute the maximum more easily: `[t1, t2, t3, ...].max` It makes code simpler. However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Several Consideration: Consideration 1: Methods other than IO.select. Several methods take a timeout. An incomplete list of methods is as follows. (I searched rb_time_interval.) - IO.select(rs, ws, es, timeout) - sleep(secs) - TCPSocket.new(connect_timeout:) - io.wait_readable(timeout) - io.wait_writable(timeout) - io.wait_priority(timeout) - mutex.sleep(timeout) Do we want to modify them consistently to accept Float::INFINITY? Consideration 2: C-level API If we want to change the timeout of many methods, we would wish to new C-level API similar to rb_time_interval but can return NULL. Unfortunately, rb_time_interval cannot return NULL because the return type is struct timeval. Note that ext/io/wait/wait.c contains get_timeout function. It seems a good first step for such API. Consideration 3: IEEE 754 dependency. Minor platforms (such as VAX) use non-IEEE 754 floating point numbers without infinity. Note that NetBSD/vax still works. (And there is an emulator, simh). Consideration 4: It seems no major languages accept infinity as select's timeout. I found Perl, Python, and OCaml take a floating point number as a timeout of select function. But they don't accept infinity. -- https://bugs.ruby-lang.org/

3 7

[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) 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:121993] [Ruby Bug#21326] Instruction generation differences between parse.y and prism for `def a(x, ...); b(...); end`
by zenspider (Ryan Davis) 11 May '25

11 May '25

Issue #21326 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21326: Instruction generation differences between parse.y and prism for `def a(x, ...); b(...); end` https://bugs.ruby-lang.org/issues/21326 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: ruby 3.5.0dev * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Diff instructions using: ```sh DUMP="puts RubyVM::InstructionSequence.compile(ARGV.first).disasm.gsub(/^\d+ /, '')" RUBY="def a(x, ...); b(...); end" env -u RUBYOPT \ diff -U99 \ <(./build/ruby -v --parser=parse.y -e "$DUMP" "$RUBY" 2>/dev/null) \ <(./build/ruby -v --parser=prism -e "$DUMP" "$RUBY" 2>/dev/null) ``` shows: ```diff --- /dev/fd/63 2025-05-10 14:46:37 +++ /dev/fd/62 2025-05-10 14:46:37 @@ -1,17 +1,18 @@ -ruby 3.5.0dev (2025-05-10T17:32:21Z master 98667f82d2) +GC [arm64-darwin24] +ruby 3.5.0dev (2025-05-10T17:32:21Z master 98667f82d2) +PRISM +GC [arm64-darwin24] == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,26)> definemethod :a, a ( 1)[Li] putobject :a leave == disasm: #<ISeq:a@<compiled>:1 (1,0)-(1,26)> local table (size: 5, argc: 1 [opts: 0, rest: 1, post: 0, block: 3, kw: -1@-1, kwrest: 2]) [ 5] x@0<Arg> [ 4] "*"@1<AnonRest>[ 3] "**"@2<AnonKwrest>[ 2] "&"@3<Block>[ 1] "..."@4 putself ( 1)[LiCa] getlocal_WC_0 "*"@1 -splatarray false +splatarray true getlocal_WC_0 "**"@2 getblockparamproxy "&"@3, 0 splatkw -send <calldata!mid:b, argc:2, ARGS_SPLAT|ARGS_BLOCKARG|FCALL|KW_SPLAT>, nil +splatkw +send <calldata!mid:b, argc:2, ARGS_SPLAT|ARGS_SPLAT_MUT|ARGS_BLOCKARG|FCALL|KW_SPLAT>, nil leave [Re] ``` PR here: https://github.com/ruby/ruby/pull/13299 goes back to at least 3.4. -- https://bugs.ruby-lang.org/

2 1

[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:121955] [Ruby Bug#21320] Namespaces leak with constant lookup
by fxn (Xavier Noria) 10 May '25

10 May '25

Issue #21320 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21320: Namespaces leak with constant lookup https://bugs.ruby-lang.org/issues/21320 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program ```ruby X = :top class C X = :super end class D < C p X end ``` prints `:super` normally, and `:top` if running under a namespace. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121952] [Ruby Bug#21318] Namespaces leak with permanent names
by fxn (Xavier Noria) 10 May '25

10 May '25

Issue #21318 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21318: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21318 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program: ```ruby Module.nesting ``` The nesting is empty or not depending on whether it is being executed under a namespace. -- https://bugs.ruby-lang.org/

2 2