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

[ruby-core:119401] [Ruby master Bug#20776] [PRISM] Pattern matching syntax error message
by nobu (Nobuyoshi Nakada) 29 Jul '25

29 Jul '25

Issue #20776 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20776: [PRISM] Pattern matching syntax error message https://bugs.ruby-lang.org/issues/20776 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Syntax error is fine, but is really expecting end-of-input there? ``` $ ruby -v -e '1 => $g' ruby 3.4.0dev (2024-10-01T14:59:58Z master 169a5ee99e) +PRISM [arm64-darwin23] -e:1: warning: possibly useless use of a variable in void context -e: -e:1: syntax errors found (SyntaxError) > 1 | 1 => $g | ^~ unexpected global variable, expecting end-of-input | ^~ expected a pattern expression after `=>` 2 | ``` And the line 2 is **not** in the input. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122868] [Ruby Bug#21521] Don't require dummy makefile in `extconf.rb`
by ioquatix (Samuel Williams) 27 Jul '25

27 Jul '25

Issue #21521 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21521: Don't require dummy makefile in `extconf.rb` https://bugs.ruby-lang.org/issues/21521 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On some platforms, no native extensions should be created. Due to limitations in `mkmf`, it is typical to create a dummy makefile that does nothing: https://github.com/search?q=File.write+Makefile+path%3A**%2Fextconf.rb&type… This seems like a bad pattern, I think it would be preferable to just do: ``` # extconf.rb return if build_not_required? require "mkmf" ... create_makefile ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120617] [Ruby master Feature#21028] Method for finding why an object isn't Ractor shareable
by tenderlovemaking (Aaron Patterson) 26 Jul '25

26 Jul '25

Issue #21028 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21028: Method for finding why an object isn't Ractor shareable https://bugs.ruby-lang.org/issues/21028 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- `Ractor.shareable?` is easy to use, but if it returns false I would like to be able to figure out what object is causing the data structure to _not_ be Ractor shareable. The context is that I'm trying to make some complex data structures in Rails deeply frozen. If they are deeply frozen they _should_ be Ractor shareable, but `Ractor.shareable?` is returning `false` and it's hard for me to figure out _why_. I would like a method that would either return all unshareable references, or a method that takes a block and unshareable references are yielded to the block. A method like `Ractor.unshareable_references?` or maybe `Ractor.shareable?(obj) { |not_shareable_obj| }` would be very helpful for discovering why an object is not shareable. Thanks! -- https://bugs.ruby-lang.org/

4 6

[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: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