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

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 06 Mar '26

06 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121627] [Ruby Feature#21264] Extract Date library from Ruby repo in the future
by hsbt (Hiroshi SHIBATA) 06 Mar '26

06 Mar '26

Issue #21264 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- Note: This is not for Ruby 3.5. `Date` and `DateTime` has no primary maintainer in 10+ years. I would like to deprecate `date` via bundled gems for reducing our maintenance time especially @nobu. But `Time.prase` and `Time.strptime` are widely used now. How do we deprecate `date` library? 1. Migrate `Date._strptime`, `Date.strptime` and `Date._parse` to `Time`. The current `Date` is migrated as bundled gems. 2. Migrate `Date` to the bundled gems. `Time.parse` and `Time.strptime` warns if `date` is not found. 3. Keep the current situation 4. ... Does anyone have another idea? -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124928] [Ruby Feature#21943] Add StringScanner#get_int to extract capture group as Integer without intermediate String
by jinroq (Jinroq SAITOH) 06 Mar '26

06 Mar '26

Issue #21943 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21943: Add StringScanner#get_int to extract capture group as Integer without intermediate String https://bugs.ruby-lang.org/issues/21943 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- ## Motivation The date library is being [rewritten from C to pure Ruby](https://github.com/ruby/date/pull/155). During this effort, `Date._strptime` was identified as a major performance bottleneck. Profiling revealed that the root cause is the overhead of extracting capture groups as Strings and then converting them to Integers: ``` sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i # allocates String "2024", converts to Integer, discards String mon = sc[2].to_i # allocates String "06", converts to Integer, discards String mday = sc[3].to_i # allocates String "15", converts to Integer, discards String ``` Each `sc[n].to_i` call allocates a temporary String object that is immediately discarded. When parsing dates, only the integer values are needed — the intermediate Strings serve no purpose. In the C implementation of date, matched byte ranges are converted directly to integers without any String allocation. The pure Ruby version cannot do this with the current StringScanner API. ## Proposal Add `StringScanner#get_int(index`) that returns the captured substring at the given index as an Integer, converting directly from the matched byte range at the C level without allocating an intermediate String object. ``` scanner = StringScanner.new("2024-06-15") scanner.scan(/(\d{4})-(\d{2})-(\d{2})/) scanner.get_int(1) # => 2024 scanner.get_int(2) # => 6 scanner.get_int(3) # => 15 ``` It returns `nil` in the same cases where `scanner[index]` would return `nil` (no match, index out of range, optional group did not participate). ## Use case The primary use case is `Date._strptime` in the pure Ruby date library. The fast path for `%Y-%m-%d` format currently does: ``` # Current: 3 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i mon = sc[2].to_i mday = sc[3].to_i ``` With `get_int`: ``` # Proposed: 0 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc.get_int(1) mon = sc.get_int(2) mday = sc.get_int(3) ``` This pattern appears throughout `_strptime` for every date/time component (`%H`, `%M`, `%S`, `%m`, `%d`, etc.), so the cumulative impact is significant. ## Benchmark Environment: Ruby 4.0.1, x86_64-linux | Operation | i/s | per iteration | Comparison | | :--- | :--- | :--- | :--- | | **sc.get_int(n)** | 1,029,041.7 | 971.78 ns/i | (Reference) | | **sc[n].to_i** | 791,945.6 | 1.26 μs/i | 1.30x slower | `get_int` is 1.30x faster than `sc[n].to_i` for a typical date parsing scenario (3 capture groups). The improvement comes from eliminating 3 temporary String allocations per call. In the context of `Date._strptime("%Y-%m-%d")`, this overhead is a significant portion of the total parse time, as shown in earlier profiling: | Operation | Time | | :--- | :--- | | C ext `_strptime` (reference) | 408 ns | | SC.new + scan + captures + `.to_i` x3 | 1,210 ns | | Pure Ruby `_strptime_ymd` total | 1,290 ns | The capture extraction + `.to_i` conversion accounts for roughly 40% of the total parse time. `get_int` directly reduces this portion. ## Implementation A working implementation is available. It reuses the same index resolution logic as `StringScanner#[]` (including negative indices) but calls `rb_cstr2inum` on the matched byte range instead of `extract_range`, avoiding String object allocation entirely. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124933] [Ruby Bug#21944] "Cannot allocate memory" with M:N threads or Ractors on a low RAM Linux machine
by jhawthorn (John Hawthorn) 05 Mar '26

05 Mar '26

Issue #21944 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21944: "Cannot allocate memory" with M:N threads or Ractors on a low RAM Linux machine https://bugs.ruby-lang.org/issues/21944 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- Linux default overcommit policy (`vm.overcommit_memory=0`) will fail for allocations which are "obvious overcommits" (https://www.kernel.org/doc/html/latest/mm/overcommit-accounting.html) Under M:N threading (including under Ractors) we allocate a ~512MB section of RAM to use (the physical pages are lazily mapped in when used). This caused the following exception on a machine with <512 MB of RAM. ``` Thread#initialize': can't create Thread: Cannot allocate memory (ThreadError) ``` This can be solved by initially mapping the region of memory in as protected, and only enabling read/write the first time a stack is used. We already added a guard page the first time a stack was used, so this just inverts that mprotect call (it also makes two calls instead of one, but since these are only used the first time a stack is used, I think that simplicity is worth the extra syscall). https://github.com/ruby/ruby/pull/16232 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124895] [Ruby Feature#21930] Add Ractor#empty? method to check for pending messages without blocking
by synacker (Mikhail Milovidov) 05 Mar '26

05 Mar '26

Issue #21930 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21930: Add Ractor#empty? method to check for pending messages without blocking https://bugs.ruby-lang.org/issues/21930 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** In concurrent Ractor‑based architectures, there’s a critical need to check whether a Ractor has pending messages without blocking. Currently, this is not possible with the standard API **Motivation** The Ractor API provides a powerful mechanism for communication between system OS threads. However, in high‑load systems that use cooperative multitasking, the current Ractor#receive method presents limitations: * It blocks the current thread until a message arrives. * It doesn’t offer a non‑blocking way to check the message queue. * This makes it difficult to integrate Ractors with cooperative scheduling frameworks (e.g., Async, Fiber‑based systems). As a result, developers must either: * Accept thread blocking (hurting responsiveness). * Implement complex workarounds with timeouts or auxiliary queues. **Proposed solution** Add Ractor#empty? to the Ractor API. The method should: * Return true if there are no pending messages in the Ractor’s main queue. * Return false if there is at least one message available for processing. * Not block the calling thread under any circumstances. * Be safe to call from any Ractor (including the current one). **Demonstration code** Below is a proof‑of‑concept showing how Ractor#empty? enables cooperative multitasking with the Async gem: ``` require 'async' class TimeCommand attr_reader :id def initialize(id) @id = id end def task 1.upto(3) do |i| sleep(1) puts "[cmd #{@id}] step #{i} @ #{Time.now}" end end end class Worker def initialize @ractor = Ractor.new do loop do Sync do |task| in_queue = Async::Queue.new queue_task = task.async do |subtask| while command = in_queue.dequeue subtask.async do |child_task| command.task end end end task.async(transient: true) do |main_task| loop do commands = [] if queue_task.children? || !in_queue.empty? main_task.yield commands.append Ractor.receive while !Ractor.current.empty? else commands.append Ractor.receive end unless commands.empty? puts "Worker received batch of #{commands.size} commands." commands.each { |command| in_queue.enqueue(command) } end end end end end end end def send(command) @ractor.send(command, move: true) end def wait @ractor.join end end worker = Worker.new 1000.times do |i| 100.times do |j| worker.send TimeCommand.new(i * 10 + j) end sleep(1) end worker.wait ``` **Key observations:** With Ractor#empty?, developers can: * Integrate Ractors with cooperative multitasking frameworks (e.g., Async) more naturally. * Avoid thread blocking when checking for incoming messages. * Batch process messages efficiently (collect all pending messages in one go). * Improve responsiveness in high‑concurrency scenarios by yielding control back to the scheduler when no work is available. **Benefits** * Enables better integration with modern Ruby concurrency tools. * Reduces need for complex workarounds. * Improves performance in message‑driven architectures. * Maintains Ractor’s thread‑safety guarantees. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:124924] [Ruby Feature#21942] Allow reading class variables from non-main Ractors
by tenderlovemaking (Aaron Patterson) 04 Mar '26

04 Mar '26

Issue #21942 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21942: Allow reading class variables from non-main Ractors https://bugs.ruby-lang.org/issues/21942 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- It's very common in Rails applications to use class variables, and today class variables aren't even allowed to be read inside a Ractor: ```ruby class Foo # This is NOT allowed to be read in non-main Ractors @@bar = 123 def self.bar; @@bar; end # This is allowed to be read in non-main Ractors @baz = 123 def self.baz; @baz; end end # This is OK Ractor.new { p Foo.baz }.value # Exception here Ractor.new { p Foo.bar }.value ``` Output is like this: ``` test.rb:4:in 'Foo.bar': can not access class variables from non-main Ractors (@@bar from Foo) (Ractor::IsolationError) from test.rb:10:in 'block in <main>' ``` Can we allow shareable values to cross the Ractor boundary, similar to class instance variables? Just for reference, the Rails code in question is [here](https://github.com/rails/rails/blob/371cbc9711b0b1fdadc186739c507b88e…. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124914] [Ruby Bug#21939] UPLOADTEST1772572871
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21939 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21939: UPLOADTEST1772572871 https://bugs.ruby-lang.org/issues/21939 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- tmp -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124913] [Ruby Bug#21938] [sec-test] html-upload-1772572676
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21938 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21938: [sec-test] html-upload-1772572676 https://bugs.ruby-lang.org/issues/21938 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- html upload probe ---Files-------------------------------- probe.html (73 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124912] [Ruby Bug#21936] [sec-test] file-upload-1-1772572612
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21936 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21936: [sec-test] file-upload-1-1772572612 https://bugs.ruby-lang.org/issues/21936 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- upload test 1 ---Files-------------------------------- normal-probe.txt (14 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124911] [Ruby Bug#21937] [sec-test] file-upload-2-1772572613
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21937 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21937: [sec-test] file-upload-2-1772572613 https://bugs.ruby-lang.org/issues/21937 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- upload test 2 ---Files-------------------------------- traversal-probe.txt (14 Bytes) -- https://bugs.ruby-lang.org/

1 0