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

[ruby-core:126134] [Ruby Feature#22205] Add deprecation warnings for ruby2_keywords
by shugo (Shugo Maeda) 26 Jul '26

26 Jul '26

Issue #22205 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22205: Add deprecation warnings for ruby2_keywords https://bugs.ruby-lang.org/issues/22205 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- # Add deprecation warnings for ruby2_keywords I believe ruby2_keywords should be removed in the future, but removing it now would cause compatibility issues. As a first step, how about adding deprecation warnings to ruby2_keywords? At least the following methods should emit a warning: * Module#ruby2_keywords * main.ruby2_keywords * Proc#ruby2_keywords The following methods are relatively harmless, so it might be better not to warn on them in the first step: * Hash.ruby2_keywords_hash? * Hash.ruby2_keywords_hash ## Background and Motivation While implementing Proc#refined, I noticed that the ruby2_keywords flag on an iseq (param.flags.ruby2_keywords) can be mutated by Proc#ruby2_keywords even when the iseq is shared among multiple Ractors, which is not Ractor-safe. I consider ruby2_keywords a negative legacy, and I would rather deprecate it than fix such behavior. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:126172] Useless Copilot 'comments' (was: Fwd: [ruby/ruby] Reject reopening `false` when assigned to constant (PR #18064))
by Martin J. Dürst 26 Jul '26

26 Jul '26

The amount of mail I get as a Ruby committer is already significant, but lately, it has been getting worse. Copilot is producing additional mails. And most of them are useless: 1) There are the regurgitating mails. See the comment from Earlopain below for why we don't need these. 2) There are the mails that say it has no comment. No actual committer sends such mails. 3) There are the mails that say that it "was unable to review this pull request because the user who requested the review has reached their quota limit.". No actual committer sends out mails e.g. saying they are currently busy with their day job. Can we change the settings so that such emails are not sent anymore? Maybe just switch off Copilot, and have people who think it might produce useful comments activate it manually for specific commits? I don't really care too much about the specifics; any improvement to this situation is welcome. Regards, Martin. -------- Forwarded Message -------- Subject: Re: [ruby/ruby] Reject reopening `false` when assigned to constant (PR #18064) Date: Sat, 25 Jul 2026 02:57:24 -0700 From: Earlopain <notifications(a)github.com> Reply-To: ruby/ruby <reply+AAGHDTMCZMSKXP3WLV2J543K3XQJJEVBNHHQAAAAAEUIY3SX(a)reply.github.com> To: ruby/ruby <ruby(a)noreply.github.com> CC: Subscribed <subscribed(a)noreply.github.com> Earlopain left a comment (ruby/ruby#18064) Thanks to the stochastic model for regurgitating what I have already written in 10x the verbosity, much appreciated. -- Reply to this email directly or view it on GitHub: https://github.com/ruby/ruby/pull/18064#issuecomment-5078055845 You are receiving this because you are subscribed to this thread. Message ID: <ruby/ruby/pull/18064/c5078055845(a)github.com>

1 0

[ruby-core:126160] [Ruby Feature#22212] Add Thread::Backtrace::Location#source_range
by Eregon (Benoit Daloze) 25 Jul '26

25 Jul '26

Issue #22212 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #22212: Add Thread::Backtrace::Location#source_range https://bugs.ruby-lang.org/issues/22212 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ## Motivation The main motivation is to be able to implement `Prism.find(Thread::Backtrace::Location)` precisely and cleanly on any Ruby implementation, in a way which does not depend on implementation details like `node_id`. For that we need the start/end line/column and the `absolute_path`, which is exactly what `Ruby::SourceRange` provides. In https://bugs.ruby-lang.org/issues/21998 we added `source_range` for `{Method,UnboundMethod,Proc}`. However we also need `source_range` for `Thread::Backtrace::Location` as this is used in `error_highlight`, `power_assert`, etc. Those tools currently use `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(Thread::Backtrace::Location)`, however: * that's a CRuby-only experimental API * it exposes CRuby internals (`node_id`) * it adds a lot of complexity for all usages because they need to handle both `Prism::Node` and `RubyVM::AbstractSyntaxTree::Node`. We solve all of this by adding a new portable API which exposes universal concepts like line and column, which are stable to find AST nodes. ## Implementation How can we get the start/end line/column when we only keep the start line in CRuby? By re-parsing, and specifically by re-parsing with *exactly* the same parser that the interpreter used to compile to bytecode. That way there is no issue of using different Prism versions, it's the Prism C library built in CRuby, or `parse.y` in `--parser=parse.y` mode. Either way, we reparse to extract the start/end line/column. We make the returned start/end line/column match for both `Prism` and `parse.y`, in practice the only difference is for calls with blocks, where we adapt the location from parse.y to match Prism. One can then easily use Prism to get a node matching that `Ruby::SourceRange` and use the resulting `Prism::Node` as they wish. This also means all versions of Prism can be used, and for example if some dependency requires some specific version of Prism it works fine and is not a problem. As a result, the user of this API can choose the Prism version they want and always get a `Prism::Node` (and not having to handle `RubyVM::AbstractSyntaxTree::Node` too, or a duplicate `Ruby::Node` API as mentioned in #21795). PR: https://github.com/ruby/ruby/pull/18043 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126167] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by Dan0042 (Daniel DeLorme) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by Dan0042 (Daniel DeLorme). ### 1. Object, block, and Enumerator forms Imho there are two options here a) If block form is supported, the offset is a keyword argument. It was not requested by the OP (also not in my duplicate #19177), but it's more versatile and future-proof. Although it introduces incompatibility due to keyword extension (described below) ```ruby index(object, offset: 0) index(offset: 0){ |element| ... } index(offset: 0) ``` b) If block form is not supported, the offset should be a positional argument, for consistency and duck-typing with String#index It's more limited, and makes it hard to add offset to block form in the future. ```ruby index(object, offset = 0) ``` Overall a) seems better to me, even if not fully consistent with String#index ### 2. Compatibility with searching for a Hash Ah yes, this is the standard problem with [keyword extension](#14183#note-29) What would happen with this code? ```ruby [{ key: 2 }].index(key: 2) ``` Will it now raise "unknown keyword: :key" ? ### 3. Semantics of `Array#rindex` > I think the corresponding Array behavior should be: > > ```ruby > [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 > ``` 100% agree. ### 4. Boundary and conversion behavior > Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? In general I would say yes, simply because having consistency for this reduces gotchas and footguns. But I'm not sure about this behavior of String: ```ruby "0aaaaaaaaaa9".rindex("a", 999) #=> 10 "0aaaaaaaaaa9".index("a", -999) #=> nil ``` To me, these two results are inconsistent and I feel like the last case should return 1. Should Array#index follow the same pattern or not? ```ruby [:a, :b, :a, :b, :a].index(:a, offset: -100) #=> nil (like String#index) or 0 ? ``` ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118233 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126166] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by nobu (Nobuyoshi Nakada) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by nobu (Nobuyoshi Nakada). Status changed from Closed to Open I think we should reopen this issue and clarify the API before fixing the implementation. There are several API details that I think need to be decided explicitly. ## Issues to clarify ### 1. Object, block, and Enumerator forms The discussion in #note-7 and #note-8 explicitly considered using an offset with the block form: ```ruby array.index(offset: 10) { |element| ... } ``` However, the reverted implementation only handled `offset:` when an object was given. The following calls raised `ArgumentError`, despite the documented Enumerator signatures: ```ruby array.index(offset: 2) array.index(offset: 2) { |element| ... } array.rindex(offset: -2) array.rindex(offset: -2) { |element| ... } ``` Should all three forms accept `offset:`? ```ruby array.index(object, offset: 2) array.index(offset: 2) { |element| ... } array.index(offset: 2) # => Enumerator ``` The same question applies to `Array#rindex`. Since `Array#find_index` is an alias of `Array#index`, it should have exactly the same behavior. If the block form accepts `offset:`, the Enumerator form should retain the keyword argument so that calling `each` performs the same search. ### 2. Compatibility with searching for a Hash Before this feature, the following searches for the Hash `{ offset: 2 }`: ```ruby [{ offset: 2 }].index(offset: 2) # => 0 ``` If a keyword-only call now means the block/Enumerator form, this behavior changes. Searching for the Hash would still be possible with explicit braces: ```ruby [{ offset: 2 }].index({ offset: 2 }) # => 0 ``` Is this compatibility change acceptable? The same ambiguity exists when a block is given. Previously the keyword-like Hash was the object and the block was ignored with a warning. ### 3. Semantics of `Array#rindex` The reverted implementation did not behave like `String#rindex`. It also documented the signature as `rindex(object, offset: nil)`, but an explicit `nil` was not accepted: ```ruby array.rindex(object, offset: nil) # => TypeError: no implicit conversion of nil into Integer ``` In the implementation, `nil` was only used internally to represent an omitted keyword. Documenting `offset: nil` makes it look like `nil` is an accepted default value. For an Array, `offset: -1` would express the actual default starting position while keeping an explicit `nil` invalid. `String#rindex(pattern, offset)` starts searching backward at `offset`. A non-negative offset is an absolute position. A negative offset is relative to the end. An offset greater than the string length is clamped to the end. For example: ```ruby "ababa".rindex("a", 2) # => 2 "ababa".rindex("a", -2) # => 2 "ababa".rindex("a", 100) # => 4 ``` I think the corresponding Array behavior should be: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 ``` The reverted implementation instead treated a non-negative offset as the lower bound of a search starting at the end: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 4 ``` This makes positive and negative offsets have different meanings and is not consistent with `String#rindex`. Should `Array#rindex` follow `String#rindex` exactly? ### 4. Boundary and conversion behavior Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? - Negative offsets relative to the end - An offset smaller than `-array.size` - An offset equal to `array.size` - An offset greater than `array.size` - Objects accepted through numeric conversion - Explicit `nil` - Integers too large for the internal index type These should be specified and tested for both forward and backward searches. ## Proposed signatures If the above behavior is intended, the signatures would be: ```ruby index(object, offset: 0) -> integer or nil index(offset: 0) { |element| ... } -> integer or nil index(offset: 0) -> Enumerator find_index(object, offset: 0) -> integer or nil find_index(offset: 0) { |element| ... } -> integer or nil find_index(offset: 0) -> Enumerator rindex(object, offset: -1) -> integer or nil rindex(offset: -1) { |element| ... } -> integer or nil rindex(offset: -1) -> Enumerator ``` The implementation has been reverted. Once these points are agreed, I think we should add specs for the complete behavior before reimplementing it. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118232 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126165] [Ruby Feature#22213] Allow no-argument and chained calls of Proc#refined
by shugo (Shugo Maeda) 25 Jul '26

25 Jul '26

Issue #22213 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22213: Allow no-argument and chained calls of Proc#refined https://bugs.ruby-lang.org/issues/22213 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract Currently, `Proc#refined` rejects no-argument and chained calls, because I wasn't sure what the desired behavior should be. How about returning the receiver for no-argument calls: ```ruby original = -> {} refined = original.refined p refined.equal?(original) #=> true ``` and activating all the given modules for chained calls? ```ruby module M refine String do def shout = upcase + "!" end end module M2 refine Integer do def doubled = self * 2 end end original = ->(s, i) { [s.shout, i.doubled] } refined = original.refined(M).refined(M2) # the same result as original.refined(M, M2) refined.call("hi", 3) #=> ["HI!", 6] ``` ## Motivation This change is necessary to make `Proc#refined` composable. A no-argument call of `Proc#refined` is a no-op, but it's useful when the arguments are calculated at runtime: ```ruby def foo(prc, *modules) ... refined = prc.refined(*modules) ... end ``` If an empty module list were rejected, a guard like `unless modules.empty?` would be needed. A chained call of `Proc#refined` is useful to extend existing DSLs: ```ruby require "packrat_parser" require "mathn" class MathParser < PackratParser def define(sym, &block) # PackratParser#define also calls Proc#refined super(sym, &block.refined(Math::N)) end end parser = MathParser.new { ... define :multitive do [:primary, "*", :multitive].map { |x, _, y| x * y } | [:primary, "/", :multitive].map { |x, _, y| x / y } | :primary end ... } parser.parse("1 / 2") #=> (1/2) ``` ## Formal semantics With this proposal, `Proc#refined` can be formalized as a monoid action on Procs created from a block, where the acting monoid is the sequences of modules under concatenation, with the empty sequence as its unit. Writing ≃ for behavioral equivalence, the action satisfies the unit and associativity laws: ``` prc.refined ≃ prc # unit law prc.refined(*ms).refined(*ns) ≃ prc.refined(*ms, *ns) # associativity law ``` Note that the unit law holds for any Proc, since `refined` with no modules returns the receiver itself. I've written a formalization in the Rocq Prover: https://github.com/shugo/ruby-refinements-semantics It abstracts away the details irrelevant to refinements. ## Design decisions ### The receiver or a copy for no-argument calls Returning a copy was also considered, but I chose to return the receiver, following precedents such as `Data#with` and `Enumerator::Lazy#lazy`. Mutable containers tend to return a copy even for a no-op, but `Proc#refined` is closer to the former group. ### Extend or replace for chained calls If a chained call replaced the receiver's refinements instead of extending them, `prc.refined(M).refined(M2)` would activate only `M2`. That breaks the associativity law above, and makes chaining useless for the DSL case in Motivation. Extending also matches nested `using`, where refinements activated later take precedence. ## Implementation Pull request: https://github.com/ruby/ruby/pull/18052 `Proc#refined` on an already refined Proc is not memoized: the cache would be keyed on short-lived copies, and entries are retained for the VM's lifetime, so it would grow without bound. A performance warning is emitted under `Warning[:performance] = true`, and passing all the modules in a single call is more efficient. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 25 Jul '26

25 Jul '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 19

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 25 Jul '26

25 Jul '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

6 26

[ruby-core:126156] [Ruby Bug#22210] Check if issue #19969 is still reproducible / re-opened in 4.0.x
by saka_omo (Yuki Takei) 24 Jul '26

24 Jul '26

Issue #22210 has been reported by saka_omo (Yuki Takei). ---------------------------------------- Bug #22210: Check if issue #19969 is still reproducible / re-opened in 4.0.x https://bugs.ruby-lang.org/issues/22210 * Author: saka_omo (Yuki Takei) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi team, I am writing to ask if Bug #19969 might still be reproducible in the current version of Ruby. Could you please check if the issue is still present or if a regression has occurred? I ran the reproduction script from #19969 across several Ruby versions on macOS (arm64-darwin), and while Ruby 3.2.4 fixed the high memory consumption (dropping to 29 MiB), Ruby 4.0.5 spikes back up to 2215 MiB. ``` ruby ruby -v -rset -e 's1 = Set.new(10000.times); s2 = Set.new(9999.times); Array.new(10000) { s1 - s2 - [0] }; puts "#{`ps -o rss= -p #{$$}`.to_i / 1024} MiB"' ``` Results across versions: ``` ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [arm64-darwin22] 183 MiB ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] 2364 MiB ruby 3.2.4 (2024-04-23 revision af471c0e01) [arm64-darwin22] 29 MiB ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin24] 2215 MiB ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126158] [Ruby Bug#22211] Fiber::Scheduler stalls on Ractor::Port.receive
by rkh (Konstantin Haase) 24 Jul '26

24 Jul '26

Issue #22211 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22211: Fiber::Scheduler stalls on Ractor::Port.receive https://bugs.ruby-lang.org/issues/22211 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-24T12:18:38Z master 180b664bd9) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Quickly upfront: This might be a duplicate of #20276, and let me know if the official solution is still to launch a thread for each port so it can block (or add some more complex thread orchestration). Anyway, I think `Ractor::Port#receive` should call `Fiber::Scheduler#block`/`Fiber::Scheduler#unblock` if a scheduler is set (or some other hook), the way that `Thread::Queue` does. Instead, it completely blocks the scheduler. Example to reproduce: ``` ruby Warning[:experimental] = false class Scheduler def initialize @fiber = Fiber.current @blocked = Set.new @ready = Queue.new end def scheduler_close @ready.pop.transfer while @blocked.any? end def block(blocker, timeout = nil) raise NotImplementedError, "block: timeout not supported" if timeout @blocked << Fiber.current @fiber.transfer ensure @blocked.delete(Fiber.current) end def unblock(blocker, fiber) = @ready << fiber def io_write(io, buffer, offset, length) = Thread.new { buffer.write(io, offset, length) }.value def fiber(&) = Fiber.new(blocking: false, &).tap(&:transfer) def respond_to_missing?(...) = true def method_missing(method, ...) = raise NotImplementedError, "#{method}: not implemented" end Fiber.set_scheduler(Scheduler.new) # This would work: # # queue = Queue.new # Fiber.schedule { puts queue.pop } # queue.push "Hello from Queue!" port = Ractor::Port.new Fiber.schedule { puts port.receive } port.send("Hello from Ractor::Port!") # never gets here ``` -- https://bugs.ruby-lang.org/

1 0