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

[ruby-core:124805] [Ruby Feature#14737] Split default gems into separate directory structure
by hsbt (Hiroshi SHIBATA) 13 Feb '26

13 Feb '26

Issue #14737 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected I have no plan to apply this proposal. I understand that the current situation is not optimal, but there is no advantage to change it considering that this structure has been in use for eight years with no critical issues. ---------------------------------------- Feature #14737: Split default gems into separate directory structure https://bugs.ruby-lang.org/issues/14737#change-116422 * Author: vo.x (Vit Ondruch) * Status: Rejected * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- On Fedora, we are using operating_system.rb [1], [2] to setup various RubyGems paths. Unfortunately, if we change Gem.default_dir (which we want to point into user home directory on Fedora), then this also changes location for default gems (!!), which are later not discovered by RubyGems [3]. It was not been a big deal for use, since we used to unbundle the gems shipped in Ruby, but with the gemification of StdLib, unbundlig becomes unsustainable (it is more work, but mainly it is incompatible change). To fix this issue, I modified the operating_system.rb to behave similarly to what Arch does [4], i.e. we started to inject "--user-install" option [1]. Unfortunately, this revealed the RubyGems are not respecting their own interfaces and I had to fix at least one of them along the way to make it work [6]. Apparently, using the "--user-install" option itself has some drawbacks and what is worse, it is not respected by Bundler, which was recently pointed out [5]. When I was fixing RubyGems [6], I just realized how the default gems are hacked up and how much is the original RubyGems configurability broken by this. This leads me to the proposal: **Could we please install default gems into different directory then the other, user installed, gems?** Since RubyGems were always designed to support various gem directory structures, the directory structure for default gems would become just other directory directory structure and would not collide with overrides in operating_system.rb, letting the distributions to override what was always designed to be overridable. BTW I believe that one nice side effect of this change would be simplification of RubyGems code base. The default gems would live in "default_gems" directory, their .gemspec files could be in standard "default_gems/specifications" directory and we could forget about "default_gems/specifications/defaults", etc. BTW2 I could fill this against RubyGems, but the default gems are Ruby stuff IMO, so I think this is appropriate tracker. [1]: https://src.fedoraproject.org/rpms/ruby/blob/master/f/operating_system.rb [2]: https://src.fedoraproject.org/rpms/ruby/blob/f27/f/operating_system.rb [3]: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.… [4]: https://wiki.archlinux.org/index.php/ruby [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1574594 [6]: https://github.com/rubygems/rubygems/pull/2116 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124804] [Ruby Bug#21876] Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts
by nbeyer＠gmail.com (Nathan Beyer) 13 Feb '26

13 Feb '26

Issue #21876 has been reported by nbeyer(a)gmail.com (Nathan Beyer). ---------------------------------------- Bug #21876: Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts https://bugs.ruby-lang.org/issues/21876 * Author: nbeyer(a)gmail.com (Nathan Beyer) * Status: Open * ruby -v: ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On macOS, `Addrinfo.getaddrinfo(host, service, Socket::AF_UNSPEC, Socket::SOCK_STREAM)` can deadlock in forked child processes when the host has no AAAA (IPv6) DNS records and the parent process previously resolved the same host. This happened to me when using an HTTP library to acquire an OAuth access token in a Rails initializer and then the process was forked, then a separate call was made to the same host in the forked process. ## Environment - macOS (tested on arm64-darwin24 and arm64-darwin25, Apple Silicon) - Ruby 3.4.7, 3.4.8 - The issue is probabilistic — frequency varies by environment but is highly reproducible under sustained DNS activity ## Reproduction Minimal example: ```ruby require "socket" require "timeout" # Parent resolves an IPv4-only host (no AAAA records) Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) pid = fork do begin Timeout.timeout(5) do Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) end puts "Child: OK" rescue Timeout::Error puts "Child: DEADLOCK — getaddrinfo hung for 5s" end end Process.waitpid(pid) ``` The issue is probabilistic — a single invocation may or may not deadlock. The attached script runs 50 trials each for several variants to demonstrate the pattern. Deadlock may not happen on the first run, but if you run it several times, you should see at least a single deadlock in Test 2, if not deadlock of all results in Test 1 and Test 2. See attachment - ruby_getaddrinfo_fork_bug.rb Typical output: ``` Test 1 (single IPv4-only host): 20/20 deadlocked Test 2 (multi-host warmup): 20/20 deadlocked Test 3 (dual-stack host control): 0/20 deadlocked Test 4 (AF_INET workaround): 0/20 deadlocked ``` ## Context The deadlock occurs when ALL of these conditions hold: 1. **macOS** (not observed on Linux) 2. Parent called `getaddrinfo(host, AF_UNSPEC)` for a host with **no AAAA (IPv6) records** 3. Child calls `getaddrinfo` for the **same host** with `AF_UNSPEC` **Not affected:** - Hosts **with** AAAA records (dual-stack) — e.g., `www.google.com`, `rubygems.org` - Using `Socket::AF_INET` instead of `Socket::AF_UNSPEC` - Hosts the parent never resolved | Host | AAAA records | Child deadlocks? | |------|-------------|-----------------| | httpbin.org | None | **Yes** | | www.github.com | None | **Yes** | | api.github.com | None | **Yes** | | stackoverflow.com | None | **Yes** | | www.google.com | Yes | No | | rubygems.org | Yes | No | | example.com | Yes | No | | www.cloudflare.com | Yes | No | ## Potential Root Cause As I understand it, on macOS, `getaddrinfo` communicates with the `mDNSResponder` system daemon via Mach IPC ports. When `getaddrinfo(AF_UNSPEC)` queries a host with no AAAA records, the negative AAAA result appears to be cached via Mach port state. After `fork()`, the child process inherits the address space (including references to this cached state) but does **not** inherit the Mach port connections to `mDNSResponder`. When the child calls `getaddrinfo` for the same host, it encounters the stale cache entry and deadlocks trying to communicate over the invalidated Mach port. Hosts with positive AAAA results are not affected, presumably because their cache entries do not require re-contacting `mDNSResponder` in the same code path. ## Feature #20590 Ruby 3.4's fork safety improvements (Feature #20590) added a read-write lock around `getaddrinfo` to prevent `fork()` while a `getaddrinfo` call is actively running. However, this does not address the issue reported here — the problem is not about forking *during* a `getaddrinfo` call, but about stale mDNSResponder Mach port state that is inherited by the child process *after* `getaddrinfo` has completed in the parent. ---Files-------------------------------- ruby_getaddrinfo_fork_bug.rb (5.36 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124803] [Ruby Feature#21822] Expose Return Value in the ensure Block
by artemb (Artem Borodkin) 12 Feb '26

12 Feb '26

Issue #21822 has been updated by artemb (Artem Borodkin). > ``` > begin > ret = begin > # .... > end > ensure > LOGGER.debug "return value: #{ret}" > end > ``` For me, ensure => ret looks cleaner, reduces cognitive overhead, and is simply easier on the eyes when reviewing real code. The structure is easier to parse visually, and the intent is clearer compared to the alternatives. Also, it doesn’t break any existing behavior — it’s purely additive, just a small but useful extension that makes the code more elegant and pleasant to read. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116419 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124684] [Ruby Feature#21863] Add RBASIC_FLAGS() and RBASIC_SET_FLAGS()
by Eregon (Benoit Daloze) 12 Feb '26

12 Feb '26

Issue #21863 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21863: Add RBASIC_FLAGS() and RBASIC_SET_FLAGS() https://bugs.ruby-lang.org/issues/21863 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- Currently there is `RBASIC_CLASS()` which is the same as `RBASIC(obj)->klass` on CRuby but also checks it's called on a valid object: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… I would like to add `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()`, which could be defined like this on CRuby: ```c #define RBASIC_FLAGS(obj) (RBASIC(obj)->flags) #define RBASIC_SET_FLAGS(obj, flags_to_set) (RBASIC(obj)->flags = flags_to_set) ``` This would let native extensions access those flags without relying on the specific fields, layout and existence of a `RBasic` `struct`. My main motivation here is that TruffleRuby, the alternative Ruby implementation with the most complete native extension support, cannot support having mutable fields in `RBasic`. The reason is because flags are mutable, it would be impossible to find out when the user writes to the flags if they write with just `RBASIC(obj)->flags = v`. And since the state related to flags is held internally on the Java object, writing to native memory would do nothing, which would be incompatible. With these macros we can know when the user writes to the flags and update the internal representation. In fact, TruffleRuby already implements these macros, since [this comment](https://github.com/truffleruby/truffleruby/issues/3118#issuecommen…. I would like to make it a standard C API to increase adoption and make it easier to discover. This would also be useful on CRuby to do additional checks when reading and writing flags: * We could add `RBIMPL_ASSERT_OR_ASSUME(!RB_SPECIAL_CONST_P(obj));` like `RBASIC_CLASS` does. * We could check that the frozen flag is not removed. * We could check that the frozen flag is consistent with the frozen flag on the object shape (if CRuby has a frozen flag in the shape). * We could check that the shape is not changed by native extensions this way (since the shape is stored in flags on 64-bit machines). * CRuby would be able to evolve the representation of RBasic more freely in the future. I'll note that there are already some macros/functions to manipulate flags such as `RB_FL_TEST()`, however they don't allow just reading or writing the flags: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… However it seems clear that C extensions do read and write the RBasic->flags field currently and these `RB_FL_*()` macros/functions are not enough, so `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()` would be obvious replacements. Here is a gem-codesearch for `/RBASIC\(.+\)->flags/`: https://gist.github.com/eregon/5866bd86e626ae723b5b16d935af8f94 An alternative would be to deprecate the RBasic->flags field entirely and eventually hide it, and don't provide a replacement for direct reading/writing flags, but that would break a bunch of native extensions, so it does not seem actionable. With this proposal we won't break anything and we'll actually get finer control over accesses to flags if e.g. we want to prevent some invariant-breaking changes. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:124800] [Ruby Misc#21825] Status of the universal parser implementing the Prism API
by Eregon (Benoit Daloze) 12 Feb '26

12 Feb '26

Issue #21825 has been updated by Eregon (Benoit Daloze). What does "Rejected" means in this case? No plan to do this? Does that mean Universal Parser no longer has the intention to become the Ruby parser used by everything? Having to maintain both parsers and both bytecode compilers is not an overhead we can ignore forever. ---------------------------------------- Misc #21825: Status of the universal parser implementing the Prism API https://bugs.ruby-lang.org/issues/21825#change-116414 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- I'm opening this issue to discuss and ask the status of the universal parser implementing the Prism API. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/), therefore if `parse.y` wants to remain a longer-term possibility it will have to somehow implement the Prism API. (this is not new, I recall discussing this at RubyKaigi 2024 with matz and @yui-knk) The Prism API covers clearly at least the Ruby API `Prism::Node`. But also if the universal parser is a complete alternative for Prism (if not it wouldn't really be *universal* and lots of existing Prism usages couldn't switch to it), it would need to also support the Java, JavaScript and Rust APIs of Prism. And also the AST part of the C API of Prism too. I think the most sensible and maybe the only realistic way is for `parse.y` to generate a Prism C AST using the AST structs from Prism: https://github.com/eregon/prism-generated/blob/generated/include/prism/ast.h such as `struct pm_call_node`. That way, all the higher-level APIs and code in the prism gem can be reused as-is and the only real difference is whether using the [prism.c](https://github.com/ruby/prism/blob/main/src/prism.c) parser or the `parse.y` parser, but the output would be the exact same. When that happens it would actually become possible to just switch the parser with `--parser=`, vs currently switching the CRuby source-to-bytecode compiler as well. IOW, there would be no need for the massive duplication in `compile.c` and `prism_compile.c`, we'd keep only `prism_compile.c` (and probably rename it), since `parse.y` would also generated a Prism C AST. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124798] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). https://github.com/ruby/prism/pull/3920 for the prism implementation. I plan to add https://bugs.ruby-lang.org/issues/21875 to the next devmeeting. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116411 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124795] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). `->(...) {}` is syntax invalid, same as `foo do |...|; end`, in that regard they are more like blocks. Lambdas do check arity though, which is probably what you were talking about. I'll make a separate issue for this to understand what the desired behavior should be if that's ok. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116407 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124794] [Ruby Feature#19107] Allow trailing comma in method signature
by byroot (Jean Boussier) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by byroot (Jean Boussier). I'm no expert on that area, but my understanding is that lambda specifically handle argument like methods do, not like proc do. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116406 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124793] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). Hm, not so sure about lambdas actually. Consider `|foo,|` block arguments, which causes the block to accept any number of positional arguments. I think a lambda should behave the same. If it is so, the usefulness is pretty limited since it doesn't work with the way the issue is about. Either way, I think it would need to be discussed first since I'm not 100% on the desired behaviour. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116405 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123433] [Ruby Misc#21630] Suggest @Earlopain for core contributor
by kddnewton (Kevin Newton) 12 Feb '26

12 Feb '26

Issue #21630 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #21630: Suggest @Earlopain for core contributor https://bugs.ruby-lang.org/issues/21630 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- @Earlopain has been prolifically contributing to Prism for over a year, in addition to other various changes around ruby/ruby, like [96fdaf2e](https://github.com/ruby/ruby/commit/96fdaf2e393933fdd128cd1a41fa9…, [3826019f](https://github.com/ruby/ruby/commit/3826019f310991aedf0612408d7b8…, [a82e7132](https://github.com/ruby/ruby/commit/a82e7132df71bd99b5d02c0c8a348…, and [many more](https://github.com/ruby/ruby/commits/master/?author=Earlopain). I would very much like @Earlopain to be able to merge their own contributions to Ruby, since they have been of such high quality for so long. -- https://bugs.ruby-lang.org/

8 9