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

[ruby-core:126119] [Ruby Bug#22204] Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only)
by maxfelsher (Max Felsher) 18 Jul '26

18 Jul '26

Issue #22204 has been reported by maxfelsher (Max Felsher). ---------------------------------------- Bug #22204: Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only) https://bugs.ruby-lang.org/issues/22204 * Author: maxfelsher (Max Felsher) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require shows the following text: > When RubyGems is required, [`Kernel#require`](https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require) is replaced with our own which is capable of loading gems on demand. > > When you call `require 'x'`, this is what happens: > > * If the file can be loaded from the existing Ruby loadpath, it is. > * Otherwise, installed gems are searched for a file that matches. If it’s found in gem ‘y’, that gem is activated (added to the loadpath). > > The normal `require` functionality of returning false if that file has already been loaded is preserved. Clicking the "Source" button shows RubyGems' version of the method, with a comment indicating it was pulled from `# File lib/rubygems/core_ext/kernel_require.rb, line 36`. The same situation holds for https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-require (as well as the 3.3 and 3.2 documentation, for what it's worth). This seems to have been fixed on master: at this moment, https://docs.ruby-lang.org/en/master/Kernel.html#method-i-require shows documentation that makes more sense for a core method (starting with "Loads the given `name`, returning `true` if successful and `false` if the feature is already loaded"). I think the fix was in https://github.com/ruby/ruby/pull/16086, which referenced a GitHub issue describing the same problem described here. If the backport policy allows for this kind of fix to be backported, would it be possible to fix the documentation for Ruby 4.0 and 3.4 in addition to master? (I assume this is out of scope for 3.3 and 3.2.) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125882] [Ruby Feature#22135] Remove deprecated `ObjectSpace#_id2ref`
by nobu (Nobuyoshi Nakada) 17 Jul '26

17 Jul '26

Issue #22135 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22135: Remove deprecated `ObjectSpace#_id2ref` https://bugs.ruby-lang.org/issues/22135 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- As a result of [Feature #15408], the `ObjectSpace#_id2ref` method has been deprecated and now triggers a warning. However, we recognize that its use had already been discouraged for a long time prior to this, and we believe it is rarely used nowadays. Are there any objections to removing this method in version 4.1? [GH-17577](https://github.com/ruby/ruby/pull/17577) -- https://bugs.ruby-lang.org/

8 7

[ruby-core:126113] [Ruby Feature#22202] Add Coverage.branch_stub and Coverage.method_stub as companions to Coverage.line_stub
by sferik (Erik Berlin) 17 Jul '26

17 Jul '26

Issue #22202 has been reported by sferik (Erik Berlin). ---------------------------------------- Feature #22202: Add Coverage.branch_stub and Coverage.method_stub as companions to Coverage.line_stub https://bugs.ruby-lang.org/issues/22202 * Author: sferik (Erik Berlin) * Status: Open ---------------------------------------- `Coverage.line_stub(path)` compiles a file and returns its line coverage array as if the file had been loaded but never run. SimpleCov uses this method to include never-loaded files in a report so that their lines count toward the denominator. But there is no equivalent for branch or method coverage. A tool that wants a never-loaded file to participate in branch or method totals must reconstruct the structures itself with a parser. The difficulty is that reconstruction must match the VM byte-for-byte. Merged coverage reports key branches and methods on their full location tuples, for example `[:if, id, start_line, start_col, end_line, end_col]`. If a tool synthesizes a tuple whose location differs from what the VM records for the same construct, merging a synthesized entry with a real one produces a duplicate branch that no execution can ever hit. The report then shows a permanently missed branch in a fully covered file. These location conventions are not documented and they change between Ruby versions. Cases SimpleCov has had to reverse engineer recently: 1. The range of an `elsif` clause changed between Ruby 3.3 and 3.4 (https://github.com/simplecov-ruby/simplecov/issues/1226) 2. A safe navigation call followed by a block ends its branch range at the call, excluding the block (https://github.com/simplecov-ruby/simplecov/issues/1233) 3. Conditions that are compile-time literals (`if true`, ternary on an integer) are folded and produce no branch at all, while `while true` still does. 4. On Ruby 3.3 the location of an empty branch arm depends on whether the construct is in value or void position. Ruby 3.4 removed this distinction. 5. `x => pattern` and `x in pattern` produce a `:case` branch on Ruby 3.3 and nothing on 3.4. SimpleCov now carries roughly 500 lines of Prism-based reconstruction plus a differential fuzzer that compiles thousands of generated programs under real Coverage and diffs the tuples, only to keep parity with conventions the VM already knows. Each new Ruby version can silently change a convention and reintroduce this class of bug. #### Proposal Add two class methods to the Coverage standard library: ```ruby require "coverage" Coverage.branch_stub("foo.rb") # => {[:if, 0, 2, 2, 6, 5] => {[:then, 1, 3, 4, 3, 10] => 0, [:else, 2, 5, 4, 5, 10] => 0}} Coverage.method_stub("foo.rb") # => {["Foo", :bar, 2, 2, 4, 5] => 0} ``` Return value shapes are identical to `Coverage.result[path][:branches]` and `Coverage.result[path][:methods]` so existing merge code works unchanged. Like `line_stub`, the file is compiled but not executed, and Coverage does not need to be running. It should raise the same errors `line_stub` raises for missing or unparsable files. The VM already computes these structures at compile time whenever coverage is enabled with `branches: true` or `methods: true`. `line_stub` is implemented by compiling the file and walking `iseq.trace_points`. A similar approach should work here. I am happy to help with a patch if this direction is acceptable. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126106] [Ruby Bug#22201] ruby.exe reads `"AA\ " BB` as a single argument
by mame (Yusuke Endoh) 16 Jul '26

16 Jul '26

Issue #22201 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22201: ruby.exe reads `"AA\ " BB` as a single argument https://bugs.ruby-lang.org/issues/22201 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A backslash escapes a double quote that sits beyond a whitespace character. ``` C:\> ruby -e "p ARGV" "AA\ " BB ["AA\\ BB"] # <- actual ["AA\\ ", "BB"] # <- expected ``` This is not intentional, right? The escape is cancelled when almost any other character appears, but I think whitespace seems to have been simply forgotten. The fix is so simple: ``` --- a/win32/win32.c +++ b/win32/win32.c @@ -1739,6 +1739,15 @@ w32_cmdvector(const WCHAR *cmd, char ***vec, UINT cp, rb_encoding *enc) *ptr = 0; done = 1; } + slashes = 0; break; case L'*': ``` https://github.com/ruby/ruby/pull/17943 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126104] [Ruby Bug#22199] win32: Kernel#system: `AA BB\` arrives as `AA BB"`
by mame (Yusuke Endoh) 16 Jul '26

16 Jul '26

Issue #22199 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22199: win32: Kernel#system: `AA BB\` arrives as `AA BB"` https://bugs.ruby-lang.org/issues/22199 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: windows * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` PS C:\> ruby -ve "system('python3','-c','import sys; print(sys.argv[1])', 'AA BB\\')" ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] AA BB" ``` `AA BB\` was passed to `Kernel#system`, but python3.exe read it as `AA BB"`. What happens: * `Kernel#system` creates and passes the command line string `python3 ... "AA BB\"` to `CreateProcessW`, and * python3.exe (and anything else using the VC Runtime's command line parser) reads `"AA BB\"` as an (accidentally unterminated) `AA BB"`. It reproduces when an argument contains a space and ends with `\`. When an argument contains a space, `Kernel#system` wraps it in double quotes. If the argument also ends with `\`, that backslash is taken to escape the closing quote. `Kernel#system` should escape the final backslash(es) when it wraps an argument that ends with one. In the example above it should pass `python3 ... "AA BB\\"` to `CreateProcessW`. Here is a PR for that: https://github.com/ruby/ruby/pull/17941 Note that cmd.exe and batch files do not interpret backslash escapes, so the backslash must NOT be escaped when calling those. The PR escapes only when (1) the call does not go through cmd.exe, (2) the argument is wrapped in double quotes, and (3) the argument ends with `\`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126102] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by Eregon (Benoit Daloze) 16 Jul '26

16 Jul '26

Issue #15408 has been updated by Eregon (Benoit Daloze). Update: `ObjectSpace._id2ref` has been removed on master / for Ruby 4.1! ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-118106 * Author: headius (Charles Nutter) * Status: Closed * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125722] [Ruby Feature#22108] Computed hash keys with (expr): syntax
by yertto (_ yertto) 16 Jul '26

16 Jul '26

Issue #22108 has been reported by yertto (_ yertto). ---------------------------------------- Feature #22108: Computed hash keys with (expr): syntax https://bugs.ruby-lang.org/issues/22108 * Author: yertto (_ yertto) * Status: Open ---------------------------------------- # Computed hash keys with `(expr):` syntax Allow `{ (expr): value }` as a computed hash key. Almost 20 years in the making, the missing puzzle piece for Hash's "new" colon notation: ```ruby h = { name: "symbol shorthand", # Ruby 1.9+ "quoted label": "symbol label", # Ruby 2.2+ (Feature #4935) (expr): "computed", # THIS PROPOSAL } ``` ## Motivation Ruby has long had two colon-based hash key syntaxes (name: for symbol keys and "quoted label": for quoted symbol keys). Adding (expr): is a baby step toward allowing all-colon hashes: ```ruby # Before -- mixed styles { name: "Alice", role: "admin", "key-#{n}": value, n => value } # After -- uniform colon syntax { name: "Alice", role: "admin", ("key-#{n}"): value, (n): value } ``` (And maybe a step closer to one day retiring the "hash rocket" `=>` from Hashes entirely?) ### Completing the colon family | Example | Since Ruby | Key type | |---------|-------|----------| | `{ name: value }` | [v1.9](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-1_9_1.html) | Symbol | | `{ "quoted label": value }` | [v2.2](https://docs.ruby-lang.org/en/3.4/NEWS/NEWS-2_2_0.html) | Symbol (quoted label) | | `{ (expr): value }` | *???* | Runtime expression value | ### Readability for computed-key-heavy code Code that builds dynamic hashes currently forces a style break midway through a literal. This is especially noticeable with interpolated keys, numeric keys, or variable-driven keys. ### Reducing `=>` overloading The `=>` token has been used to serve more purposes than the Hash literal (aka "Hash rocket") it was originally used for. - rightward assignment ``` expr => var ``` - pattern capture ``` case {name: "Alice", role: "admin"} in {name: String => name, role:} # capture the name String value into `name` p name # => "Alice" end ``` - rescue variables ``` rescue SomeExceptionClass => e ``` ``` rescue => e ``` Reducing its use in Hashes simplifies the language, especially for newcomers. ## Design ### `(expr):` vs `[expr]:` Parenthesized expressions were chosen over square bracket delimited: - Idempotent wrapping: `((x))` = `(x)`, but `[[x]]` != `[x]` (nested array) - Array keys: `{(["a"]): "b"}` reads naturally vs `{[["a"]]: "b"}` requiring extra wrapping - [jq precedent](https://jqlang.org/manual/v1.6/#object-construction): the JSON query language uses identical `{("a"+"b"): 59}` syntax (since jq 1.6, 2018) - Parentheses signals a grouping or "evaluate this", whereas square brackets signals an Array/container ### Improving on JavaScript JavaScript's "computed property names" `{ [expr]: value }` were introduced in ECMAScript 2015 (ES6), 3 years before the jq version. In Ruby, `[]` already means Array literal and method call. Rather than overloading `[]` further, `(expr):` (from jq) improves on the JavaScript design. Parentheses naturally signal evaluation, `):` inside `{}` is unambiguous to the lexer, and it matches the well-established jq convention. ### Edge cases handled - `(expr) : value` (space before colon) -- *syntax error* (consistent with `name : value`) - `{ (expr): }` (value omission) -- *syntax error* (runtime expression, no compile-time local to infer) - Mixed styles: `{ (1): "one", two: "two", "three": "three" }` -- *valid* - Nested parens: `{ ((1 + 2) * 3): "nested" }` -- *valid* - Nested hashes: `{ ({(1): "one"}): "two" }` -- *valid* ## Implementation Three changes to `parse.y` (Lrama LALR(1) parser, zero new conflicts): 1. Lexer: emit `tLABEL_END` when `EXPR_ENDFN` state, no space before `:`, and inside `brace_nest > 0` 2. Grammar: new `assoc` alternative -- `tLPAREN compstmt ")" tLABEL_END arg_value` 3. Precedence: `%nonassoc ')'` to disambiguate Reference implementation: [feature/computed-hash-keys](https://github.com/ruby/ruby/pull/17299) PR on GitHub. ## Historical context This was discussed on ruby-core in October 2007 (["General hash keys for colon notation"](https://public-inbox.org/ruby-core/E1ImQBE-00033s-IZ@x31/T/), murphy). Withdrawn due to the 1.9 feature freeze. Since then, `"quoted label":` (Ruby 2.2, [Feature #4935](https://bugs.ruby-lang.org/issues/4935)) and value omission (Ruby 3.1, [Feature #14579](https://bugs.ruby-lang.org/issues/14579)) have expanded the colon family, making the computed-key gap more conspicuous. Meanwhile, jq introduced the identical `{("a"+"b"):59}` syntax in jq 1.6 (2018), demonstrating real-world viability. ## Open questions - Is this syntax acceptable to the community? - Ripper (Ruby's parser library) does not yet emit events for this syntax -- should that be added before merging, or can it follow separately? - Is the jq precedent compelling enough to address the "no language does this" objection? ## Future directions All colon-based key syntaxes would now be available. This opens up the possibility of eventually deprecating `=>` from Hash literals (while keeping it for rescue, pattern matching, and rightward assignment). This proposal does not require that change - it is simply the enabling step, and any deprecation timeline could be a separate discussion. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:125045] [Ruby Bug#21955] `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page`
by ioquatix (Samuel Williams) 15 Jul '26

15 Jul '26

Issue #21955 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21955: `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page` https://bugs.ruby-lang.org/issues/21955 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a fiber terminates (falls off the end of its block, or raises an unhandled exception) after being reached via `Fiber#transfer`, its machine stack is **not** returned to the fiber pool. The stack is only freed when the `Fiber` object is eventually garbage collected. In production, where GC does not run continuously, terminated fibers accumulate unreleased stacks. Each stack allocation contains a guard page set with `mprotect(PROT_NONE)`, which splits a kernel VMA. On Linux this exhausts the per-process `vm.max_map_count` limit and raises: ``` FiberError: can't set a guard page: Cannot allocate memory ``` The symptom is confusing: the fibers are all dead (`alive? == false`), new fibers cannot be created, but GC has not run. ## Root cause In `cont.c`, `fiber_switch()`, the eager stack release after `fiber_store` returns is guarded by `resuming_fiber`: ```c // cont.c (affected versions) #ifndef COROUTINE_PTHREAD_CONTEXT if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` `resuming_fiber` is only non-`NULL` when the switch was initiated by `Fiber#resume` (which passes `resuming_fiber = fiber`). `Fiber#transfer` passes `resuming_fiber = NULL`, so the condition is never true and the stack is silently leaked until GC. Additionally, `fiber_raise` on a suspended non-yielding (transferred) fiber calls `fiber_transfer_kw`, also passing `resuming_fiber = NULL`, so the same leak occurs when a transferred fiber is terminated by a raised exception. ## Reproduction Set a low map count limit, then run the attached script: ``` sudo bash -c "echo 10000 > /proc/sys/vm/max_map_count" ruby test_fiber_transfer_leak.rb ``` Restore afterwards (`sysctl vm.max_map_count` shows the default, typically 65530). ```ruby GC.disable leaked = [] count = 0 begin 10_000.times do f = Fiber.new { } # terminates immediately leaked << f # hold reference so Fiber object is not GC'd f.transfer # transfer, not resume => stack NOT released (bug) count += 1 puts "[#{count} fibers] all dead: #{leaked.none?(&:alive?)}" if count % 1000 == 0 end puts "No error — fix is applied." rescue FiberError => e puts "FiberError after #{count} fibers: #{e.message}" puts "All terminated (alive?=false): #{leaked.none?(&:alive?)}" ensure GC.enable leaked.clear GC.start end ``` Expected output on **unpatched** Ruby (vm.max_map_count=10000): ``` [1000 fibers] all dead: true [2000 fibers] all dead: true [3000 fibers] all dead: true [4000 fibers] all dead: true FiberError after 4096 fibers: can't set a guard page: Cannot allocate memory All terminated (alive?=false): false ``` Expected output on **patched** Ruby: ``` [1000 fibers] all dead: true ... [10000 fibers] all dead: true No error — fix is applied. ``` ## Fix Drop the `resuming_fiber &&` guard. After `fiber_store` returns we are executing in the caller's context — we are never on `fiber`'s stack — so releasing it is unconditionally safe. `fiber_stack_release` is already idempotent (guarded by `fiber->stack.base == NULL`), so the resume path is unaffected. ```c #ifndef COROUTINE_PTHREAD_CONTEXT if (FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` Pull request with fix: https://github.com/ruby/ruby/pull/16416 -- https://bugs.ruby-lang.org/

4 3

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

15 Jul '26

Issue #22180 has been updated by hsbt (Hiroshi SHIBATA). I discussed the code signing plan for the official Windows binaries with @shugo . For the time being, we will use SignPath Foundation, which provides free code signing for open source projects. The publisher name on the binaries will be "SignPath Foundation" during this period. In the long term, we will move to a certificate under a Ruby-related name, either Azure Trusted Signing or a regular OV code signing certificate. Since identity validation for Azure Trusted Signing is not yet available to Japanese entities, that option would need cooperation from an eligible organization, for example Ruby Central. ---------------------------------------- Misc #22180: Provide official Windows (mswin) binary packages and a version manager https://bugs.ruby-lang.org/issues/22180#change-118093 * 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:126066] [Ruby Misc#22192] Clarify the scope of default visibility changed inside a block
by shugo (Shugo Maeda) 14 Jul '26

14 Jul '26

Issue #22192 has been reported by shugo (Shugo Maeda). ---------------------------------------- Misc #22192: Clarify the scope of default visibility changed inside a block https://bugs.ruby-lang.org/issues/22192 * Author: shugo (Shugo Maeda) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- `private` etc. called with no arguments inside a block changes the default visibility of the enclosing lexical scope, and the change survives the block: ```ruby class C %i[foo bar].each do |name| private define_method(name) { } end def afterwards; end # also private end C.private_method_defined?(:foo) #=> true C.private_method_defined?(:afterwards) #=> true ``` When multiple Procs share the same lexical scope, `private` in a Proc affects all Procs: ```ruby class Host SET_PRIVATE = proc { private } DEFINE = proc { def probe; end } end Host::SET_PRIVATE.call Host::DEFINE.call Host.private_method_defined?(:probe) #=> true ``` Neither CRuby nor ruby/spec has corresponding tests. I assume this is intentional, but am I correct? It seems that the visibility change is effective only within the block on JRuby, so I'd like to clarify this. -- https://bugs.ruby-lang.org/

2 4