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

[ruby-core:125389] [Ruby Bug#22019] Set#intersect () segv if the block is called after return
by jhawthorn (John Hawthorn) 10 Jul '26

10 Jul '26

Issue #22019 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22019: Set#intersect () segv if the block is called after return https://bugs.ruby-lang.org/issues/22019 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: jhawthorn (John Hawthorn) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class C include Enumerable def each(&b) $b = b yield 1 end end Set[1, 2, 3] & C.new $b.call(1) # [BUG] Segmentation fault at 0x00007f21bfa67f60 ``` The cause is essentially the same as #5801, we're initializing an ifunc pointing to a stack-allocated struct. The solution I think is to only ever use `rb_block_call` with a GC managed object like an imemo_memo. In addition to `set_intersection_block` this likely also affects, `lazy_flat_map_i`, `nmin_i`, `enum_sum_i`, and `product_each_i` all of which are passed a stack buffer. It might also be helpful to prevent the ifunc from being called after return. Some iterators (ex. `sort_by`) will raise a runtime error when this happens, but it's done ad-hoc (and detection depends on the variable still being accessible). -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126032] Status check on Ractor API proposals: empty? (#21930) and receive_all (#21869)
by milovidovmikhail＠gmail.com 10 Jul '26

10 Jul '26

Hi everyone, I have opened two Pull Requests that propose extensions to the Ractor API. Both have been open for some time, and I would appreciate your feedback on whether they can be approved or if they need changes: 1. Ractor#empty? Pull Request: https://github.com/ruby/ruby/pull/16277/ Tracker: https://bugs.ruby-lang.org/issues/21930 2. Ractor.receive_all Pull Request: https://github.com/ruby/ruby/pull/16105/ Tracker: https://bugs.ruby-lang.org/issues/21869 These are my very first Pull Requests to the Ruby core repository. If I missed any contribution guidelines, or if I need to provide more context or use cases, please let me know.

1 0

[ruby-core:125891] [Ruby Feature#22137] Change `Symbol#to_s` to return frozen strings
by byroot (Jean Boussier) 10 Jul '26

10 Jul '26

Issue #22137 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22137: Change `Symbol#to_s` to return frozen strings https://bugs.ruby-lang.org/issues/22137 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Since Ruby 3.4 ([Feature #20350]) `Symbol#to_s` returns a chilled string, meaning mutating it emits a deprecation warning. I believe it's now time to act on this deprecation, I'd like to request that on Ruby 4.1, `Symbol#to_s` always return a frozen string. Several very large codebases include Shopify and GitHub have been running with `Symbol.alias_method(:to_s, :name)` without any compatibility issues whatsoever. Making this change would allow to progressively get rid of an annoying pattern in performance sensitive code: ```ruby arg.is_a?(Symbol) ? arg.name : arg.to_s ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126029] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by matz (Yukihiro Matsumoto) 10 Jul '26

10 Jul '26

Issue #18915 has been updated by matz (Yukihiro Matsumoto). Thank you for checking. I am aware that adding any new top-level constant can conflict with existing code, but I would like to proceed as planned. The failure mode here is benign as compatibility issues go: a superclass mismatch raises an explicit `TypeError` at the definition site, so it surfaces immediately during development or in preview releases, not silently in production, and the fix is one line (remove the own definition or use the built-in one). We had the same situation with `Data` in 3.2 and it worked out fine. Announcing the addition in the NEWS and preview release notes should be enough. Matz. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-118008 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125265] [Ruby Feature#21998] Add {Method,UnboundMethod,Proc}#source_range
by Eregon (Benoit Daloze) 10 Jul '26

10 Jul '26

Issue #21998 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21998: Add {Method,UnboundMethod,Proc}#source_range https://bugs.ruby-lang.org/issues/21998 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I'm using matz's suggestion almost as-is from https://bugs.ruby-lang.org/issues/6012#note-53. The only change is the proposed class name. ## Use Cases Use cases have been discussed extensively and matz said: > The use cases are real and I want to support them So I think we don't need to discuss that anymore :) ## Background Adding column and last line information to `#source_location` is deemed too incompatible given the usages of `obj.source_location.last` which expect the start line (they would get the end column instead). ## Proposal So instead we add a new method, `{Method,UnboundMethod,Proc}#source_range`, which returns a `Ruby::SourceRange` and has these methods: * `start_line`: 1-indexed (same as `source_location.first`) * `end_line`: 1-indexed * `start_column`: in bytes, 0-indexed, I think `start_byte_column` could be good for extra clarity * `end_column`: in bytes, 0-indexed, I think `end_byte_column` could be good for extra clarity * `inspect` which shows something like `#<Ruby::SourceRange (1,0)-(2,10)>`. For the edge case of a heredoc spanning further than the end of a method/block, we would not include it in the `end_line` & `end_column` methods, but instead document it and provide a small code snippet in the docs to compute that if desired with Prism. ## Alternative An alternative could be a `Ruby::SourceLocation` class and `obj.source_location(object: true)`/`obj.source_location(extended: true)` but it feels less nice. Since we are designing something new I think it's best to go for the cleanest design. ## Consistency The above methods match the name of methods on `Prism::Node` and have the same semantics, which is good for consistency and to avoid confusion. ## Scope The scope is intentionally minimal to keep the discussion focused. ## Implementation I'm happy to implement this, it should be pretty trivial and very similar to the extended `source_location`. I would prefer to get an approval for this feature before implementing. -- https://bugs.ruby-lang.org/

6 22

[ruby-core:125586] [Ruby Feature#22085] `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
by byroot (Jean Boussier) 10 Jul '26

10 Jul '26

Issue #22085 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings https://bugs.ruby-lang.org/issues/22085 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Ruby issue warnings when parsing out of range floats, e.g.: ``` $ ruby -We '1e184467440737095516160.to_s' -e:1: warning: Float 1e184467440737095516... out of range ``` This makes a lot of sense for float literals parsed by the Ruby parser. However I'm not convinced it makes sense when parsing user input or third party data: ```ruby >> '1e184467440737095516160'.to_f (irb):1: warning: Float 1e184467440737095516... out of range => Infinity >> Float('1e184467440737095516160') <internal:kernel>:196: warning: Float 1e184467440737095516... out of range => Infinity ``` As these warnings aren't really actionable in most cases. So I think `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126026] [Ruby Misc#22180] Provide official Windows (mswin) binary packages and a version manager
by matz (Yukihiro Matsumoto) 10 Jul '26

10 Jul '26

Issue #22180 has been updated by matz (Yukihiro Matsumoto). I approve all three asks: making these official distribution artifacts on ruby-lang.org, signing them with a project identity, and hosting `rbmanager` under the `ruby` organization. The lack of an official Windows distribution has been a weak point of Ruby for decades, and this proposal fixes it for the very platform the core team builds and tests on, without competing with the existing gcc-based distributions. The fact that everything is already implemented and verified, and rides on the release automation hsbt already operates, makes this an easy decision. Details such as the vcruntime bundling question can be settled among the people already discussing them. Matz. ---------------------------------------- Misc #22180: Provide official Windows (mswin) binary packages and a version manager https://bugs.ruby-lang.org/issues/22180#change-118005 * 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:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 10 Jul '26

10 Jul '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125889] [Ruby Feature#22136] `sprintf` shouldn't raise ArgumentError when $DEBUG is set
by byroot (Jean Boussier) 10 Jul '26

10 Jul '26

Issue #22136 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22136: `sprintf` shouldn't raise ArgumentError when $DEBUG is set https://bugs.ruby-lang.org/issues/22136 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Expected behavior If I'm tracking down a problem and suspect an error might be swallowed somewhere, I do run my test case with `RUBYOPT="-d"` (or simply set `$DEBUG = true`. I do expect the program to execute all in the same way than without `-d`, expect for extra output on STDERR. ### Actual behavior If some code happens to call `sprintf` or `String#%` with too many arguments, then it will raise an error and likely break the program, preventing me from simply running the same code but in debug mode. ### Reproduction ``` $ ruby -e 'sprintf("foo", "bar"); p :ok' :ok $ ruby -We 'sprintf("foo", "bar"); p :ok' -e:1: warning: too many arguments for format string :ok $ ruby -dWe 'sprintf("foo", "bar"); p :ok' Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1423 - cannot load such file -- rubygems/defaults/operating_system Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1438 - cannot load such file -- rubygems/defaults/ruby Exception 'ArgumentError' at -e:1 - too many arguments for format string Exception 'RuntimeError' at <internal:ast>:96 - cannot get AST for ISEQ compiled by prism -e:1:in 'Kernel#sprintf': too many arguments for format string (ArgumentError) from -e:1:in '<main>' ``` ### Bug or Feature? I looked around the Ruby codebase, as far as I can tell this is the only method behaving this way (aside from its aliases like `String#%`). So I filed this as a Feature, but really in my opinion it is a bug. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125903] [Ruby Feature#22139] Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor
by ko1 (Koichi Sasada) 10 Jul '26

10 Jul '26

Issue #22139 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22139: Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor https://bugs.ruby-lang.org/issues/22139 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- Let's prohibit `END{}`/`Kernel#at_exit` on non-main Ractor. The current behavior is strange: ```ruby Ractor.new{ at_exit{ p [self, Ractor.current] } } sleep 1 #=> [#<Ractor:#2 t.rb:2 terminated>, #<Ractor:#1 running>] ``` There are some options: 1. prohibit them. Simple. 2. invoke the block at the end of the Ractor. 3. invoke the block at the end of the process on main Ractor. It is similar idea of the current behavior. 2 is rejected clearly by Matz because of the semantic gap with current behavior. 3 is no problem because the block and reachable objects from the block can be inherited to main Ractor. However, to make it simple, now let's prohibit them (1), and revisit if we found the (3) is needed. -- https://bugs.ruby-lang.org/

2 3