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

[ruby-core:122649] [Ruby Misc#21500] Backport gcc 15 support
by nobu (Nobuyoshi Nakada) 24 Jul '25

24 Jul '25

Issue #21500 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21500: Backport gcc 15 support https://bugs.ruby-lang.org/issues/21500 * Author: nobu (Nobuyoshi Nakada) * Status: Closed ---------------------------------------- commit:b42afa1dbcb Suppress gcc 15 unterminated-string-initialization warnings commit:f1f0cc14cc7 Separate `__has_attribute` from `defined(__has_attribute)` commit:543e3a1896a Cast up `int` instruction code to `VALUE` commit:ed2806117a0 Do not let files depend on a phony target commit:46e4c867374 Detect `clock_gettime` and `clock_getres` for winpthreads -- https://bugs.ruby-lang.org/

4 3

[ruby-core:121835] [Ruby Bug#21310] YJIT optimization causes incorrect is_a? method evaluation
by ravron-hb (Riley Avron) 24 Jul '25

24 Jul '25

Issue #21310 has been reported by ravron-hb (Riley Avron). ---------------------------------------- Bug #21310: YJIT optimization causes incorrect is_a? method evaluation https://bugs.ruby-lang.org/issues/21310 * Author: ravron-hb (Riley Avron) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Our Rails application contains code like the following: ```ruby result = a_proc.call if result.is_a?(Result) && result.nil? puts('This should be impossible') end ``` With YJIT enabled in dev mode and the `yjit-call-threshold` set to 2, the seemingly impossible condition always evaluates to true, and the `puts` is evaluated. If YJIT is disabled, the code behaves as expected: namely, the condition never evaluates to true. If YJIT is enabled but not in dev mode, with the `yjit-call-threshold` is set to 1,500 (as in our original configuration), the error occurs non-deterministically. We originally discovered this issue while updating to Rails 7.2. The following code began to occasionally fail with a `NoMethodError`, complaining that `nil:NilClass` does not define `success?`: ```ruby result = a_proc.call raise ResultRollbackError, result if result.is_a?(Result) && !result.success? ``` `Result` *does* define `success?`, so it seemed impossible that `result.success?` would be invoked unless `result.is_a?(Result)`, and especially impossible that it would be invoked if `result.nil?`. After various debugging, we added the `if` statement shown in the first code block and discovered that YJIT’s optimizations seem to be incorrect. The inability to predict the possible errors this could cause in our application led us to disable YJIT for our entire application while this behavior persists. Unfortunately, we have not been able to reproduce the error in a self-contained case, which I know will make investigation more difficult. That said, we would like to assist in solving it however possible. We would appreciate guidance on how to obtain relevant debugging information, or suggestions on how we might generate a self-contained reproduction of the issue. We would also be willing to consider allowing a Ruby maintainer to review the actual code demonstrating the issue, though we would probably request that they sign an NDA in that case. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:121994] [Ruby Bug#21327] Windows builds seem broken after clock_gettime changes?
by zenspider (Ryan Davis) 24 Jul '25

24 Jul '25

Issue #21327 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21327: Windows builds seem broken after clock_gettime changes? https://bugs.ruby-lang.org/issues/21327 * Author: zenspider (Ryan Davis) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby/actions/workflows/windows.yml not sure how stable windows normally is, but this looks consistent since this commit (5855986) Assigning to nobu to investigate. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121574] [Ruby Bug#21255] Ruby couldn't build with Windows SDK 10.0.26100
by hsbt (Hiroshi SHIBATA) 24 Jul '25

24 Jul '25

Issue #21255 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21255: Ruby couldn't build with Windows SDK 10.0.26100 https://bugs.ruby-lang.org/issues/21255 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I tried to build ruby.exe with Windows SDK 10.0.26100. But it failed with: ``` dmyext.obj dmyenc.obj linking shared-library x64-vcruntime140-ruby350.dll x64-vcruntime140-ruby350.def : error LNK2001: 外部シンボル "Avx2WmemEnabledWeakValue" は未解決です。 dummy.lib : fatal error LNK1120: 1 件の未解決の外部参照 ``` (This message is the japanese edition of VS2019 Ver.16.11.45) I and @nobu faced the same issue at GitHub Actions. ``` x64-vcruntime140-ruby350.def : error LNK2001: unresolved external symbol Avx2WmemEnabledWeakValue ``` https://github.com/nobu/ruby/actions/runs/13630688130/job/38097613034#step:… I resolved this issue to downgrade Windows SDK to 10.0.22261. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122639] [Ruby Bug#21497] building issue when using gcc15, because C23 is default
by liuzx (Liu Z.) 24 Jul '25

24 Jul '25

Issue #21497 has been reported by liuzx (Liu Z.). ---------------------------------------- Bug #21497: building issue when using gcc15, because C23 is default https://bugs.ruby-lang.org/issues/21497 * Author: liuzx (Liu Z.) * Status: Open * ruby -v: 3.2, 3.3, 3.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby/pull/13736 1. for ruby 3.3, 3.4: when compiling using gcc 15 with "-flto -Werror=lto-type-mismatch", ext/io/console/extconf.h will have: > #define HAVE_RB_IO_PATH 1 > #define HAVE_RB_IO_DESCRIPTOR 1 > #define HAVE_RB_IO_GET_WRITE_IO 1 > #define HAVE_RB_IO_CLOSED_P 1 > #define HAVE_RB_IO_OPEN_DESCRIPTOR 1 the build is failed with: > console.c:1417:1: error: static declaration of ‘rb_io_closed_p’ follows non-static declaration > 1417 | rb_io_closed_p(VALUE io) > | ^~~~~~~~~~~~~~ > ../../.././include/ruby/io.h:385:7: note: previous declaration of ‘rb_io_closed_p’ with type ‘VALUE(VALUE)’ {aka ‘long unsigned int(long un signed int)’} > 385 | VALUE rb_io_closed_p(VALUE io); > | ^~~~~~~~~~~~~~ see https://bugs.gentoo.org/945643#c17 for more detail analysis 2. for ruby 3.2, 3.3, 3.4: when enable socks5 support, gcc15 will report: > init.c:573:19: error: too many arguments to function ‘Rconnect’; expected 0, have 3 > 573 | return (VALUE)Rconnect(arg->fd, arg->sockaddr, arg->len); > | ^~~~~~~~ ~~~~~~~ > In file included from init.c:11: > rubysocket.h:294:5: note: declared here > 294 | int Rconnect(); > | ^~~~~~~~ > sockssocket.c:33:9: error: too many arguments to function ‘SOCKSinit’; expected 0, have 1 > 33 | SOCKSinit("ruby"); > | ^~~~~~~~~ ~~~~~~ > In file included from sockssocket.c:11: > rubysocket.h:293:6: note: declared here > 293 | void SOCKSinit(); > | ^~~~~~~~~ -- https://bugs.ruby-lang.org/

4 4

[ruby-core:122638] [Ruby Bug#21496] Fix for gcc-15 `-flto` option
by nobu (Nobuyoshi Nakada) 24 Jul '25

24 Jul '25

Issue #21496 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21496: Fix for gcc-15 `-flto` option https://bugs.ruby-lang.org/issues/21496 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Even no prototype information is available, gcc-15 seems retrieve something when LTO is enabled. As the result, `have_func` method may fail due to the inconsistency between the info and the default old-style declaration. Possible fixes are: * Specify the header file providing its proper prototype. * Add the argument list to the first argument. By the following commits, the extconf.h files generated with `-flto` option became same as without the option. > commit:11fe8b26c14 [ruby/etc] Run `have_func` with the header providing the declarations > commit:134bdf2d34a [ruby/io-console] Run `have_func` with the header providing the declarations > commit:ac72a25a578 [ruby/io-nonblock] Run `have_func` with the header providing the declarations > commit:89031666487 [ruby/io-wait] Run `have_func` with the header providing the declarations > commit:5277ca1431a [ruby/openssl] Run `have_func` with the header providing the declarations > commit:94803fe9e7b [ruby/strscan] Run `have_func` with the header providing the declarations > commit:9d080765cc3 [ruby/json] Run `have_func` with the header providing the declarations -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122086] [Ruby Bug#21337] Using `not` on the RHS of a logical operator becomes valid syntax with Prism
by koic (Koichi ITO) 23 Jul '25

23 Jul '25

Issue #21337 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #21337: Using `not` on the RHS of a logical operator becomes valid syntax with Prism https://bugs.ruby-lang.org/issues/21337 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following syntax behavior differs between Ruby 3.3 (parse.y by default) and Ruby 3.4 (Prism by default). ```ruby if true && not true; end ``` ## Expected In Ruby 3.3 and earlier, the following code results in a syntax error. The default parser is `parse.y`. ```console $ ruby -vce 'if true && not true; end' ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-darwin24] -e:1: syntax error, unexpected `true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) ``` The key point is that `not` is used on the right-hand side of a logical operator. ## Actual When the default parser is switched to Prism, it is accepted as valid syntax with Ruby 3.4+ (Prism by default): ```console $ ruby -vce 'if true && not true; end' ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-darwin24] Syntax OK $ ruby -vce 'if true && not true; end' ruby 3.5.0dev (2025-05-13T02:05:19Z master 9b8c846bdf) +PRISM [x86_64-darwin24] Syntax OK ``` Specifying parse.y causes a syntax error, as before 3.3 (parse.y by default): ```console $ ruby -vce 'if true && not true; end' ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-darwin24] -e:1: syntax error, unexpected `true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) $ ruby --parser=parse.y -vce 'if true && not true; end' ruby 3.5.0dev (2025-05-13T02:05:19Z master 9b8c846bdf) [x86_64-darwin24] -e:1: syntax error, unexpected 'true', expecting '(' if true && not true; end ruby: compile error (SyntaxError) ``` The behavior seen in the parse.y producing a syntax error might be probably the expected one. Any case, it is likely that users would not expect such a discrepancy between parsers. This issue was noticed in the context of the following RuboCop issue: https://github.com/rubocop/rubocop/issues/14177 -- https://bugs.ruby-lang.org/

6 5

[ruby-core:122844] [Ruby Bug#21519] `configure` script in Ruby tarballs should be generated with autoconf 2.72+ for C23 compilers
by stanhu (Stan Hu) 23 Jul '25

23 Jul '25

Issue #21519 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #21519: `configure` script in Ruby tarballs should be generated with autoconf 2.72+ for C23 compilers https://bugs.ruby-lang.org/issues/21519 * Author: stanhu (Stan Hu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The `autoconf` used to generate `configure` in the Ruby source downloads needs to be updated from 2.71 to 2.72 to fix compatibility with C23 compilers, such as GCC 15. This is related to https://bugs.ruby-lang.org/issues/21024, but this is focused on C, not C++, compilation. This is also related to gem compilation issues, such as: * https://github.com/socketry/io-event/issues/136 * https://jira.mongodb.org/browse/RUBY-3675 * https://github.com/cabo/cbor-ruby/issues/27 These gems worked around the problem by using `append_cflags` instead of `CFLAGS`. That fixes the problem because `-std=c99` is omitted entirely, even for `gcc`. However, this masks the problem that for GCC 15, the Ruby headers should include `<stdbool.h>`. If a gem really needed to use an older C version, `append_cflags` would always throw it out in GCC 15 because `bool` is not defined without including that header. As mentioned in https://gcc.gnu.org/gcc-15/porting_to.html#c23, GCC 15 defaults to C23 now: > In C99 and later you can use #include <stdbool.h> which provides definitions of bool, true, and false compatible with C23. The `configure` script checks whether `stdbool.h` is available and defines `HAVE_STDBOOL_H` if it is. However, if I install `ruby 3.4.4` via `mise` with the Docker image `fedora:42`, I see this in the build logs: ``` configure:13530: checking for stdbool.h that conforms to C99 configure:13646: gcc -c -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -O3 -fno-fast-math -ggdb3 conftest.c >&5 conftest.c:103:17: error: #error "bool is not defined" 103 | #error "bool is not defined" | ^~~~~ conftest.c:106:17: error: #error "false is not defined" 106 | #error "false is not defined" | ^~~~~ conftest.c:109:17: error: #error "true is not defined" 109 | #error "true is not defined" | ^~~~~ configure:13646: $? = 1 ``` Attached is the test program used by `configure`: [test-bool.txt](https://github.com/user-attachments/files/21394404/test-bool… It seems that this test is outdated. It needs this `autoconf` fix for C23: https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=6dcecb780a69…. If I install `autoconf` and run this: ``` autoreconf -fiv ./configure ``` Then it works: ``` checking for stdbool.h that conforms to C99 or later... yes ``` If we peek at `https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.4.tar.gz`: ``` # curl -O https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.4.tar.gz # tar xzf ruby-3.4.4.tar.gz # head -3 ruby-3.4.4/configure #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.71. ``` I believe `autoconf` needs to be updated to 2.72. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:122229] [Ruby Bug#21360] Inconsistent Support for `Exception#cause` in `Fiber#raise` and `Thread#raise`
by ioquatix (Samuel Williams) 22 Jul '25

22 Jul '25

Issue #21360 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21360: Inconsistent Support for `Exception#cause` in `Fiber#raise` and `Thread#raise` https://bugs.ruby-lang.org/issues/21360 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The `raise` method supports setting the cause of an exception using the `cause:` keyword, but this behavior does not work as expected when calling `Fiber#raise` or `Thread#raise`, resulting in a `TypeError`. This breaks consistency with `Kernel#raise` and makes it difficult to attach causal chains to exceptions raised from other execution contexts. ## The Problem The following code behaves correctly when using `Kernel#raise`, correctly setting the `cause`: ```ruby cause = RuntimeError.new("cause") begin raise RuntimeError, "boom", cause: cause rescue => error pp error: error, cause: error.cause end ``` Produces: ```ruby {error: #<RuntimeError: boom>, cause: #<RuntimeError: cause>} ``` However, using `Fiber.current.raise` or `Thread.current.raise` with the same arguments produces a `TypeError`: ```ruby begin Fiber.current.raise RuntimeError, "boom", cause: cause rescue => error pp error: error, cause: error.cause end ``` Results in: ```ruby {error: #<TypeError: backtrace must be an Array of String or an Array of Thread::Backtrace::Location>, cause: nil} ``` This occurs because the third argument is incorrectly interpreted as a backtrace, not as keyword arguments. A similar issue occurs with `Thread#raise`. ## Proposed Solution Update `Fiber#raise` and `Thread#raise` to accept and correctly interpret keyword arguments, including `cause:`, in the same manner as `Kernel#raise`. This would restore consistency across all `raise` implementations and allow causal exception chaining regardless of context. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:121060] [Ruby master Feature#21140] Add a method to get the address of certain JIT related functions
by tenderlovemaking (Aaron Patterson) 22 Jul '25

22 Jul '25

Issue #21140 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21140: Add a method to get the address of certain JIT related functions https://bugs.ruby-lang.org/issues/21140 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Feature #21116 extracted RJIT as a gem. But RJIT accesses certain internal functions which it cannot access as a gem. For example it used the `rb_str_bytesize` function, but this symbol is not exported, so we cannot access it (even from a C extension). Instead of exporting these symbols, I would like to propose an API for getting access to their addresses in Ruby. For example ```ruby RubyVM::RJIT.address_of(:rb_str_bytesize) # => 123456 ``` I would like to limit the addresses to [this list](https://github.com/ruby/ruby/blob/f32d5071b7b01f258eb45cf533496d82d5c… which are the ones required by RJIT. -- https://bugs.ruby-lang.org/

7 22