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

[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:122615] [Ruby Misc#21458] Test 'make install'?
by MSP-Greg (Greg L) 23 Jul '25

23 Jul '25

Issue #21458 has been reported by MSP-Greg (Greg L). ---------------------------------------- Misc #21458: Test 'make install'? https://bugs.ruby-lang.org/issues/21458 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Can `make install` be tested? Two items come to mind: 1. Test that all gems can be required? 2. Check that all gem binstubs are installed and work. Some of the above are being done in ruby-loco and https://github.com/ruby/ruby-dev-builder/blob/master/cli_test.rb. Both of these are cron jobs, they don't run on every commit. A long time ago, I think this was discussed, but it was back when CI was much more limited. It was also mixed in with the idea of running tests from the 'install' folder, rather than the 'build' folder. Maybe a few jobs could be added to check `make install` on the three main OS's (Ubuntu, macOS, Windows)? Lastly, with minimal changes, tests can be run from the install folder, which is what ruby-loco has done for years. Recently, two tests that I believe are skipped here started failing: ``` TestGemRequire#test_realworld_default_gem Line: 471 Expected "" to not be empty. TestGemRequire#test_realworld_upgraded_default_gem Line: 492 <"999.99.9"> expected but was <"/ruby/tmp/test_rubygems_20250628-8920-sifyoe/test_realworld_upgraded_default_gem.rb:3:in '<main>': undefined method 'version' for nil (NoMethodError)">. ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122797] [Ruby Feature#21515] Add `&return` as sugar for `x=my_calculation; return x if x`
by nhorton (Noah Horton) 22 Jul '25

22 Jul '25

Issue #21515 has been reported by nhorton (Noah Horton). ---------------------------------------- Feature #21515: Add `&return` as sugar for `x=my_calculation; return x if x` https://bugs.ruby-lang.org/issues/21515 * Author: nhorton (Noah Horton) * Status: Open ---------------------------------------- Let me preface this by saying I have no marriage to the exact keyword name of `&return`. # Problem It is very common to have an early return in code where you get some initial value and return it if it is non-null. i.e. ``` return my_calculation(input_a, input_b) if my_calculation(input_a, input_b) ``` That form on its own is verbose and one where you need to look at it for a moment to confirm it is the same code on either side of the if. If `my_calculation` is non-trivial at all, it normally gets turned into something with a variable: ``` my_calc = my_calculation(input_a, input_b) return my_calc if my_calc ``` That is now two lines. The worse scenario, however, is if the user did not bother doing that and my_calculation turned out to be expensive (and they did not know it). # Proposal I propose a syntax of `&return my_calculation(input_a, input_b)` where it will evaluate the argument and return it as the result of the method if it is non-nil, otherwise it will continue on. # Alternatives ## Do Nothing There is no way to work around this with rolling your own methods. You can't make a `returnif` method or something yourself since you can't do a return in the caller's scope. ## Different Name The best other name I saw were permutations of `returnif`. The biggest issue I see is the similarity of the following two statements: ``` return if foo returnif foo ``` Those are obviously very, very different statements, but are somewhat similar. However, things like this are common, and the code is still quite distinct on those, so I think it is acceptable. Ultimately, this feels so similar to the safe navigator that using `&` in this context feels appropriate. Thank you all for your consideration. -- https://bugs.ruby-lang.org/

8 8

[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

[ruby-core:121605] [Ruby Bug#21259] The Prism compiler wrongly creates a line number of zero
by mame (Yusuke Endoh) 21 Jul '25

21 Jul '25

Issue #21259 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21259: The Prism compiler wrongly creates a line number of zero https://bugs.ruby-lang.org/issues/21259 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- test.rb ``` TracePoint.new(:line) do |tp| p tp end.enable load "./target.rb" ``` target.rb ``` if true..true end ``` ``` $ ~/work/ruby/local/bin/ruby --parser=prism test.rb #<TracePoint:line test.rb:5> #<TracePoint:line /tmp/reproduce-simplecov-ruby34-bug/target.rb:0> # <=== This lineno should be 1 $ ~/work/ruby/local/bin/ruby --parser=parse.y test.rb #<TracePoint:line test.rb:5> #<TracePoint:line /tmp/reproduce-simplecov-ruby34-bug/target.rb:1> ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122787] [Ruby Bug#21514] Rust deprecation warning building ruby-3.4.5/yjit/src/codegen.rs
by debo (David Bohman) 21 Jul '25

21 Jul '25

Issue #21514 has been reported by debo (David Bohman). ---------------------------------------- Bug #21514: Rust deprecation warning building ruby-3.4.5/yjit/src/codegen.rs https://bugs.ruby-lang.org/issues/21514 * Author: debo (David Bohman) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-darwin16] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I get the following warning when building `ruby-3.4.5` from the tarball release. I am using `rustc-1.88.0`. ``` warning: `extern` declarations without an explicit ABI are deprecated --> ../ruby-3.4.5/yjit/src/codegen.rs:7406:1 | 7406 | extern { | ^^^^^^ help: explicitly specify the "C" ABI: `extern "C"` | = note: `#[warn(missing_abi)]` on by default ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122683] [Ruby Bug#21504] [Ractor] Process.waitpid blocks ractor, new NT doesn't pick up other ractors
by luke-gru (Luke Gruber) 21 Jul '25

21 Jul '25

Issue #21504 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21504: [Ractor] Process.waitpid blocks ractor, new NT doesn't pick up other ractors https://bugs.ruby-lang.org/issues/21504 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following code hangs when run with `RUBY_MAX_CPU=2 make run`: Note: `RUBY_MAX_CPU` is set to 2 so that only 1 non-main ractor can run at once. test.rb: ```ruby rs = [] 2.times do |i| rs << Ractor.new(i) do |i| if i == 0 io = IO.popen("ruby -e 'sleep'") Process.wait(io.pid) # block forever else sleep 1 # make sure first ractor blocks forever first $stderr.puts "Running r #{i}" 100_000.times do [nil] * 1_000 end $stderr.puts "done r #{i}" end end end while rs.size == 2 r, obj = Ractor.select(*rs) rs.delete(r) end ``` The timer thread should create a new NT to compensate for the dedicated task, and the new NT should be able to pick up the other runnable ractor. In contrast, the following works fine: ```ruby rs = [] 2.times do |i| rs << Ractor.new(i) do |i| if i == 0 r, w = IO.pipe r.read(1) # block forever else sleep 1 # make sure first ractor blocks forever first $stderr.puts "Running r #{i}" 100_000.times do [nil] * 1_000 end $stderr.puts "done r #{i}" end end end while rs.size == 2 r, obj = Ractor.select(*rs) rs.delete(r) end ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122562] [Ruby Bug#21448] Random.urandom may fail to fall back to reading /dev/urandom on Linux < 3.17
by rhenium (Kazuki Yamaguchi) 20 Jul '25

20 Jul '25

Issue #21448 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #21448: Random.urandom may fail to fall back to reading /dev/urandom on Linux < 3.17 https://bugs.ruby-lang.org/issues/21448 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Origianlly reported for tmpdir: https://github.com/ruby/tmpdir/issues/50 On Linux, `Random.urandom` is expected to first attempt the `getrandom(2)` syscall (Linux >= 3.17), and fall back to reading from `/dev/urandom` if it is not supported. In Ruby 3.1, commit commit:54c91185c9273b9699693910fa95383c86f2af22 replaced the fallback routine that read from `/dev/urandom` with a call to `getentropy(3)`, if available at compile time. On Linux, glibc 2.25 and musl 1.1.20 started to provide a `getentropy(3)` implementation based on `getrandom(2)`. If Ruby is compiled with such a libc version but run on Linux 3.16 or earlier, both `getrandom()` and `getentropy(3)` fail. As a result, `Random.urandom` becomes unusable, even though `/dev/urandom` is still available. I couldn't find the orignal issue the commit was intended to address, except that it appears to related to macOS. Is there a scenario on macOS where `CCRandomGenerateBytes()` or `SecRandomCopyBytes()` might fail, while `getentropy()` will still succeed? -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII
by ippachi (Kazuya Hatanaka) 19 Jul '25

19 Jul '25

Issue #20009 has been reported by ippachi (Kazuya Hatanaka). ---------------------------------------- Bug #20009: Marshal.load raises exception when load dumped class include non-ASCII https://bugs.ruby-lang.org/issues/20009 * Author: ippachi (Kazuya Hatanaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Reproduction code ```ruby class Cクラス; end Marshal.load(Marshal.dump(Cクラス)) ``` ## Actual result ``` <internal:marshal>:34:in `load': undefined class/module C\xE3\x82\xAF\xE3\x83\xA9\xE3\x82\xB9 (ArgumentError) from marshal.rb:2:in `<main>' ``` ## Expected result Returns `Cクラス` ## Impacted area An exception is raised in Rails under the following conditions * minitest is used with default settings * Parallel execution with parallelize * test class names contain non-ASCII characters The default parallelization uses DRb, and Marshal is used inside DRb. ## Other After trying various things, I thought I could fix it by making `rb_path_to_class` support strings containing non-ASCII characters, but I couldn't find anything more than that. -- https://bugs.ruby-lang.org/

7 13