- ruby-core - ml.ruby-lang.org

[ruby-core:111740] [Ruby master Bug#19325] Windows support lacking.
by dsisnero (Dominic Sisneros) 29 Sep '26

29 Sep '26

Issue #19325 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Bug #19325: Windows support lacking. https://bugs.ruby-lang.org/issues/19325 * Author: dsisnero (Dominic Sisneros) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2. -- https://bugs.ruby-lang.org/

11 13

[ruby-core:126876] [Ruby Feature#18439] YJIT: Support Microsoft x86 calling convention
by hsbt (Hiroshi SHIBATA) 29 Sep '26

29 Sep '26

Issue #18439 has been updated by hsbt (Hiroshi SHIBATA). I made YJIT work on mswin x64 in https://github.com/ruby/ruby/pull/19114. It follows the Win64 calling convention and registers unwind info for JIT code, as discussed here, and passes `nmake check` with YJIT enabled. YJIT is about 2x faster than the interpreter on ruby-bench's headline benchmarks on mswin. I'd like to ship this in Ruby 4.1 and will maintain the Windows side, so I'd appreciate reviews from the JIT team. ---------------------------------------- Feature #18439: YJIT: Support Microsoft x86 calling convention https://bugs.ruby-lang.org/issues/18439#change-119247 * Author: usa (Usaku NAKAMURA) * Status: Assigned * Assignee: jit ---------------------------------------- I heard that supporting YJIT for VC++ needs mmap from k0kubun-san, so I implemented tiny mmap emulation on Windows and committed it to master. And, I found we need more changes to actually enabled YJIT for VC++, at least: - YJIT requires `OPT_DIRECT_THREADED_CODE` or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq()`. Really? - Maybe ABI deffers between VC++ and YJIT's expectation. Can I get support to fix above? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126235] [Ruby Feature#22226] Ractor: class/module ownership -- restrict modification to the Ractor that created it
by ko1 (Koichi Sasada) 28 Sep '26

28 Sep '26

Issue #22226 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22226: Ractor: class/module ownership -- restrict modification to the Ractor that created it https://bugs.ruby-lang.org/issues/22226 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 4.1 ---------------------------------------- ## Abstract Every class/module records the Ractor that created it as its *owner*. Only the owner Ractor can modify it. Reading is unchanged and allowed from any Ractor. This replaces several ad-hoc "main Ractor only" rules with a single rule keyed on the creator. It **relaxes** the rules for classes a Ractor creates itself, and **tightens** them for classes created by somebody else. No Ruby-level API is added: ownership is recorded internally and is not exposed. --- ## 1. Motivation ### 1.1 The current rules ask the wrong question Today's restrictions ask *"are you the main Ractor?"*. They never ask *"did you create this class?"*. The result is inconsistent in both directions. A non-main Ractor may freely redefine **any** class in the process: ```ruby class C; end Ractor.new { C.define_method(:m) { 1 }; :done }.value #=> :done (works today) Ractor.new { class String; def foo = 1; end; :done }.value #=> :done (works today) Ractor.new { def f = 42; f() }.value #=> 42 (works today; defines Object#f) Ractor.new { Object.send(:remove_const, :FOO); :done }.value #=> :done (works today) ``` ...but it may **not** set an instance variable on a class it created itself: ```ruby Ractor.new { k = Class.new # nobody else can even name this class yet k.instance_variable_set(:@iv, 1) }.value #=> Ractor::IsolationError: # can not set instance variables of classes/modules by non-main Ractors ``` ...nor give it an unshareable constant: ```ruby Ractor.new { k = Class.new k.const_set(:X, "str".dup) }.value #=> Ractor::IsolationError: # can not set constants with non-shareable objects by non-main Ractors ``` The first group is unrestricted although it affects the whole process. The second group is forbidden although it affects nothing but the Ractor doing it. The rules are exactly inverted with respect to who is actually affected. ### 1.2 A Ractor's classes can be redefined under it by another Ractor Because any Ractor may modify any class, the code a Ractor runs can be changed by somebody else at any moment: ```ruby Ractor.new { class String; def upcase = :patched; end; :done }.value "abc".upcase #=> :patched # evaluated in the *main* Ractor ``` ```ruby FOO = 1 Ractor.new { Object.send(:remove_const, :FOO); :removed }.value FOO #=> NameError: uninitialized constant FOO ``` Both of these run fine today. There is no way for a Ractor to rely on the classes it uses. ### 1.3 Class internals have no single writer `m_tbl`, `const_tbl` and the class fields can be written by any Ractor today. This means the implementation cannot assume a single writer for any class, which stands in the way of synchronization and caching work (and it is also how the `cvar_overtaken()` bug below arose: a *read* path physically deletes a table entry, potentially of another Ractor's class). --- ## 2. Proposal A class/module records its creator Ractor as its **owner**. Only the owner may: * define/remove/undef methods, `alias`, change method visibility * `include`/`prepend` into it, and `Module#refine` targeting it * define/remove constants, register `autoload` * set instance variables on the class/module object Non-owner Ractors get `Ractor::IsolationError`. **Reading is completely unchanged**: method calls, instantiation, subclassing, constant reads and instance-variable reads all work from any Ractor as before. In exchange, the previous "main Ractor only" rules for class instance variables and unshareable constant values become "**owner Ractor only**". A Ractor gets full use of the classes it creates. Since all classes/modules created at boot or by main-Ractor code (including everything loaded by `require`) are owned by the main Ractor, this is equivalent to today's rules for programs that do not create classes inside non-main Ractors. --- ## 3. Examples ### 3.1 Newly allowed: a Ractor can fully use the classes it creates Instance variables on a class the Ractor created: ```ruby Ractor.new { k = Class.new k.instance_variable_set(:@iv, 1) # was: IsolationError, even for a shareable value! k.instance_variable_set(:@iv, "str".dup) # was: IsolationError k.instance_variable_get(:@iv) #=> "str" }.value ``` **Unshareable values in constants** of a class the Ractor created. This was the main Ractor's privilege before; now every Ractor has it for its own classes: ```ruby Ractor.new { k = Class.new k::BUF = "buffer".dup # unshareable value; was: IsolationError k::BUF << "!" # ...and the owner can freely use it k::BUF #=> "buffer!" }.value Ractor.new { k = Class.new k.const_set(:LIST, [1, 2, 3]) # an unfrozen Array is unshareable too k::LIST << 4 k::LIST #=> [1, 2, 3, 4] }.value ``` The value stays private to the owner -- reading it from another Ractor raises, which is exactly the rule that applied to the main Ractor before: ```ruby port = Ractor::Port.new r = Ractor.new(port) { |pt| k = Class.new; k::BUF = "buffer".dup; pt << k; Ractor.receive } k = port.receive k::BUF #=> Ractor::IsolationError: can not access non-shareable objects in constant # #<Class:0x...>::BUF of a class/module created by another Ractor. ``` A *shareable* value in the same position is readable from anywhere, as before: ```ruby r = Ractor.new(port) { |pt| k = Class.new; k::N = 42; pt << k; Ractor.receive } k = port.receive k::N #=> 42 ``` Classes defined under a module the Ractor created itself work fully: ```ruby Ractor.new { mod = Module.new mod.const_set(:Foo, Class.new { def m = :ok }) mod::Foo.new.m #=> :ok }.value ``` ### 3.2 Newly prohibited: modifying a class created by another Ractor ```ruby class C; end module M; end Ractor.new { def f = 42 }.value #=> can not modify Object because it is created by another Ractor # (top-level `def` defines a private method on Object) Ractor.new { class String; def foo = 1; end }.value #=> can not modify String because it is created by another Ractor Ractor.new { C.define_method(:m) { 1 } }.value Ractor.new { C.send(:alias_method, :a, :inspect) }.value Ractor.new { C.send(:private, :inspect) }.value Ractor.new { C.send(:undef_method, :inspect) }.value Ractor.new { C.include(M) }.value Ractor.new { C.prepend(M) }.value Ractor.new { Module.new { refine(C) { def z = 1 } } }.value Ractor.new { C.autoload(:Zz, "zz") }.value #=> can not modify C because it is created by another Ractor Ractor.new { C.const_set(:X, 1) }.value # note: even a *shareable* value now raises #=> can not set constants of classes/modules created by another Ractor Ractor.new { class TopCls; end }.value # a top-level class name... Ractor.new { module TopMod; end }.value # ...and a top-level module name #=> can not set constants of classes/modules created by another Ractor # (both write a constant into Object) Ractor.new { Object.send(:remove_const, :FOO) }.value #=> can not modify Object because it is created by another Ractor Ractor.new { C.instance_variable_set(:@iv, 1) }.value #=> can not set instance variables of classes/modules created by another Ractor ``` Patterns that stop working: ```ruby # a registry in Class#inherited that writes into the superclass Base = Class.new { def self.inherited(sub) = const_set(:"Sub#{sub.object_id}", sub) } Ractor.new { Class.new(Base) }.value #=> can not set constants of classes/modules created by another Ractor # lazy definition on first touch M2 = Module.new { def self.const_missing(n) = const_set(n, Class.new) } Ractor.new { M2::Foo }.value #=> can not set constants of classes/modules created by another Ractor ``` Both work if the definition happens before the Ractor is spawned (eager loading). ### 3.3 Unchanged ```ruby Ractor.new { "abc".upcase }.value #=> "ABC" Ractor.new { C.new }.value # instantiation Ractor.new { Class.new(String) { def m = :ok }.new.m }.value #=> :ok (subclassing is creation) Ractor.new { require "time"; Time.now.respond_to?(:xmlschema) }.value #=> true ``` `require` from a non-main Ractor keeps working because `Ractor#require` performs the load on the main Ractor, so the library's classes are defined by (and owned by) the main Ractor. `def` on an object a Ractor created is also unaffected -- an ordinary object's singleton class is created by, and owned by, the Ractor that triggers it: ```ruby Ractor.new { o = Object.new; def o.f = :ok; o.f }.value #=> :ok ``` ### 3.4 Summary table | operation from a non-main Ractor | today | proposal | |---|---|---| | define a method on a foreign class | OK | **IsolationError** | | top-level `def` | OK | **IsolationError** | | `include`/`prepend`/`refine` a foreign class | OK | **IsolationError** | | set a **shareable** constant on a foreign class | OK | **IsolationError** | | set an **unshareable** constant on a foreign class | IsolationError | IsolationError | | `remove_const` / `autoload` on a foreign class | OK | **IsolationError** | | set an ivar on a foreign class | IsolationError | IsolationError | | define a method on its **own** class | OK | OK | | set a **shareable** constant on its **own** class | OK | OK | | set an **unshareable** constant on its **own** class | IsolationError | **OK** | | set an ivar on its **own** class | IsolationError | **OK** | | read / call / instantiate / subclass any class | OK | OK | --- ## 4. How the proposal answers the motivation * **1.1 (rules ask the wrong question)** -- the rules now ask "did you create this?" instead of "are you main?". Every restriction is on the class of somebody else, and every relaxation is on your own class. The two inverted cases in 1.1 both flip to the right side. The old "main Ractor only" rules become the special case *"boot-time classes are owned by the main Ractor"*, so they are no longer separate rules. * **1.2 (classes changed under you)** -- no Ractor can modify a class it did not create, so the classes a Ractor uses cannot be redefined by another Ractor. * **1.3 (no single writer)** -- every class/module now has exactly one Ractor which can write its method table, constant table and fields. --- ## 5. What this does **not** give Ownership bounds *who may write*, not *what readers may see*. Reads stay unsynchronized and a class modification is not atomic, so a non-owner Ractor can still observe a class in the middle of being modified by its owner: after the first `def` of a `class ... end` body but before the second, or while `include`/`prepend` is rewiring the ancestor chain. The guarantee is **a single writer per class/module**, not a consistent view for readers. This proposal is not, and does not claim to be, full isolation of class state. --- ## 6. Details * **Singleton classes / metaclasses** are owned by the owner of the object they are attached to, not by the Ractor that happened to trigger their lazy creation. `def C.foo` is allowed exactly for the owner of `C`: ```ruby class C; end Ractor.new { C.singleton_class; :touched }.value # another Ractor touches it first class << C; def foo = :ok; end # still fine in main C.foo #=> :ok Ractor.new { class << C; def bar = 1; end }.value #=> IsolationError ``` * **Terminated owner**: a class whose owner Ractor has finished becomes permanently read-only for everybody, including the main Ractor. ```ruby K = Ractor.new { Class.new { def x = :made_in_ractor } }.value K.new.x #=> :made_in_ractor (reading is fine) K.define_method(:y) { 1 } #=> IsolationError (nobody owns it any more) ``` There is intentionally no API to look up or transfer ownership. * **Class variables** are *not* covered by the relaxation. They are shared across the whole inheritance chain and the class they are physically stored in can migrate over time (`cvar_overtaken`), so no single owner can be defined for them. Writes still require the main Ractor, and additionally must not cross the ownership boundary (the class actually written into must be owned), so class fields keep a single writer. * **Copying a foreign class**: `Class#dup`/`clone` of a class created by another Ractor produces a copy owned by the copying Ractor. It raises if the source's constants or instance variables refer to unshareable objects (they would leak across Ractors); copying classes holding only shareable values works. This gives a mutation-free alternative to monkey-patching: ```ruby S = Class.new; S.const_set(:OK, 1) Ractor.new { k = S.dup; k.define_method(:m) { 1 }; k.new.m }.value #=> 1 ``` * **Top-level class and module names**: `class Foo; end` / `module Foo; end` at the top level of a non-main Ractor writes a constant into `Object`, so both are prohibited. Define them under a module the Ractor creates itself instead (`mod = Module.new; mod.const_set(:Foo, Class.new)`). Integration with `Ruby::Box` is future work. * **Bug fix included**: `cvar_overtaken()` physically deleted a duplicated cvar entry from the `front` class, and that path is reachable from *read* operations (`rb_cvar_find`) -- i.e. a cross-Ractor write triggered by a read. The clean-up is now skipped unless the current Ractor owns `front`. --- ## 7. Incompatibility Only code that modifies classes from a non-main Ractor is affected. Concretely, the following raise `Ractor::IsolationError` where they used to work: * method definition / `alias` / visibility change on a foreign class, including top-level `def` * `include`/`prepend` into a foreign class, `refine` targeting one * setting a **shareable** constant on a foreign class, `remove_const`, `autoload` registration * `Class#inherited` and `const_missing`/`method_missing` hooks which mutate a foreign class Migration is usually "define it before spawning the Ractor" (eager loading), or "create the class inside the Ractor that uses it", or "`dup` the foreign class and modify the copy". Programs which never define classes inside non-main Ractors are unaffected. --- ## 8. Open questions / future work * `freeze` of a foreign class is still allowed. It is a behavior-changing write and should probably be owner-only too. * `Module#set_temporary_name` is not checked yet. * Singleton class ownership is not transferred by `Ractor#send(move: true)`. * Integration with `Ruby::Box`, so that non-main Ractors can define top-level class/module names. * Should the error message for a class owned by the main Ractor say "owned by the main Ractor" rather than "created by another Ractor"? The current wording is confusing for top-level `def`, where the user never mentioned `Object`. --- ## 9. Implementation https://github.com/ruby/ruby/pull/17913 The owner is stored in `rb_classext_t::owner_ractor` as the Ractor object; `0` means the main Ractor, so single-Ractor programs get no additional GC edges. It is marked from the classext and updated on compaction, so the comparison never sees a dangling or reused reference. Method-table checks funnel through `rb_class_modify_check()`; constant/ivar/cvar checks replace the previous `rb_ractor_main_p()` checks in `variable.c`. The class-ivar fast paths in `vm_insnhelper.c` switch from "main Ractor" to "owner Ractor", which keeps them valid because the owner is the only writer and its threads are serialized by the per-Ractor lock. `make btest` (2053 tests), `make test-all` (35797 tests, 0 failures / 0 errors) and `make test-spec` (32628 examples, 0 failures / 0 errors / 0 tagged) all pass. Three tests which relied on cross-Ractor method definition were rewritten so that the owner Ractor performs the definition. ## Notes * Above description is written by Claude code from my explanation. * The biggest motivation is "main-Ractor" exceptions. The concept "owner Ractor for classes/modules" solves this kind of exception. * Another idea for mutating the classes/modules is prohibit them on non-main Ractors because most of classes/modules are defined on the loading time on the main Ractor. However, it also prohibits `Class.new` in non-main Ractors, and it is common programming pattern on Ruby. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126871] [Ruby Bug#22387] str_shared_replace incorrectly recalculates termlen
by rwstauner (Randy Stauner) 28 Sep '26

28 Sep '26

Issue #22387 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22387: str_shared_replace incorrectly recalculates termlen https://bugs.ruby-lang.org/issues/22387 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- This ruby snippet crashes under ASan ```ruby s = ("\u{30AF}" * 7).encode("UTF-16LE").b s.force_encoding("UTF-16LE") s.encode!("UTF-8") # 21 bytes in a 22-byte malloc, capa now claims 22 s << "x" # fits, per capa, then NUL terminator written at [22] ``` str_shared_replace uses rb_enc_associate which recalculates termlen based on the old str even though the termlen of the new str was already used for the copy. We can just switch that to rb_enc_raw_set to fix. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:126866] [Ruby Bug#22386] Segfault when a Ractor helper thread reports an exception during teardown
by rkh (Konstantin Haase) 28 Sep '26

28 Sep '26

Issue #22386 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22386: Segfault when a Ractor helper thread reports an exception during teardown https://bugs.ruby-lang.org/issues/22386 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-27T05:30:49Z master f6ff9e7d02) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.1-dev can segfault when a thread inside a terminating Ractor raises an exception in an `ensure` block. Automatic thread exception reporting tries to load error-formatting code through `require`. The require path creates an internal Ractor port after the Ractor's port table has been freed. Creating a `Ractor::Port` directly in the same teardown context also segfaults, even with automatic exception reporting disabled. Script to reproduce the issue: ```ruby worker = Ractor.new do ready = Thread::Queue.new Thread.new do begin ready << true sleep ensure Object.new.missing_method_during_teardown end end ready.pop :done end worker.value ``` Running the script on Ruby 4.1-dev gives a segmentation fault output and then hangs. ``` #<Thread:0x0000000122aa0190 issue.rb:3 aborting> terminated with exception (report_on_exception is true): [BUG] Segmentation fault at 0x0000000000000018 ruby 4.1.0dev (2026-09-27T05:30:49Z master f6ff9e7d02) +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0002 p:---- s:0006 e:000005 l:y b:0001 r:0x0 CFUNC :detailed_message c:0001 p:---- s:0003 e:000002 l:y b:---- r:0x0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- issue.rb:0:in 'detailed_message' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 2 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000000000000001 x2: 0x000000083b2cf0e0 x3: 0x0000000000000000 x4: 0x0000000000000001 x5: 0x0000000000000000 x6: 0xffffffffbfc007ff x7: 0xfffff0003ffff800 x18: 0x0000000000000000 x19: 0x0000000122ac09c0 x20: 0x000000083adced00 x21: 0x0000000000000000 x22: 0x0000000000000001 x23: 0x000000083b2cf0e0 x24: 0x0000000122ab00a0 x25: 0x00000000ffffffff x26: 0x000000012d90bfc8 x27: 0x000000083b03a940 x28: 0x0000000055550483 lr: 0x0000000103b8e020 fp: 0x000000012da0f760 sp: 0x000000012da0f720 -- C level backtrace information ------------------------------------------- ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126735] [Ruby Misc#22320] Build fails with SIGSEGV in `miniruby` during `builtin_binary` on macOS 26 (Tahoe): `pipe2` declared by SDK but absent from libSystem at runtime
by mreiche＠adobe.com (Michael Reiche) 28 Sep '26

28 Sep '26

Issue #22320 has been reported by mreiche(a)adobe.com (Michael Reiche). ---------------------------------------- Misc #22320: Build fails with SIGSEGV in `miniruby` during `builtin_binary` on macOS 26 (Tahoe): `pipe2` declared by SDK but absent from libSystem at runtime https://bugs.ruby-lang.org/issues/22320 * Author: mreiche(a)adobe.com (Michael Reiche) * Status: Open ---------------------------------------- **Environment** - macOS 26.6.2 (Tahoe), Apple Silicon (arm64) - Apple clang 21.0.0 (clang-2100.3.34.2), target `arm64-apple-darwin25.6.0` - Ruby 3.4.10 (also reproduced on 4.0.7), built via ruby-build 20260915 / rbenv - Also reproduces with a plain `./configure && make` from the release tarball **Summary** On macOS 26, `make` dies with `Segmentation fault: 11` at the step that runs the freshly-linked `miniruby` to generate `builtin_binary.inc` (`builtin_binary.rbbin`). Every Ruby version fails identically, because `miniruby` segfaults *on launch* during interpreter init. ``` compiling enc/trans/newline.c linking miniruby make: *** [builtin_binary.inc] Segmentation fault: 11 ``` **Root cause** macOS 26's SDK now **declares `pipe2()`** in its headers, so Ruby's `configure` sets `HAVE_PIPE2` and `rb_cloexec_pipe()` compiles a call to `pipe2`. However, **libSystem does not actually provide the symbol at runtime**. The weak-imported `_pipe2` binds to NULL, and the call during timer-thread setup jumps to address 0. Crash report (`~/Library/Logs/DiagnosticReports/miniruby-*.ips`): ``` Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000000 Faulting thread frames: 0x0 ← call through NULL function pointer miniruby rb_cloexec_pipe miniruby setup_communication_pipe_internal miniruby rb_thread_create_timer_thread miniruby Init_Thread miniruby rb_call_inits miniruby ruby_setup / ruby_init miniruby main dyld start ``` Confirmation that `pipe2` is declared but not present at runtime: ``` $ cat > /tmp/pipe2test.c <<'EOF' #include <stdio.h> extern int pipe2(int[2], int); int main(void){ printf("%p\n", (void*)pipe2); return 0; } EOF $ clang -o /tmp/pipe2test /tmp/pipe2test.c && /tmp/pipe2test dyld[]: Symbol not found: _pipe2 Expected in: /usr/lib/libSystem.B.dylib ``` **Steps to reproduce** 1. On macOS 26 (Apple Silicon), build Ruby 3.4.x from source (`./configure && make`). 2. `make` segfaults at `builtin_binary.inc` while executing `miniruby`. **Expected** `configure` should not enable `HAVE_PIPE2` when the symbol is declared but unavailable at runtime, or `rb_cloexec_pipe` should guard the call (e.g. `__builtin_available` / weak-symbol NULL check) and fall back to `pipe()` + `FD_CLOEXEC`. **Actual** `HAVE_PIPE2` is enabled based solely on the declaration; the resulting binary calls a NULL symbol and crashes. **Workaround** ``` ac_cv_func_pipe2=no ./configure ... # or, with rbenv: RUBY_CONFIGURE_OPTS="ac_cv_func_pipe2=no" rbenv install 3.4.10 ``` **Suggested fix** Make the `pipe2` detection on Darwin a *link-and-availability* test rather than a declaration check, or wrap the call site with an availability guard so it degrades to the `pipe()` fallback when `&pipe2 == NULL`. (macOS historically lacked `pipe2`; the macOS 26 SDK appears to declare it ahead of libSystem actually providing it.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126868] [Ruby Feature#8947] make alias, alias_method, attr_* return name of the alias
by Earlopain (Earlopain _) 28 Sep '26

28 Sep '26

Issue #8947 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed This was implemented in https://bugs.ruby-lang.org/issues/17314 ---------------------------------------- Feature #8947: make alias, alias_method, attr_* return name of the alias https://bugs.ruby-lang.org/issues/8947#change-119234 * Author: rkh (Konstantin Haase) * Status: Closed ---------------------------------------- Now that def returns the method name, it would be handy to have alias/alias_method return the name of the alias: class Foo private def foo() end protected alias_method :bar, :foo end Same goes for the attr_* methods: class Foo private attr_accessor :foo, :bar end What do you think? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126676] [Ruby Bug#22310] parse.y rejects a variable binding that precedes an unrelated alternative pattern
by yuki300 (Yuki Hirota) 27 Sep '26

27 Sep '26

Issue #22310 has been reported by yuki300 (Yuki Hirota). ---------------------------------------- Bug #22310: parse.y rejects a variable binding that precedes an unrelated alternative pattern https://bugs.ruby-lang.org/issues/22310 * Author: yuki300 (Yuki Hirota) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `parse.y` rejects patterns in which a variable binding appears *before* an alternative pattern, even when the alternative itself binds nothing. Prism accepts the same code. Is this intended? ## Reproduction ```ruby # ok.rb case [:a, 1] in [ :a | :b, x ] end # ng.rb case [1, :a] in [ x, :a | :b ] end ``` ``` $ ruby --parser=parse.y -c ok.rb Syntax OK $ ruby --parser=parse.y -c ng.rb ng.rb:2: alternative pattern after variable capture (SyntaxError) $ ruby --parser=prism -c ng.rb Syntax OK ``` The two patterns are semantically identical; only the order of the array elements differs. Both files run without error under the default parser. ## Other forms rejected by parse.y (all accepted by Prism) ```ruby in { a: String => t, b: Integer | String } # binding, then alternative in { a: String => t, b: { c: Integer | String } } # alternative nested deeper in [ one, "a" | "b" => two ] # form reported in rails/bootsnap issue 539 in { access_token: String => token, expires_in: (Integer | String) => expires_in } # form shipped in the anthropic gem ``` Reversing the order makes them pass: ```ruby in { b: Integer | String, a: String => t } # Syntax OK ``` For contrast, a binding *inside* the alternation is rejected by both parsers on 4.0.4, as expected: ```ruby in [ x, :a | y ] # variable capture in alternative pattern (parse.y and Prism) ``` ## Why this looks unintended `:a | :b` and `Integer | String` bind no variables, so the documented restriction -- "Binding to variables currently does NOT work for alternative patterns joined with `|`" -- is not violated. Nothing can be left unbound. The check in `p_alt` tests `p->ctxt.capture_in_pattern`, which is set by any binding anywhere in the same `in` clause, not only by a binding on the left-hand side of the `|`: ```c p_alt : p_alt[left] '|'[alt] { p->ctxt.in_alt_pattern = 1; } p_expr_basic[right] { if (p->ctxt.capture_in_pattern) { yyerror1(&@alt, "alternative pattern after variable capture"); } ``` Prism instead visits the left-hand node when it reaches the `|` (`parse_pattern_alternation_error` in prism.c), so sibling bindings are not affected. The check was introduced in https://github.com/ruby/ruby/commit/f4b6a5191ceb0ed0cd7a3e3c8bab24cc0dd15736 ([Feature #21572]). The discussion in #21572 and in the dev meeting (https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeeting-2025-10…) only covers bindings *inside* an alternation, and `test/ruby/test_pattern_matching.rb` only asserts the passing order (`in [ :a | :b, x]`). The `p_alt` rule is unchanged on current master. ## Impact Not visible under the default parser. However, `RubyVM::InstructionSequence.compile_file` was routed to parse.y until [Bug #22023] was fixed, so bootsnap (which uses it to build its bytecode cache) made gems fail to load on Ruby 4.0.1-4.0.3 while `ruby foo.rb` worked. That path is fixed in 4.0.4 and worked around in bootsnap 1.24.2, but the parse.y check itself remains. ## Prior sightings The same rejection has been observed before and was each time attributed to the `compile_file` routing bug ([Bug #22023]): - https://github.com/rails/bootsnap/issues/539 (cause identified as https://github.com/ruby/ruby/pull/16463, later backported as #22023) - https://github.com/ruby/irb/issues/1212 ("in Ruby `4.0.2` `parse.y` has a bug, but the important part here is that this is using `parse.y`") - https://github.com/anthropics/anthropic-sdk-ruby/pull/192, whose author noticed that swapping the hash-pattern key order avoids the error As far as I can find, whether the parse.y check itself is correct has not been raised. ## Environment ``` ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] # rejects with --parser=parse.y ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] # same; also via compile_file ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin25] # parse.y accepts all of the above ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126864] [Ruby Bug#22385] Enumerator::Lazy#zip loses to_ary conversions when mixed with enumerable arguments
by afurm (Andrii Furmanets) 26 Sep '26

26 Sep '26

Issue #22385 has been reported by afurm (Andrii Furmanets). ---------------------------------------- Bug #22385: Enumerator::Lazy#zip loses to_ary conversions when mixed with enumerable arguments https://bugs.ruby-lang.org/issues/22385 * Author: afurm (Andrii Furmanets) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-26T04:24:02Z af/ruby-correctnes.. da3e1fcb68) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Enumerator::Lazy#zip` discards a successful `to_ary` conversion when a later argument requires Enumerable iteration. The equivalent eager `Enumerable#zip` call preserves the conversion. ## Reproduction ```ruby array_like = Object.new def array_like.to_ary [:a, :b] end p (1..3).zip(array_like, 10..12) # => [[1, :a, 10], [2, :b, 11], [3, nil, 12]] p (1..3).lazy.zip(array_like).force # => [[1, :a], [2, :b], [3, nil]] p (1..3).lazy.zip(array_like, 10..12).force # => NoMethodError: undefined method 'each' for an Object ``` ## Expected behavior The last expression should return `[[1, :a, 10], [2, :b, 11], [3, nil, 12]]`, matching the eager call. Adding the range should not discard the earlier successful array conversion. If the argument defines both `to_ary` and `each` with different values, the same defect silently uses the `each` values instead of the converted array. ## Affected versions Reproduced on unchanged Ruby master at `da3e1fcb685864a2f58f113e82d9dc67d7fe9197` (Ruby 4.1.0dev) and on Ruby 3.3.1 (`c56cd86388`, arm64-darwin24). ## Cause and patch In `lazy_zip`, converted arguments are accumulated in `ary`. When a later argument does not convert to an Array, the fallback rebuilds `ary` from the original arguments, losing those conversions. Appending the remaining arguments to the converted prefix preserves the behavior of `Enumerable#zip`. Patch and regression tests: https://github.com/ruby/ruby/pull/19063 Both new regression tests fail before the fix (one failure and one error) and pass afterward. They cover conversion precedence, nil padding and repeated enumeration. After rebasing the fix onto master at `6eab8427a849dfe2e121b75faa30a272a8e4a1b3`, the related suites passed: 222 tests and 1,858 assertions (one skip for unavailable `callcc`), plus 439 specification examples with 687 expectations. The full Ruby test suite was not run. I found no matching report in the GitHub all-state and Redmine all-status searches performed. Related #7706 concerns the earlier lazy zip optimization and invalid-argument handling, rather than this conversion-loss case. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126828] [Ruby Bug#22342] IO#gets can ignore the limit argument in some edge cases
by rhenium (Kazuki Yamaguchi) 26 Sep '26

26 Sep '26

Issue #22342 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22342: IO#gets can ignore the limit argument in some edge cases https://bugs.ruby-lang.org/issues/22342 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `io.gets(rs, limit)` ignores the `limit` value and reads until `rs` is found or EOF, if the `limit`-th byte of the stream matches `rs`'s last byte and: 1. The potential start of the record separator, the `limit-rs.bytesize`-th byte of the stream is not at a character boundary ```ruby str = "\x83\\xxx".force_encoding("Windows-31J") # "ソxxx".encode("Windows-31J") IO.pipe("Windows-31J"){|r,w|w.write(str); w.close_write; p r.gets("\\", 2); p r.read} # Expected: "\x{835C}" "xxx" # Actual: "\x{835C}xxx" "" ``` 2. Or, `limit < rs.bytesize` ```ruby IO.pipe{|r,w|w.write("a:bc"); w.close_write; p r.gets(":::", 2); p r.read} # Expected: "a:" "bc" # Actual: "a:bc" "" ``` This behavior appears to date back to Ruby 1.9.x. -- https://bugs.ruby-lang.org/

2 2