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

[ruby-core:116664] [Ruby master Misc#20254] FYI: Add Launchable into Ruby CI
by ono-max (Naoto Ono) 29 Feb '24

29 Feb '24

Issue #20254 has been reported by ono-max (Naoto Ono). ---------------------------------------- Misc #20254: FYI: Add Launchable into Ruby CI https://bugs.ruby-lang.org/issues/20254 * Author: ono-max (Naoto Ono) * Status: Open * Priority: Normal * Assignee: ono-max (Naoto Ono) ---------------------------------------- Ruby core team has granted me (Naoto Ono) the permission to integrate [Launchable](https://www.launchableinc.com/) into ruby/ruby. This decision was made during [the meeting](https://chouseisan.com/s?h=4d6c803c3ea1492b9b61de0ea7668255). Thus, I have created the ticket to share the benefit and progress. ## Progress Currently, both ruby/debug and ruby/vscode-rdbg has started using Launchable. ## Benefits By introducing Launchable, we can enjoy the following benefits: ### Rich UI to see stderr and stdout in failed tests Some Ruby developers find it challenging to review test failure logs in Github Actions. Launchable provides a rich UI that makes it easier to examine stderr and stdout related to test failure. <img width="600" alt="Screenshot 2024-01-29 at 19 23 08" src="https://github.com/ruby/debug/assets/59436572/68f52a50-8e96-4f7f-861d-2dc09…"> ### Test reports in Github comments Identifying which CI job failed in the Github UI can be cumbersome. Launchable addresses this by creating a comment that summarizes test results directly in Github pull request. This enhancement will significantly improve the development experiment. <img width="500" alt="Test reports in Github comments" src="https://github.com/ruby/debug/assets/59436572/283b27d6-7b43-40bf-b423-8bb94…"> ### Flakey test insight By developing Ruby, some flakey tests might be added. Launchable has [Unhealthy Tests](https://www.launchableinc.com/docs/features/unhealthy-tests/) page which analyze the flakey tests. For instance, the page shows the flakiness score which express how much the test is flakiness. Let's say `foo` test has a flakiness score of 0.5. This means that if `foo` test failed against 10 different commits, that failure was not a true failure in half of the commits. By seeing this graph, we can prioritize which tests that we have to deal with. In addition to that, we can understand the test is flakey or not. <img width="700" alt="Flakey test page" src="https://github.com/ruby/debug/assets/59436572/ca9f972e-9744-40b9-92a2-353b5…"> ### Predictive Test Selection Ruby has an extensive suite of tests, and the number of tests is expected to grow. However, waiting for all tests to pass can be time-consuming. To address this challenge, Launchable offers the [Predictive Test Selection](https://www.launchableinc.com/docs/features/predictive-test-sele… feature. Predictive Test Selection leverages machine learning to identify the right tests to run for a specific code change. By analyzing data from past test runs and considering the changes being tested, Launchable determines which tests are most relevant. Here is a execution strategy with Launchable. 1. Initial Selection Launchable selects a subset of tests (let's say approximately 25% of all tests) based on the predictive analysis. These tests are executed, first. 2. Remaining Tests The remaining of 75% of tests are then executed. Since the initial selection focuses on potentially problematic areas, there's a high likelihood of identifying any failed tests sooner. -- https://bugs.ruby-lang.org/

7 17

[ruby-core:116996] [Ruby master Bug#20313] Backport RUBY_YJIT_ENABLE PR https://github.com/ruby/ruby/pull/7208
by andclt (Andrea Culot) 29 Feb '24

29 Feb '24

Issue #20313 has been reported by andclt (Andrea Culot). ---------------------------------------- Bug #20313: Backport RUBY_YJIT_ENABLE PR https://github.com/ruby/ruby/pull/7208 https://bugs.ruby-lang.org/issues/20313 * Author: andclt (Andrea Culot) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Backporting "Make sure RUBY_YJIT_ENABLE only enables YJIT for truthy values" PR https://github.com/ruby/ruby/pull/7208 to Ruby 3.2 I opened a PR here: https://github.com/ruby/ruby/pull/10125 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116969] [Ruby master Bug#20308] `it` and numbered parameters do not work in `eval`
by kddnewton (Kevin Newton) 27 Feb '24

27 Feb '24

Issue #20308 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20308: `it` and numbered parameters do not work in `eval` https://bugs.ruby-lang.org/issues/20308 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am not sure if this is a purposeful restriction or not, so I apologize if this is not a "bug" per se. Currently if you use `it` or `_1` (numbered parameters) in `eval` they do not work with `compile.c`: ``` irb(main):001> 1.tap { eval("_1") } (eval):1:in `block in <top (required)>': undefined local variable or method `_1' for main:Object (NameError) Did you mean? _ ``` They work accidentally with prism because I didn't know this wasn't allowed. Is it a bug? Or is this on purpose? -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116902] [Ruby master Feature#20290] Add API for C extensions to free memory
by peterzhu2118 (Peter Zhu) 26 Feb '24

26 Feb '24

Issue #20290 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #20290: Add API for C extensions to free memory https://bugs.ruby-lang.org/issues/20290 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/10055 Ticket #19993 added the new feature RUBY_FREE_AT_EXIT, which frees memory in Ruby at shutdown. This allowed tools like Valgrind, ASAN, and macOS leaks to find memory leaks in Ruby without a large number of false-positives outputted. However, this feature is not complete for C extensions, as they may also need to free their memory and there was no way to do so. This means that C extensions might not be able to directly use tools like Valgrind, ASAN, or macOS leaks to find memory leaks. This ticket proposes an API for C extensions to free memory by defining a function called `Destruct_<extension name>` that is called during shutdown when RUBY_FREE_AT_EXIT is enabled. This name mirrors the `Init_<extension name>` API that already exists for extension initialization. However, unlike the `Init_<extension name>` function, `Destruct_<extension name>` is NOT mandatory for the C extension to implement so that we can preserve backwards compatibility. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:116957] [Ruby master Feature#17342] Hash#fetch_set
by Dan0042 (Daniel DeLorme) 26 Feb '24

26 Feb '24

Issue #17342 has been updated by Dan0042 (Daniel DeLorme). It's confusing that this ticket, #17342, is striked out even though the status is "Feedback". Another name for this could be `Hash#add`; at least that's the terminology used in memcached and I believe some other caching servers. ---------------------------------------- Feature #17342: Hash#fetch_set https://bugs.ruby-lang.org/issues/17342#change-107000 * Author: MaxLap (Maxime Lapointe) * Status: Feedback ---------------------------------------- I would like to propose adding the `fetch_set` method to `Hash`. It behaves just like `fetch`, but when using the default value (2nd argument or the block), it also sets the value in the Hash for the given key. We often use the pattern `cache[key] ||= calculation`. This pattern however has a problem when the calculation could return false or nil, as in those case, the calculation is repeated each time. I believe the best practice in that case is: ```ruby cache.fetch(key) { cache[key] = calculation } ``` With my suggestion, it would be: ```ruby cache.fetch_set(key) { calculation } ``` In these examples, each part is very short, so the `fetch` case is still clean. But as each part gets longer, the need to repeat cache[key] becomes more friction. Here is a more realistic example: ```ruby # Also using the key argument to the block to avoid repeating the # long symbol, adding some indirection RequestStore.store.fetch(:monitor_value_is_delayed?) do |key| RequestStore.store[key] = !MonitorValue.where('date >= ?', Time.now - 5.minutes).exists? end RequestStore.store.fetch_set(:monitor_value_is_delayed?) do !MonitorValue.where('date >= ?', Time.now - 5.minutes).exists? end ``` There is a precedent for such a method: Python has it, but with a quite confusing name: `setdefault(key, default_value)`. This does not set a default for the whole dictionary as the name would make you think, it really just does what is proposed here. https://docs.python.org/3/library/stdtypes.html#dict.setdefault -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116387] [Ruby master Bug#20206] PTY.spawn seems to fail to capture the output of "echo foo" once in a while
by lacostej (Jerome Lacoste) 26 Feb '24

26 Feb '24

Issue #20206 has been reported by lacostej (Jerome Lacoste). ---------------------------------------- Bug #20206: PTY.spawn seems to fail to capture the output of "echo foo" once in a while https://bugs.ruby-lang.org/issues/20206 * Author: lacostej (Jerome Lacoste) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We use PTY.spawn to call "echo foo", and on Mac it seems to randomly fail, capturing an empty output every now and then. On Linux, the failure doesn't seem to happen. The following code 1. contains 2 ways of capturing the output from PTY.spawn. Both seem to show the same issue (`run_command` and `run_command2`) 2. invokes the external `stress` program. This helps to trigger the issue more often. ``` ruby require 'pty' require 'expect' def run_command(command) output = [] PTY.spawn(command) do |command_stdout, command_stdin, pid| begin command_stdout.each do |l| line = l.chomp output << line end rescue Errno::EIO # This is expected on some linux systems, that indicates that the subcommand finished # and we kept trying to read, ignore it ensure command_stdout.close command_stdin.close Process.wait(pid) end end raise "#{$?.exited?} #{$?.stopped?} #{$?.signaled?} - #{$?.stopsig} - #{$?.termsig} -" unless $?.exitstatus == 0 [$?.exitstatus, output.join("\n")] end def run_command2(command) output = [] PTY.spawn(command) do |command_stdout, command_stdin, pid| output = "" begin a = command_stdout.expect(/foo.*/, 5) output = a[0] if a ensure command_stdout.close command_stdin.close Process.wait(pid) end end raise "#{$?.exited?} #{$?.stopped?} #{$?.signaled?} - #{$?.stopsig} - #{$?.termsig} -" unless $?.exitstatus == 0 [$?.exitstatus, output] end def test_spawn(command) status, output = run_command(command) errors = [] errors << "status was '#{status}'" unless status == 0 errors << "output was '#{output}'" unless output == "foo" raise errors.join(" - ") unless errors.empty? end t = nil pid = nil if ENV['STRESS'] t = Thread.new do |t| puts "Spawning stress" pid = spawn("stress -c 16 -t 99", pgroup: true) puts "Waiting #{pid}" Process.wait(pid) puts "#{pid} DONE" end end command = "echo foo" if ARGV.count == 1 command = ARGV[0] end puts "Will run command: '#{command}'" errors = 0 2000.times do |i| begin test_spawn(command) rescue => e puts "ERROR #{i}: #{e}" errors += 1 end end if t begin Process.kill(:SIGKILL, -pid) rescue Errno::ESRCH # already dead, ignore end t.join end raise "Failed #{errors} times" unless errors == 0 ``` Here are some ways of reproducing the issue ``` ruby test_pty.rb STRESS=y ruby test_pty.rb ``` Here's an example of how it fails on circleci. https://app.circleci.com/pipelines/github/lacostej/cienvs/33/workflows/d6d8… Tested on ruby 2.6 to ruby 3.3.0 on Mac. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116949] [Ruby master Misc#20303] Troubleshooting Guide for Common Issues with GMC Acadia
by adamrojas (Adam Rojas) 26 Feb '24

26 Feb '24

Issue #20303 has been reported by adamrojas (Adam Rojas). ---------------------------------------- Misc #20303: Troubleshooting Guide for Common Issues with GMC Acadia https://bugs.ruby-lang.org/issues/20303 * Author: adamrojas (Adam Rojas) * Status: Open ---------------------------------------- Owning a GMC Acadia brings numerous benefits, yet like any vehicle, it may encounter issues. In this guide, we’ll delve into common problems reported by GMC Acadia owners and offer effective solutions. ![Troubleshooting Guide for Common Issues with GMC Acadia](https://autorepairandservice.files.wordpress.com/2024/02/troublesho… Whether you’re dealing with transmission faults, engine light codes, or other issues, we’ve got you covered. ## **Troubles with Transmission and Check Engine Light:** ![Troubles with Transmission and Check Engine Light](https://autorepairandservice.files.wordpress.com/2024/02/troubles-wi… One significant challenge faced by GMC Acadia owners revolves around transmission faults, often accompanied by the illumination of the check engine light. This issue, reported by numerous individuals, demands prompt attention to prevent further complications. Seeking assistance from experienced professionals is recommended to diagnose and address these transmission-related concerns effectively, ensuring the continued reliability and performance of your vehicle. ## **Interpreting Check Engine Light Codes:** ![Interpreting Check Engine Light Codes](https://autorepairandservice.files.wordpress.com/2024/02/interpretin… Another common issue encountered by GMC Acadia owners involves the activation of the check engine light, often accompanied by specific diagnostic trouble codes (DTCs). Understanding these codes is essential for identifying underlying issues promptly. Seeking assistance from a qualified mechanic for thorough diagnostics and appropriate remedies is advised to prevent potential engine damage and ensure continued vehicle reliability. ## **Addressing Gas Cap Concerns and Check Engine Light Illumination:** ![Addressing Gas Cap Concerns and Check Engine Light Illumination](https://autorepairandservice.files.wordpress.com/2024/02/addr… Another area of concern for GMC Acadia owners involves issues related to the gas cap, which can lead to the illumination of the check engine light. This problem, while less common, should not be overlooked. It’s important to ensure the gas cap is securely tightened to prevent evaporation and maintain proper fuel system pressure. If the check engine light persists after verifying the gas cap’s tightness, seeking assistance from a qualified technician is advisable to diagnose and resolve any underlying issues effectively. ## **Navigating GMC Acadia Electrical Issues:** ![Navigating GMC Acadia Electrical Issues](https://autorepairandservice.files.wordpress.com/2024/02/navigating… Electrical problems can pose significant challenges for GMC Acadia owners, affecting various systems within the vehicle. These issues might manifest as malfunctioning lights, power window failures, intermittent electrical failures, or battery drainage concerns. Addressing electrical problems promptly is crucial to prevent further complications and ensure the safety and functionality of your Acadia. Seeking assistance from experienced technicians equipped with diagnostic tools and expertise in automotive electrical systems is essential for accurately identifying and resolving these issues, restoring your vehicle’s performance and reliability. ## **Essential Maintenance Tasks for GMC Acadia Owners:** ![Essential Maintenance Tasks for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/essential-… Beyond adhering to scheduled maintenance, there are fundamental tasks that every GMC Acadia owner should prioritize. These include: **1. Regular Brake Fluid Flushes:** To uphold braking effectiveness, it’s crucial to schedule regular brake fluid flushes. This process helps prevent contaminants from compromising the brake system’s performance, ensuring optimal safety on the road. **2. Transmission Inspections:** Regular inspections of the transmission are essential for early detection of potential issues. By identifying any signs of wear or malfunction early on, owners can mitigate the risk of costly repairs and ensure smooth operation of their Acadia. **3. Coolant Inspections:** Preventing overheating is vital for maintaining engine health. Regular coolant inspections help owners monitor coolant levels and quality, ensuring proper engine temperature regulation and preventing potential damage due to overheating. **4. Spark Plug Replacements:** Spark plugs play a critical role in engine performance by igniting the air-fuel mixture in the cylinders. Replacing worn-out spark plugs at recommended intervals helps maintain fuel efficiency, prevent misfires, and ensure optimal engine performance. ## **Expert Tips for GMC Acadia Owners:** ![Expert Tips for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/expert-tip… Routine inspections and preventive measures are key to maintaining your GMC Acadia’s performance and longevity. Beyond addressing specific issues and adhering to maintenance schedules, here are some expert tips to keep your vehicle running smoothly: **1. Driving Habits Matter:** Be mindful of your driving habits to minimize wear and tear on your Acadia. Avoid sudden acceleration or braking whenever possible, and practice smooth, gradual maneuvers to reduce strain on the engine, transmission, and other vital components. **2. Stay Informed and Educated:** Stay updated on recalls, service bulletins, and manufacturer recommendations for your GMC Acadia. Joining online forums or communities dedicated to GMC owners can provide valuable insights and tips from fellow enthusiasts and experts. Keeping yourself informed empowers you to make informed decisions about your vehicle’s care and maintenance. By incorporating these expert tips into your maintenance routine, you can ensure that your GMC Acadia remains reliable, efficient, and enjoyable to drive for miles to come. ## **Conclusion:** Being aware of common GMC Acadia issues and following proper maintenance practices can ensure trouble-free ownership. Promptly addressing problems through professional diagnosis and repair, along with adhering to recommended maintenance intervals, can help maintain a reliable and enjoyable driving experience. Thank you for reading this post. If you're looking for a car specialist to opt for a [cheap plastic bumper repair in Manchester](https://servicemycar.com/uk/services/car-bumper-repair-manchest…. So, you can connect with Service My Car and get the best car dent service at a very reasonable price. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116946] [Ruby master Bug#20302] Multiple refinements cannot be applied to the same module
by mame (Yusuke Endoh) 26 Feb '24

26 Feb '24

Issue #20302 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20302: Multiple refinements cannot be applied to the same module https://bugs.ruby-lang.org/issues/20302 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: shugo (Shugo Maeda) * ruby -v: ruby 3.4.0dev (2024-02-20T07:17:20Z master a605234bfa) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If we are using multiple refinements for the Kernel module, it seems that only the last refinement is enabled. In the following example, we can call `f2` of M2, which is enabled later. but cannot call `f1` of M1. ```ruby module M1 refine(Kernel) do def f1 = :f1 end end module M2 refine(Kernel) do def f2 = :f2 end end class Foo using M1 using M2 def test p f2 #=> :f2 p f1 # expected => :f1 # actual => undefined local variable or method 'f1' for an instance of Foo end end Foo.new.test ``` Note that if I change `refine(Kernel)` to `refine(Object)`, it works as expected. So I think there is a problem only when the refinement target is a module. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115985] [Ruby master Feature#20108] Introduction of Happy Eyeballs Version 2 (RFC8305) in Socket.tcp
by shioimm (Misaki Shioi) 26 Feb '24

26 Feb '24

Issue #20108 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #20108: Introduction of Happy Eyeballs Version 2 (RFC8305) in Socket.tcp https://bugs.ruby-lang.org/issues/20108 * Author: shioimm (Misaki Shioi) * Status: Open * Priority: Normal ---------------------------------------- This is an implementation of Happy Eyeballs version 2 (RFC 8305) in Socket.tcp. ### Background Currently, `Socket.tcp` synchronously resolves names and makes connection attempts with `Addrinfo::foreach.` This implementation has the following two problems. 1. In hostname resolution, the program stops until the DNS server responds to all DNS queries. 2. In a connection attempt, while an IP address is trying to connect to the destination host and is taking time, the program stops, and other resolved IP addresses cannot try to connect. ### Proposal "Happy Eyeballs" ([RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) is an algorithm to solve this kind of problem. It avoids delays to the user whenever possible and also uses IPv6 preferentially. I implemented it into `Socket.tcp` by using `Addrinfo.getaddrinfo` in each thread spawned per address family to resolve the hostname asynchronously, and using `Socket::connect_nonblock` to try to connect with multiple addrinfo in parallel. See https://github.com/ruby/ruby/pull/9374 ### Outcome This change eliminates a fatal defect in the following cases. #### Case 1. One of the A or AAAA DNS queries does not return ```ruby require 'socket' class Addrinfo class << self # Current Socket.tcp depends on foreach def foreach(nodename, service, family=nil, socktype=nil, protocol=nil, flags=nil, timeout: nil, &block) getaddrinfo(nodename, service, Socket::AF_INET6, socktype, protocol, flags, timeout: timeout) .concat(getaddrinfo(nodename, service, Socket::AF_INET, socktype, protocol, flags, timeout: timeout)) .each(&block) end def getaddrinfo(_, _, family, *_) case family when Socket::AF_INET6 then sleep when Socket::AF_INET then [Addrinfo.tcp("127.0.0.1", 4567)] end end end end Socket.tcp("localhost", 4567) ``` Because the current `Socket.tcp` cannot resolve IPv6 names, the program stops in this case. It cannot start to connect with IPv4 address. Though `Socket.tcp` with HEv2 can promptly start a connection attempt with IPv4 address in this case. #### Case 2. Server does not promptly return ack for syn of either IPv4 / IPv6 address family ```ruby require 'socket' fork do socket = Socket.new(Socket::AF_INET6, :STREAM) socket.setsockopt(:SOCKET, :REUSEADDR, true) socket.bind(Socket.pack_sockaddr_in(4567, '::1')) sleep socket.listen(1) connection, _ = socket.accept connection.close socket.close end fork do socket = Socket.new(Socket::AF_INET, :STREAM) socket.setsockopt(:SOCKET, :REUSEADDR, true) socket.bind(Socket.pack_sockaddr_in(4567, '127.0.0.1')) socket.listen(1) connection, _ = socket.accept connection.close socket.close end Socket.tcp("localhost", 4567) ``` The current `Socket.tcp` tries to connect serially, so when its first name resolves an IPv6 address and initiates a connection to an IPv6 server, this server does not return an ACK, and the program stops. Though `Socket.tcp` with HEv2 starts to connect sequentially and in parallel so a connection can be established promptly at the socket that attempted to connect to the IPv4 server. In exchange, the performance of `Socket.tcp` with HEv2 will be degraded. ``` 100.times { Socket.tcp("www.ruby-lang.org", 80) } # Socket.tcp (Before) 0.123809 # Socket.tcp (After) 0.224684 ``` This is due to the addition of the creation of IO objects, Thread objects, etc., and calls to `IO::select` in the implementation. -- https://bugs.ruby-lang.org/

4 13

[ruby-core:116935] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nagachika (Tomoyuki Chikanaga) 25 Feb '24

25 Feb '24

Issue #18743 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ruby_3_2 5e4606423da96c2e26b00981c22bddfce0d970bf merged revision(s) f15123c34ce80f3928612befe2a9aaf4c9d27fda. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-106970 * Author: sos4nt (Stefan Schüßler) * Status: Closed * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0