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

[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:120694] [Ruby master Bug#21039] Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks
by Eregon (Benoit Daloze) 24 Jul '25

24 Jul '25

Issue #21039 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks https://bugs.ruby-lang.org/issues/21039 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby def make_counter count = 0 nil.instance_exec do [-> { count }, -> { count += 1 }] end end get, increment = make_counter reader = Thread.new { sleep 0.01 loop do p get.call sleep 0.1 end } writer = Thread.new { loop do increment.call sleep 0.1 end } ractor_thread = Thread.new { sleep 1 Ractor.make_shareable(get) } sleep 2 ``` This prints: ``` 1 2 3 4 5 6 7 8 9 10 10 10 10 10 10 10 10 10 10 10 ``` But it should print 1..20, and indeed it does when commenting out the `Ractor.make_shareable(get)`. This shows a given block/Proc instance is concurrently broken by `Ractor.make_shareable`, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment". It's expected that `Ractor.make_shareable` can `freeze` objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong values being read. I think what should happen instead is that `Ractor.make_shareable` should create a new Proc and mutate that. However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like `Ractor.make_shareable([get])`). So I think one fix would to be to only accept Procs for `Ractor.make_shareable(obj, copy: true)`. FWIW that currently doesn't allow Procs, it gives `<internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError)`. I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with `Ractor.make_shareable`. Instead it could be some new method like `isolated { ... }` or `Proc.isolated { ... }` or `Proc.snapshot_outer_variables { ... }` or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do `Ractor.make_shareable(copy: true)` on outer variables) and possibly also set `self` since that's anyway needed. That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables. Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5 Extracted from https://bugs.ruby-lang.org/issues/21033#note-14 -- https://bugs.ruby-lang.org/

5 14

[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