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

[ruby-core:125684] [Ruby Feature#22102] C API to obtain a C string from a Ruby String
by rhenium (Kazuki Yamaguchi) 07 Jul '26

07 Jul '26

Issue #22102 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Feature #22102: C API to obtain a C string from a Ruby String https://bugs.ruby-lang.org/issues/22102 * Author: rhenium (Kazuki Yamaguchi) * Status: Open ---------------------------------------- Extracted from https://bugs.ruby-lang.org/issues/19315#note-35 It would be nice to have a utility function whose sole purpose is to obtain a C string (NUL-terminated and containing no NUL bytes) from a Ruby String. I suggest adding something like the following to the public C API: ```c /** * Returns a pointer to the string contents as a C string. This checks that the * string does not contain embedded NUL bytes and that it is properly * NUL-terminated. * * @param[in] str String in question. * @exception rb_eArgError String contents include a NUL byte in the middle. * @return Pointer to its contents. * @pre `str` must be an instance of ::RString. */ const char *rb_str_cstr(VALUE str); ``` While extensions can currently use `StringValueCStr(val)`, there are cases where it's inconvenient. - The argument `val` needs to be addressable and modifiable, even if a type conversion is not needed. ```c const char *ptr = StringValueCStr(rb_ary_entry(ary, 0)); // Won't compile ``` - Repeating `StringValue*()` calls on the same object to perform different checks is awkward. ```c // Let's say, `val_a` and `val_b` are passed as an input, and the types are unknown StringValueCStr(val_a); // The result is unusable because the next line can invalidate it const char *b = StringValueCStr(val_b); // `val_b.to_str` can mutate `val_a` const char *a = StringValueCStr(val_a); // So you have to check `val_a` again ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:125963] [Ruby Feature#16757] Add intersection to Range
by Eregon (Benoit Daloze) 07 Jul '26

07 Jul '26

Issue #16757 has been updated by Eregon (Benoit Daloze). I think we should add this, see discussion in #22175. ---------------------------------------- Feature #16757: Add intersection to Range https://bugs.ruby-lang.org/issues/16757#change-117939 * Author: stuyam (Stuart Yamartino) * Status: Open ---------------------------------------- It would be great if there was a way to do an intersection with ranges. I wrote a method recently to solve this but it gets complicated and doesn't solve for all edge cases. The example I was using it for was getting the intersection of two date ranges. I was using it to calculate pricing discounts for overlapping dates for a reservation system. I would propose something like: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)) & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)) => Wed, 15 Apr 2020..Mon, 20 Apr 2020 ``` There are a handful of array methods that you can just convert a range to and do on an arrays rather than the ranges themselves, like so: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)).to_a & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)).to_a => [Wed, 15 Apr 2020, Thu, 16 Apr 2020, Fri, 17 Apr 2020, Sat, 18 Apr 2020, Sun, 19 Apr 2020, Mon, 20 Apr 2020] ``` There are a few issues with this however: 1. Performance: creating the ranges into arrays and doing array calculations can me slower based on the span of the range. 2. Returning a range: if you want to go back to a range, you need to convert the resulting array back to a range, which involves min and maxing the array and handling nil edge cases. 3. Infinite ranges: Now that there are endless and beginless ranges added in ruby 2.6 and 2.7 respectively, you can not convert an infinite range to an array and therefore can't do an intersection without more complex logic. I think the added infinite range support makes it a good reason to add range intersections since that is a feature you can't accomplish with just an array. It looks like there was an [Array#intersection alias](https://bugs.ruby-lang.org/issues/16155) added for Array#& recently. I would propose Range#& and Range#intersection to have parity with Array and Set methods. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125958] [Ruby Misc#22180] Provide official Windows (mswin) binary packages and a version manager
by alanwu (Alan Wu) 07 Jul '26

07 Jul '26

Issue #22180 has been updated by alanwu (Alan Wu). It looks like packaging `vcruntime140.dll` is dubious, because it gets security updates all the time, even if it's not a direct violation of Microsoft's redistribution terms: https://www.quora.com/Am-I-legally-allowed-in-C-Visual-Studio-to-distribute… Curious if you've considered linking with [UCRT](https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-th… instead? If it works, that's one fewer DLL to ship, and one fewer thing to install for users on Windows 10 and up. ---------------------------------------- Misc #22180: Provide official Windows (mswin) binary packages and a version manager https://bugs.ruby-lang.org/issues/22180#change-117932 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Japanese version of this proposal: https://gist.github.com/hsbt/552b01f2aac616af6f8056148407900a ## Background Ruby used to ship official Windows binaries. https://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ still has mswin32 zips from the 1.6 to 1.9-preview era, and they were discontinued around 1.9. One reason is that a bare zip was not usable as a distribution. https://bugs.ruby-lang.org/issues/999 reports that the `ruby-1.9.1-preview1` mswin32 zip was missing the OpenSSL and zlib DLLs, so `gem update` did not work at all. Since then, installing Ruby on Windows has depended on third-party distributions. The mswin platform, which is what `ruby/ruby` CI actually builds and tests with MSVC, has had no end-user distribution at all. https://bugs.ruby-lang.org/issues/19325 shows how the current state is perceived by Windows users. The technical ground has changed. Over the last few months I fixed all the tests that remained broken on mswin myself: `nmake check`, `test-bundler` and `test-bundled-gems` are green now, and `nmake exam`, which runs all of the test suites, completes as well. The build manages its C dependencies with a pinned vcpkg manifest (`vcpkg.json`), and CI covers VS 2022, VS 2026 and `windows-11-arm`. MSVC ABI (`vcruntime140`) has been stable since 2015. The missing piece is distribution, not build quality. Timing also matters. In the era of writing code with AI, the people who need a working Ruby on Windows are increasingly ordinary users who let a coding assistant set up the environment for them, and consumer AI tools operate natively on Windows, not through WSL. An assistant working unattended needs a runtime that installs without elevation and without GUI dialogs, exposes a machine-readable version index, and is relocatable so that installs are deterministic. Unattended provisioning is already the norm in CI (`setup-ruby` exists precisely for this), and AI assistants bring the same requirement to end-user machines. Python reached the same conclusion with PEP 773, described below. Ruby has no official answer to this on Windows today. ## Proposal I propose to provide an official Windows distribution based on the mswin platform, made of three components. All of them, including the test-suite fixes above, are work I implemented and verified myself. Nothing below is a design on paper. **1. `ruby/ruby`: a `binary-package` target.** A new nmake-only target packages the installed tree together with the vcpkg runtime DLLs, the VC runtime and the license terms of everything redistributed into a relocatable zip, with build-machine specific paths scrubbed from `rbconfig.rb`. Thanks to `LOAD_RELATIVE` the tree runs from any location. I will submit the pull request shortly. This is implemented and verified. The package passes a smoke test with `PATH` restricted to `System32` (openssl, fiddle, psych, zlib and RubyGems all work), and C extensions compile with VS Build Tools. In a survey of the 500 most-downloaded gems on rubygems.org forced to build from source, 21 of the 44 gems with a native extension built and loaded. All 23 failures were gem-side or environment-side issues (gcc-only code, POSIX-only source, missing third-party libraries), none caused by the package or by ruby itself, with identical results on 3.3.11, 3.4.10 and 4.0.5. **2. `ruby/actions`: building and publishing.** Automation builds the zips and publishes them together with sha256 checksums: daily builds of master and release builds of the maintained series. Released series (3.3, 3.4, 4.0) are built from their release tarballs with the same packaging script applied externally, so no change to the stable branches is required. This also enables re-packaging revisions (`-1`, `-2`) when a bundled dependency such as OpenSSL needs a security update without a new Ruby release. This part is already working too: in addition to master, zips of 3.3.11, 3.4.10 and 4.0.5 have been built and verified this way, and they are the packages the gem survey above was run on. **3. `rbmanager`: a version manager for Windows.** The same shape as Python's install manager (PEP 773, https://peps.python.org/pep-0773/) A single native executable (the `rb` command) installs a zip from a URL or a local path, extracts it under `%LOCALAPPDATA%`, switches versions with an NTFS junction, and needs one user-level `PATH` entry and no elevation. A working prototype written in C# is already complete and verified on a real machine: ``` > rb install ruby-4.1.0-x64-mswin64_140.zip Extracting ruby-4.1.0-x64-mswin64_140 ... Installed ruby-4.1.0-x64-mswin64_140 > ruby -v ruby 4.1.0dev (2026-06-29T22:22:44Z master 2ce6b8e54a) +PRISM [x64-mswin64_140] > rb list ruby-3.3.11-x64-mswin64_140 ruby-3.4.10-x64-mswin64_140 ruby-4.0.5-x64-mswin64_140 * ruby-4.1.0-x64-mswin64_140 > rb use 4.0 Now using ruby-4.0.5-x64-mswin64_140 > ruby -v ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x64-mswin64_140] ``` The example installs from a local zip today. Once the official version index described below is published, `rb install 4.1` will resolve the version, download the zip and verify its checksum by itself. ## What building on the platform vendor's toolchain enables This proposal is complementary to the existing gcc-based distributions and does not compete with them. Some capabilities are decided by third-party vendors rather than by Ruby, because their SDKs assume the MSVC toolchain and ABI, and those become reachable with an official MSVC-built runtime. Machine-learning runtime assets become directly reusable: the prebuilt Windows packages of ONNX Runtime, libtorch and OpenCV are MSVC binaries with C++ ABIs, and CUDA's `nvcc` accepts only `cl.exe` as its host compiler on Windows, so Ruby extensions binding GPU and ML runtimes need an MSVC-built Ruby to link cleanly. PDB symbols connect Ruby to the standard Windows diagnostics stack: WinDbg and Visual Studio can debug a mixed stack of Ruby and vendor DLLs, WER minidumps from end users become analyzable, and publishing official symbol packages becomes possible for the first time. And extension authors can pull C dependencies from the same vcpkg ecosystem that `ruby/ruby` itself already uses through `vcpkg.json`. ## What I ask to decide First, make these official distribution artifacts: announce them on the www.ruby-lang.org download page and host the zips, checksums and a static version index (the equivalent of pymanager's `index-windows.json`) on ruby-lang.org infrastructure. GitHub Releases can serve as the initial hosting during the preview period. Second, sign the published binaries with a project identity (for example SignPath Foundation issues OSS code-signing certificates) rather than an individual certificate. Third, host `rbmanager` as a repository under the `ruby` organization. The concrete zip layout and naming rule are implementation details. I will work them out with @nobu and document the result in `doc/distribution/windows.md`, so they are not something to decide on this ticket. ## Scope and non-goals This proposal does not replace or deprecate any existing third-party distribution. It adds an official channel for the platform the core team itself builds and tests. I already operate the official snap distribution and the entire release pipeline including security releases, and these artifacts ride on the same automation and the same operator, so this proposal does not change the current maintenance level. Pure-Ruby gems work with no toolchain. Building a C extension requires VS Build Tools, which Microsoft has licensed for building open-source dependencies without a paid Visual Studio license since 2022, and a `ridk`-like bootstrap (`win32/install-buildtools.cmd` is the seed) is follow-up work. Precompiled `x64-mswin64` gems across the ecosystem are long-term work and not a prerequisite. The survey above identified 12 gems that already support Windows with `x64-mingw-ucrt` precompiled binaries and only lack a working MSVC source path, a concrete and small upstream fix list. That list includes nokogiri and ffi, so applications depending on them (Rails, for example) do not work on this distribution yet. The fixes are tractable: I have already verified a one-line fix for msgpack locally and will send these upstream. TLS trust anchors are not bundled in the zip. `rbmanager` provisions certificates from the Windows certificate store at install time, and I will separately propose `OpenSSL::X509::Store#add_store` support for the OpenSSL 3.2+ `org.openssl.winstore://` store in ruby/openssl as the permanent solution. x64 comes first. arm64 (`arm64-mswin64`) already builds in CI and will follow once its test suite is green. ## Roadmap The rollout is incremental rather than tied to a single date. Zips for the released series (3.3, 3.4, 4.0) will be published progressively for their existing releases. For 4.1, nightly zips of master are published continuously, and a zip follows each preview release as soon as it is out. Only the GA of `rbmanager` and the distribution mechanism as a whole is aligned with the Ruby 4.1 release in December. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125796] [Ruby Feature#22121] Introduce Parallel Sweep feature
by luke-gru (Luke Gruber) 07 Jul '26

07 Jul '26

Issue #22121 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22121: Introduce Parallel Sweep feature https://bugs.ruby-lang.org/issues/22121 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Abstract Ruby's GC sweep implementation is currently incremental and lazy. This is to reduce pause times when sweeping. However, the sweep implementation doesn't take advantage of parallelism (multi-core). Sweeping in a GC is not an "embarassingly parallel" problem, but extra threads can help. I would like to introduce such a feature to Ruby so that users can take advantage of their multi-core CPUs to reduce GC pause times. ## Design I would like to have an additional "sweep thread" that sweeps alongside the Ruby GC thread (in parallel) and at the same time as Ruby code is running (concurrent). When the sweep thread is working alongside the Ruby GC thread, both threads grab pages from the current heap. If the sweep thread has already swept a page, the Ruby GC thread finishes it by clearing its bitmaps and adding the page to the free pages or empty pages lists. If there are no swept pages from the sweep thread, the Ruby GC thread sweeps a page by itself instead of waiting for swept pages. When an incremental sweep step is over, the sweep thread sweeps 1 incremental step's budget worth of slots while Ruby code is running. This is so that during the next incremental step, the Ruby GC thread just has to finish the pages off instead of sweeping the objects. ## Limitations Certain objects aren't safe to be freed by the sweep thread. T_DATA types from native extensions cannot be swept in general (although most are safe) because the user's sweep function may not be thread-safe. That function may modify global state in such a way that when it is called from both the sweep thread AND the Ruby GC thread at once, it behaves badly. In order to get around this, we introduce a new [TypedData flag](https://github.com/ruby/ruby/pull/17395). T_DATA internal to the VM mostly have this flag set, and native extension authors can set this flag if it is defined to allow their type to be swept concurrently. This feature is only available for the default GC. Ruby's MMTK garbage collector has its own implementation of concurrent sweeping that is not affected by this feature. This feature is only available for pthread platforms, although that restriction could be lifted with a bit of work. This feature is not on by default (see section `Building`). ## Implementation The [PR](https://github.com/ruby/ruby/pull/17411) is currently a draft, but it's in a working state. Please play with it and tell me what you think! ## Building ```bash ./configure --enable-parallel-sweep make -j ./ruby --enable-parallel-sweep -v #=> ruby 4.1.0dev (2026-06-19T15:49:17Z parallel-sweep cd7e59d45b) +PRISM +Parallel-Sweep [arm64-darwin25] ``` ## Benchmarks This image below is from running [ruby-bench](https://github.com/ruby/ruby-bench) `--headline` benchmarks 10 times and taking the median of means of the runs. The ruby-bench command was: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --headline ``` If you want sweep info per run, you can run it with the GC harness: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --harness=gc --headline ``` <img style="width: 1219px;" src="clipboard-202606191327-7umxq.png"><br> I encourage others to experiment with this feature, run your own benchmarks and share them here. When running your benchmarks, make sure not to pin the process to a CPU with `taskset`, otherwise the sweep thread will not run in parallel. > [!NOTE] > Sometimes there are regressions run to run. Run the benchmark 5-10 times to get more accurate results. > GC micro-benchmarks may not see any improvements or even slight regressions. The implementation targets a workload where there is sufficient time in between sweep steps for the sweep thread to do its work. > [!WARNING] > Benchmarking on MacOS tends to be less accurate than Linux. However, if that's all you have and want to share your results, please do. ## Future Work In the future, I would like it if we could process the metadata of a page in the sweep thread. For example, if we could clear the bitmaps and unlink an empty page, or even add a page to the free pages list then the Ruby pause time would get even smaller (or none at all). I did have a prototype of this, but it caused issues because it was creating too many empty pages too fast, and that had unintended consequences for the rest of the GC. I also believe parallel marking would have a large benefit. Major GCs take a long time due to marking, and if you have lots of threads of fibers than it takes even longer. Marking is a more naturally parallel problem, so would likely benefit from more than 1 worker thread. ---Files-------------------------------- clipboard-202606191327-7umxq.png (342 KB) -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124616] [Ruby Bug#21848] GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete
by henrik (Henrik A) 07 Jul '26

07 Jul '26

Issue #21848 has been reported by henrik (Henrik A). ---------------------------------------- Bug #21848: GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete https://bugs.ruby-lang.org/issues/21848 * Author: henrik (Henrik A) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.1 freezes with 100% CPU usage when garbage collection runs during Rails code reloading (hot reload in development). The process becomes unresponsive and requires kill -9 to terminate. Environment: - Ruby: 4.0.1 (Homebrew, ARM64) - Platform: macOS 15.6.1 (Darwin 24.6.0, Apple Silicon) - Rails: 8.x with Puma 7.2.0 - Mode: Development with code reloading enabled Steps to reproduce: 1. Run a Rails application with Puma in development mode (bundle exec rails server -e development -b 0.0.0.0) 2. Make a several code change to trigger hot reload, reload the site in the browser in between 3. Process freezes with ~100% CPU Expected behavior: Code reloads successfully, GC completes normally. Actual behavior: Process freezes indefinitely at 100% CPU. Stack trace from sample shows GC stuck in hash table lookup while freeing VM call info: ``` gc_sweep (in libruby.4.0.dylib) gc_compact_plane gc_sweep_page gc_sweep_plane rb_gc_obj_free_vm_weak_references rb_vm_ci_free st_general_delete find_table_bin_ind vm_ci_hash_cmp <-- stuck here, spinning ``` Full relevant stack (Puma worker thread): ``` Thread: puma srv tp 005 rb_ary_each -> rb_yield -> invoke_block_from_c_bh -> rb_vm_exec -> int_upto -> rb_yield (nested loops) -> vm_search_method_slowpath0 -> rb_vm_search_method_slowpath -> newobj_of -> newobj_cache_miss -> gc_continue -> gc_sweep -> gc_compact_plane -> gc_sweep_page -> gc_sweep_plane -> rb_gc_obj_free_vm_weak_references -> rb_vm_ci_free -> st_general_delete -> find_table_bin_ind -> vm_ci_hash_cmp ``` Workaround: Disabling auto-compaction prevents the freeze: GC.auto_compact = false Analysis: The freeze occurs during GC sweep/compaction when freeing cached VM call info entries (rb_vm_ci_free). This is triggered by code reloading which invalidates method caches. The GC appears to get stuck in an infinite loop or extremely slow operation in find_table_bin_ind while looking up entries in the call info hash table. ---Files-------------------------------- rails_stuck.txt (159 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125944] [Ruby Bug#22184] error: conflicting types for ‘OnigUChar’; have ‘char16_t’ {aka ‘short unsigned int’} since
by yahonda (Yasuo Honda) 07 Jul '26

07 Jul '26

Issue #22184 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22184: error: conflicting types for ‘OnigUChar’; have ‘char16_t’ {aka ‘short unsigned int’} since https://bugs.ruby-lang.org/issues/22184 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-07T04:45:34Z master 86a6b79e5d) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This issue was found at Rails Nightly CI https://buildkite.com/rails/rails-nightly/builds/4522#019f393b-4212-453f-8f… ### Steps to reproduce 1. Install these packages (this repro uses Ubuntu 26.04) ``` sudo apt-get install -y gcc make libicu-dev ``` 2. Create extconf.rb and repro.c - extconf.rb ``` require "mkmf" create_makefile("repro") ``` - repro.c ``` #include <ruby.h> #include <unicode/uchar.h> ``` 3. Run `ruby.extconf & make` ``` ruby extconf make ``` ### Expected behavior It should pass like: ``` $ ruby extconf.rb && make creating Makefile linking shared-object repro.so ``` ### Actual behavior It raises the ` error: conflicting types for ‘OnigUChar’; have ‘char16_t’ {aka ‘short unsigned int’}` ``` $ ruby extconf.rb creating Makefile $ make compiling repro.c In file included from /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby/internal/core/rregexp.h:30, from /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby/internal/core.h:31, from /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby/ruby.h:29, from /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby.h:38, from repro.c:1: /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby/onigmo.h:76:16: error: conflicting types for ‘OnigUChar’; have ‘char16_t’ {aka ‘short unsigned int’} 76 | # define UChar OnigUChar | ^~~~~~~~~ /home/yahonda/.local/share/mise/installs/ruby/trunk/include/ruby-4.1.0+4/ruby/onigmo.h:79:24: note: previous declaration of ‘OnigUChar’ with type ‘OnigUChar’ {aka ‘unsigned char’} 79 | typedef unsigned char OnigUChar; | ^~~~~~~~~ make: *** [Makefile:251: repro.o] Error 1 $ ``` ### Workaround Setting `CPPFLAGS=-DONIG_ESCAPE_UCHAR_COLLISION` workarounds this error. ```ruby $ ruby -v ruby 4.1.0dev (2026-07-07T04:45:34Z master 86a6b79e5d) +PRISM [x86_64-linux] yahonda@myubuntu:~/src/github.com/yahonda/ruby-head-uchar-repro$ ruby extconf.rb creating Makefile $ make CPPFLAGS=-DONIG_ESCAPE_UCHAR_COLLISION compiling repro.c linking shared-object repro.so $ ``` Reference https://github.com/rails/buildkite-config/pull/187 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125927] [Ruby Bug#22177] Prism rejects a nested destructuring target in a for loop index, while parse.y accepts it
by shugo (Shugo Maeda) 06 Jul '26

06 Jul '26

Issue #22177 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22177: Prism rejects a nested destructuring target in a for loop index, while parse.y accepts it https://bugs.ruby-lang.org/issues/22177 * Author: shugo (Shugo Maeda) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary When the index of a `for` loop is a multiple-assignment target whose first element is itself a parenthesized target (for example `(a, b), c`), Prism reports a syntax error, but parse.y accepts it. The same target works in a normal multiple assignment in both parsers, so the difference is specific to the `for` loop index. ## Reproduction ```ruby for (a, b), c in [[[1, 2], 3]] do p [a, b, c] end ``` ### parse.y (--parser=parse.y) Accepted. Prints: ``` [1, 2, 3] ``` ### Prism (default, --parser=prism) Rejected: ``` > 1 | for (a, b), c in [[[1, 2], 3]] do | ^~~~~ unexpected write target ``` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:125915] [Ruby Bug#22173] `Ractor.new { Fiber.current }.value` raises `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2`
by yahonda (Yasuo Honda) 05 Jul '26

05 Jul '26

Issue #22173 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22173: `Ractor.new { Fiber.current }.value` raises `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2` https://bugs.ruby-lang.org/issues/22173 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This issue is originally found at https://github.com/rails/rails/issues/57954 ### Steps to reproduce 1. Build ruby with `-DRUBY_DEBUG=1` enabled like ``` #!/bin/bash cd ${HOME}/src/github.com/ruby/ruby make clean make distclean make realclean ./autogen.sh ./configure --prefix="${HOME}/.local/share/mise/installs/ruby/trunk" cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" optflags="-O3 -fno-inline" --disable-install-doc make -j"$(getconf _NPROCESSORS_ONLN)" make install ``` 2. Run these one liners ``` ruby -ve 'Ractor.new { Fiber.current }.value' ``` ``` ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ``` ### Expected behavior Both of one liners should pass: ``` $ ruby -ve 'Ractor.new { Fiber.current }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. $ ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. ``` ### Actual behavior Both of them raise the `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2` assertion failures added through https://github.com/ruby/ruby/commit/af2471365fe ``` $ ruby -ve 'Ractor.new { Fiber.current }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. <OBJ_INFO:rb_ractor_confirm_belonging@ractor_core.h:329> 0x000078fa403213d0 fiber/Fiber -e:1: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] ... ``` ``` $ ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. <OBJ_INFO:rb_ractor_confirm_belonging@ractor_core.h:329> 0x00007e56dbe9dfa8 T_OBJECT/Object len:0 capa:2 ptr:0x00007e56dbe9dfb8 -e:1: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] ``` ---Files-------------------------------- 1.out (23.8 KB) 2.out (23.8 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125933] [Ruby Misc#22180] Provide official Windows (mswin) binary packages and a version manager
by hsbt (Hiroshi SHIBATA) 05 Jul '26

05 Jul '26

Issue #22180 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned PoC is here: * https://github.com/ruby/ruby/pull/17662 * https://github.com/ruby/actions/pull/133 ---------------------------------------- Misc #22180: Provide official Windows (mswin) binary packages and a version manager https://bugs.ruby-lang.org/issues/22180#change-117899 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Japanese version of this proposal: https://gist.github.com/hsbt/552b01f2aac616af6f8056148407900a ## Background Ruby used to ship official Windows binaries. https://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ still has mswin32 zips from the 1.6 to 1.9-preview era, and they were discontinued around 1.9. One reason is that a bare zip was not usable as a distribution. https://bugs.ruby-lang.org/issues/999 reports that the `ruby-1.9.1-preview1` mswin32 zip was missing the OpenSSL and zlib DLLs, so `gem update` did not work at all. Since then, installing Ruby on Windows has depended on third-party distributions. The mswin platform, which is what `ruby/ruby` CI actually builds and tests with MSVC, has had no end-user distribution at all. https://bugs.ruby-lang.org/issues/19325 shows how the current state is perceived by Windows users. The technical ground has changed. Over the last few months I fixed all the tests that remained broken on mswin myself: `nmake check`, `test-bundler` and `test-bundled-gems` are green now, and `nmake exam`, which runs all of the test suites, completes as well. The build manages its C dependencies with a pinned vcpkg manifest (`vcpkg.json`), and CI covers VS 2022, VS 2026 and `windows-11-arm`. MSVC ABI (`vcruntime140`) has been stable since 2015. The missing piece is distribution, not build quality. Timing also matters. In the era of writing code with AI, the people who need a working Ruby on Windows are increasingly ordinary users who let a coding assistant set up the environment for them, and consumer AI tools operate natively on Windows, not through WSL. An assistant working unattended needs a runtime that installs without elevation and without GUI dialogs, exposes a machine-readable version index, and is relocatable so that installs are deterministic. Unattended provisioning is already the norm in CI (`setup-ruby` exists precisely for this), and AI assistants bring the same requirement to end-user machines. Python reached the same conclusion with PEP 773, described below. Ruby has no official answer to this on Windows today. ## Proposal I propose to provide an official Windows distribution based on the mswin platform, made of three components. All of them, including the test-suite fixes above, are work I implemented and verified myself. Nothing below is a design on paper. **1. `ruby/ruby`: a `binary-package` target.** A new nmake-only target packages the installed tree together with the vcpkg runtime DLLs, the VC runtime and the license terms of everything redistributed into a relocatable zip, with build-machine specific paths scrubbed from `rbconfig.rb`. Thanks to `LOAD_RELATIVE` the tree runs from any location. I will submit the pull request shortly. This is implemented and verified. The package passes a smoke test with `PATH` restricted to `System32` (openssl, fiddle, psych, zlib and RubyGems all work), and C extensions compile with VS Build Tools. In a survey of the 500 most-downloaded gems on rubygems.org forced to build from source, 21 of the 44 gems with a native extension built and loaded. All 23 failures were gem-side or environment-side issues (gcc-only code, POSIX-only source, missing third-party libraries), none caused by the package or by ruby itself, with identical results on 3.3.11, 3.4.10 and 4.0.5. **2. `ruby/actions`: building and publishing.** Automation builds the zips and publishes them together with sha256 checksums: daily builds of master and release builds of the maintained series. Released series (3.3, 3.4, 4.0) are built from their release tarballs with the same packaging script applied externally, so no change to the stable branches is required. This also enables re-packaging revisions (`-1`, `-2`) when a bundled dependency such as OpenSSL needs a security update without a new Ruby release. This part is already working too: in addition to master, zips of 3.3.11, 3.4.10 and 4.0.5 have been built and verified this way, and they are the packages the gem survey above was run on. **3. `rbmanager`: a version manager for Windows.** The same shape as Python's install manager (PEP 773, https://peps.python.org/pep-0773/) A single native executable (the `rb` command) installs a zip from a URL or a local path, extracts it under `%LOCALAPPDATA%`, switches versions with an NTFS junction, and needs one user-level `PATH` entry and no elevation. A working prototype written in C# is already complete and verified on a real machine: ``` > rb install ruby-4.1.0-x64-mswin64_140.zip Extracting ruby-4.1.0-x64-mswin64_140 ... Installed ruby-4.1.0-x64-mswin64_140 > ruby -v ruby 4.1.0dev (2026-06-29T22:22:44Z master 2ce6b8e54a) +PRISM [x64-mswin64_140] > rb list ruby-3.3.11-x64-mswin64_140 ruby-3.4.10-x64-mswin64_140 ruby-4.0.5-x64-mswin64_140 * ruby-4.1.0-x64-mswin64_140 > rb use 4.0 Now using ruby-4.0.5-x64-mswin64_140 > ruby -v ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x64-mswin64_140] ``` The example installs from a local zip today. Once the official version index described below is published, `rb install 4.1` will resolve the version, download the zip and verify its checksum by itself. ## What building on the platform vendor's toolchain enables This proposal is complementary to the existing gcc-based distributions and does not compete with them. Some capabilities are decided by third-party vendors rather than by Ruby, because their SDKs assume the MSVC toolchain and ABI, and those become reachable with an official MSVC-built runtime. Machine-learning runtime assets become directly reusable: the prebuilt Windows packages of ONNX Runtime, libtorch and OpenCV are MSVC binaries with C++ ABIs, and CUDA's `nvcc` accepts only `cl.exe` as its host compiler on Windows, so Ruby extensions binding GPU and ML runtimes need an MSVC-built Ruby to link cleanly. PDB symbols connect Ruby to the standard Windows diagnostics stack: WinDbg and Visual Studio can debug a mixed stack of Ruby and vendor DLLs, WER minidumps from end users become analyzable, and publishing official symbol packages becomes possible for the first time. And extension authors can pull C dependencies from the same vcpkg ecosystem that `ruby/ruby` itself already uses through `vcpkg.json`. ## What I ask to decide First, make these official distribution artifacts: announce them on the www.ruby-lang.org download page and host the zips, checksums and a static version index (the equivalent of pymanager's `index-windows.json`) on ruby-lang.org infrastructure. GitHub Releases can serve as the initial hosting during the preview period. Second, sign the published binaries with a project identity (for example SignPath Foundation issues OSS code-signing certificates) rather than an individual certificate. Third, host `rbmanager` as a repository under the `ruby` organization. The concrete zip layout and naming rule are implementation details. I will work them out with @nobu and document the result in `doc/distribution/windows.md`, so they are not something to decide on this ticket. ## Scope and non-goals This proposal does not replace or deprecate any existing third-party distribution. It adds an official channel for the platform the core team itself builds and tests. I already operate the official snap distribution and the entire release pipeline including security releases, and these artifacts ride on the same automation and the same operator, so this proposal does not change the current maintenance level. Pure-Ruby gems work with no toolchain. Building a C extension requires VS Build Tools, which Microsoft has licensed for building open-source dependencies without a paid Visual Studio license since 2022, and a `ridk`-like bootstrap (`win32/install-buildtools.cmd` is the seed) is follow-up work. Precompiled `x64-mswin64` gems across the ecosystem are long-term work and not a prerequisite. The survey above identified 12 gems that already support Windows with `x64-mingw-ucrt` precompiled binaries and only lack a working MSVC source path, a concrete and small upstream fix list. That list includes nokogiri and ffi, so applications depending on them (Rails, for example) do not work on this distribution yet. The fixes are tractable: I have already verified a one-line fix for msgpack locally and will send these upstream. TLS trust anchors are not bundled in the zip. `rbmanager` provisions certificates from the Windows certificate store at install time, and I will separately propose `OpenSSL::X509::Store#add_store` support for the OpenSSL 3.2+ `org.openssl.winstore://` store in ruby/openssl as the permanent solution. x64 comes first. arm64 (`arm64-mswin64`) already builds in CI and will follow once its test suite is green. ## Roadmap The rollout is incremental rather than tied to a single date. Zips for the released series (3.3, 3.4, 4.0) will be published progressively for their existing releases. For 4.1, nightly zips of master are published continuously, and a zip follows each preview release as soon as it is out. Only the GA of `rbmanager` and the distribution mechanism as a whole is aligned with the Ruby 4.1 release in December. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125930] [Ruby Bug#22178] Regexp#== regression: regexps built via the `rb_reg_new` C API are no longer equal to an identical literal
by watson1978 (Shizuo Fujita) 04 Jul '26

04 Jul '26

Issue #22178 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #22178: Regexp#== regression: regexps built via the `rb_reg_new` C API are no longer equal to an identical literal https://bugs.ruby-lang.org/issues/22178 * Author: watson1978 (Shizuo Fujita) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-24T22:57:54Z master d663de3fc4) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On current master, two `Regexp` objects that have the same options, the same regexp encoding (`Regexp#encoding`), and byte-identical sources are no longer `==` if their *source strings* have different encodings (e.g. `ASCII-8BIT` vs `US-ASCII`). This worked on 4.0 and earlier. Such a regexp is produced by the public C API `rb_reg_new()`, which does not normalize the source encoding, so an ASCII-only pattern keeps an `ASCII-8BIT` source instead of being promoted to `US-ASCII`. ## Reproduction ```ruby require "fiddle" libruby = Fiddle.dlopen(nil) RB_REG_NEW = Fiddle::Function.new( libruby["rb_reg_new"], [Fiddle::TYPE_VOIDP, Fiddle::TYPE_LONG, Fiddle::TYPE_INT], Fiddle::TYPE_VOIDP ) def reg_via_c_api(src, options = 0) # what a C extension using ptr = RB_REG_NEW.call(Fiddle::Pointer[src], src.bytesize, options) Fiddle.dlunwrap(ptr.to_i) # rb_reg_new() produces end c = reg_via_c_api("^[0-9]") # rb_reg_new() -> source ASCII-8BIT lit = /^[0-9]/ # literal -> source US-ASCII p c.source.encoding # ASCII-8BIT p lit.source.encoding # US-ASCII p c.encoding # US-ASCII p lit.encoding # US-ASCII p(c.options == lit.options) # true p(c.source == lit.source) # true (byte-identical) p(c == lit) # 4.0: true / master: false ``` Output on master: ``` #<Encoding:ASCII-8BIT> #<Encoding:US-ASCII> #<Encoding:US-ASCII> #<Encoding:US-ASCII> true true false # <-- was true on 4.0.5 ``` ## Cause Bisects to commit **d663de3fc43a8bb54bbdde12764b54bff4369da0** ("re.c: Simplify rb_reg_equal", 2026-06-24). Confirmed by building the two adjacent commits. | commit | `c == lit` | |--------|-----------| | `bb75c2893a` (parent) | `true` | | `d663de3fc4` | `false` | `rb_reg_equal` changed from comparing regexp encoding + source **content** to comparing the source **fstring identity**: ```c // before if (RREGEXP_SRC_LEN(re1) != RREGEXP_SRC_LEN(re2)) return Qfalse; if (ENCODING_GET(re1) != ENCODING_GET(re2)) return Qfalse; return RBOOL(memcmp(RREGEXP_SRC_PTR(re1), RREGEXP_SRC_PTR(re2), RREGEXP_SRC_LEN(re1)) == 0); // after if (RREGEXP_SRC(re1) != RREGEXP_SRC(re2)) return Qfalse; // fstring pointer compare return RBOOL(ENCODING_GET(re1) == ENCODING_GET(re2)); ``` Because fstring interning is encoding-sensitive, a `US-ASCII` `"^[0-9]"` and an `ASCII-8BIT` `"^[0-9]"` are distinct fstrings, so the new pointer comparison returns `false` where the old content+encoding comparison returned `true`. ## Question Is this behavior change intentional, or a side effect of the optimization? The commit message describes d663de3fc4 as a pure optimization and doesn't mention making the source string's encoding significant to Regexp#==, so it reads like an unintended side effect: the optimization assumes every regexp source is a normalized fstring, but rb_reg_new() can produce one whose source is a valid fstring with a non-normalized (`ASCII-8BIT`) encoding. -- https://bugs.ruby-lang.org/

1 0