ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

May 2026

  • 1 participants
  • 128 discussions
[ruby-core:124950] [Ruby Bug#21947] `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use.
by ioquatix (Samuel Williams) 09 May '26

09 May '26
Issue #21947 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21947: `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use. https://bugs.ruby-lang.org/issues/21947 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following example executes successfully after 7 seconds instead of timing out after 2. ```ruby require 'async' require 'net/http' start = Time.now Sync do Timeout.timeout 2 do Net::HTTP.get(URI 'https://httpbin.org/delay/5') puts "...request finished, no timeout though; in #{Time.now - start}s" end end puts "Duration: #{Time.now - start}s" # => ...request finished, no timeout though; in 7.7007s # Duration: 7.700962s ``` There are two issues: - `Net::HTTP` rescues `Timeout::Error` and retries. This causes 2s (timeout -> retry) + 5s execution time. - `Timeout.timeout` uses `Timeout::ExitException` when no exception is specified, but the Fiber scheduler code path was not updated. See <https://github.com/socketry/async/issues/448> for more discussion. -- https://bugs.ruby-lang.org/
3 4
0 0
[ruby-core:124920] [Ruby Bug#21941] Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure
by nicholasdower (Nick Dower) 09 May '26

09 May '26
Issue #21941 has been reported by nicholasdower (Nick Dower). ---------------------------------------- Bug #21941: Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure https://bugs.ruby-lang.org/issues/21941 * Author: nicholasdower (Nick Dower) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code results in the `read` local variable becoming nil, even though it is never reassigned: ``` def run fork_safe = ->(t) { t } RubyVM::YJIT.enable read, wakeup = IO.pipe Signal.trap("SIGCHLD") { wakeup.write("!") } begin while true begin fork { exit } next if read.wait_readable rescue Interrupt end end ensure end end run ``` Error: ``` repro.rb:13:in 'Object#run': undefined method 'wait_readable' for nil (NoMethodError) next if read.wait_readable ^^^^^^^^^^^^^^ from repro.rb:21:in '<main>' ``` See also: https://github.com/puma/puma/issues/3620 https://github.com/Shopify/ruby/issues/625 -- https://bugs.ruby-lang.org/
5 5
0 0
[ruby-core:125235] [Ruby Bug#21991] `$!` stays as the first exception in Ruby Box
by tikkss (Tsutomu Katsube) 08 May '26

08 May '26
Issue #21991 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #21991: `$!` stays as the first exception in Ruby Box https://bugs.ruby-lang.org/issues/21991 * Author: tikkss (Tsutomu Katsube) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Description --- When Ruby Box is enabled (`RUBY_BOX=1`), `$!` inside `rescue` does not change after the first exception. `$!` is expected to show the exception for each `rescue` block, but it always shows the first one. Steps to reproduce --- ```ruby # test.rb begin raise "First error" rescue pp $! end begin raise "Second error" rescue pp $! end begin raise "Third error" rescue pp $! end ``` Expected result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Actual result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: First error> #<RuntimeError: First error> ``` Additional information --- This issue does not reproduce when `RUBY_BOX=1` is not set: ```console $ ruby test.rb #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Also, this issue does not reproduce when the exception object is captured explicitly in the `rescue` clause: ```ruby # test.rb begin raise "First error" rescue => e pp e end begin raise "Second error" rescue => e pp e end begin raise "Third error" rescue => e pp e end ``` ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` -- https://bugs.ruby-lang.org/
2 2
0 0
[ruby-core:125397] [Ruby Bug#22021] Array#delete_if may delete wrong object if array has been altered already
by chucke (Tiago Cardoso) 05 May '26

05 May '26
Issue #22021 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22021: Array#delete_if may delete wrong object if array has been altered already https://bugs.ruby-lang.org/issues/22021 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The simplest example I can come up with: ```ruby $ar = ar = [1, 2, 3, 4, 5] def delete_at(i) $ar.delete(i) end ar.delete_if { |i| i == 2 ? (delete_ar(i) && true) : false } ar #=> [1, 4, 5], and it should be [1, 3, 4, 5] ``` -- https://bugs.ruby-lang.org/
2 4
0 0
[ruby-core:125403] [Ruby Bug#22023] Backport commits cba70c3532c34803bae065745b799103635ec67a and cfdca23bfecb5fb74fd31128ac37d734d8e7e43b
by byroot (Jean Boussier) 05 May '26

05 May '26
Issue #22023 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22023: Backport commits cba70c3532c34803bae065745b799103635ec67a and cfdca23bfecb5fb74fd31128ac37d734d8e7e43b https://bugs.ruby-lang.org/issues/22023 * Author: byroot (Jean Boussier) * Status: Closed * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- - Fix passing frozen_string_literal option to #compile_file backed by Prism: https://github.com/ruby/ruby/pull/16779 - ISeq.compile_file was not switching on parser: https://github.com/ruby/ruby/pull/16463 -- https://bugs.ruby-lang.org/
2 3
0 0
[ruby-core:125377] [Ruby Bug#22018] ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage
by byroot (Jean Boussier) 05 May '26

05 May '26
Issue #22018 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22018: ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage https://bugs.ruby-lang.org/issues/22018 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction: ```ruby require "coverage" File.write("/tmp/a.rb", <<~RUBY) module CoverableRaw def self.call "cover up" end end CoverableRaw.call RUBY Coverage.start require "/tmp/a.rb" p Coverage.result File.write("/tmp/b.rb", <<~RUBY) module Coverable def self.call "cover up" end end Coverable.call RUBY class RubyVM::InstructionSequence def self.load_iseq(path) compile_file(path) end end Coverage.start require "/tmp/b.rb" p Coverage.result ``` Expected: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {"/tmp/b.rb" => [1, 1, 1, nil, nil, nil, 1]} ``` Actual: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {} ``` Patch: https://github.com/ruby/ruby/pull/16805 -- https://bugs.ruby-lang.org/
2 3
0 0
[ruby-core:125396] [Ruby Bug#22020] Inner call node without all arguments returned by RubyVM::AbstractSyntaxTree.of for call with a block
by Eregon (Benoit Daloze) 04 May '26

04 May '26
Issue #22020 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22020: Inner call node without all arguments returned by RubyVM::AbstractSyntaxTree.of for call with a block https://bugs.ruby-lang.org/issues/22020 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby begin foo(1, 2, kw: :arg) { 42 } rescue => e pp RubyVM::AbstractSyntaxTree.of e.backtrace_locations[0] end ``` ``` $ ruby --parser=parse.y rubyvm_ast_node_id_loc.rb (FCALL@2:2-2:21 :foo (LIST@2:6-2:20 (INTEGER@2:6-2:7 1) (INTEGER@2:9-2:10 2) (HASH@2:12-2:20 (LIST@2:12-2:20 (SYM@2:12-2:15 :kw) (SYM@2:16-2:20 :arg) nil)) nil)) ``` That covers `foo(1, 2, kw: :arg)` so all arguments except the block argument, which looks inconsistent. I believe it should be: ``` $ ruby --parser=parse.y rubyvm_ast_node_id_loc.rb (ITER@2:2-2:28 (FCALL@2:2-2:21 :foo (LIST@2:6-2:20 (INTEGER@2:6-2:7 1) (INTEGER@2:9-2:10 2) (HASH@2:12-2:20 (LIST@2:12-2:20 (SYM@2:12-2:15 :kw) (SYM@2:16-2:20 :arg) nil)) nil)) (SCOPE@2:22-2:28 tbl: [] args: nil body: (INTEGER@2:24-2:26 42))) ``` PR: https://github.com/ruby/ruby/pull/16836 -- https://bugs.ruby-lang.org/
1 2
0 0
[ruby-core:125398] [Ruby Bug#22022] Refinement zsuper problems when referenced method changes
by jeremyevans0 (Jeremy Evans) 04 May '26

04 May '26
Issue #22022 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22022: Refinement zsuper problems when referenced method changes https://bugs.ruby-lang.org/issues/22022 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found many problems with refinement zsuper methods. Here's one example: ```ruby module M private def a = :a alias a a end class A include M end class B < A end module R refine B do public :a end end using R B.new.a # false() function is unimplemented on this machine (NotImplementedError) ``` Here's another: ```ruby class A private def a = :a end module R refine A do public :a end end using R A.new.a # => :a module M def a = :b end A.prepend M A.new.a # SystemStackError: stack level too deep ``` The problematic cases are in general can be broken down into: * Method being redefined (in same or closer ancestor) * Method being removed * Method being undef-ed (in same or closer ancestor) * Method being overridden by method in included module * Method being overridden by method in prepended module * Method being defined in an included/prepended module at time of refinement In addition to the `NotImplementedError` and `SystemStackError`, there are other cases where incorrect results are given. One possible approach for fixing this is to turn the zsuper methods into regular methods that call super . This fixes all cases that I found. This is not a perfect solution, due to mildly worse performance (I'm guessing) as well as arity/parameters for the method not as helpful. It may possible to avoid these issues by clearing method caches in more cases. However, I think that would require a lot of extra work, since you cannot just clear the method cache for the current class. You would need to clear it for all subclasses, if this is a module, do the same for all classes that include/prepend the module, as well as any subclasses of those classes. Considering the need for refinement zsuper methods is very rare, the performance and arity/parameters issues seem acceptable (to me). Pull request: https://github.com/ruby/ruby/pull/16844 -- https://bugs.ruby-lang.org/
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 10
  • 11
  • 12
  • 13
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.