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

[ruby-core:119649] [Ruby master Bug#20856] Incorrect and inconsistent multi-thread eval execution
by hurricup (Alexandr Evstigneev) 04 Nov '24

04 Nov '24

Issue #20856 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #20856: Incorrect and inconsistent multi-thread eval execution https://bugs.ruby-lang.org/issues/20856 * Author: hurricup (Alexandr Evstigneev) * Status: Open * ruby -v: 3.4.0-preview2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Consider example: ``` s = Thread.new { a = 5 puts eval("a == b") x = 6 } s.join b = 11 ``` As far as I see it, it should not work. Because at the moment of eval, b is unknown and not even declared (it can even be in condition). But it may be available because file `iseq` already compiled and we know that there is b. So, this works in ruby 3.3 in a script we running, wrapped into the method, or required by other file. But in 3.4-preview2: - it works in file - it works in method - it fails if required from other file with: ``` #<Thread:0x00007725530d6a98 /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:1 run> terminated with exception (report_on_exception is true): (eval at /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3):1:in 'block in <top (required)>': undefined local variable or method 'b' for main (NameError) from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'Kernel#eval' from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'block in <top (required)>' (eval at /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3):1:in 'block in <top (required)>': undefined local variable or method 'b' for main (NameError) from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'Kernel#eval' from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'block in <top (required)>' ``` And this ^^ is correct behavior if you ask me :) but atm it is inconsistent between the ruby versions and even in the scope of 3.4-preview2 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119121] [Ruby master Bug#20722] curious search result order on docs.ruby-lang.org
by masterleep2 (Bill Lipa) 01 Nov '24

01 Nov '24

Issue #20722 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #20722: curious search result order on docs.ruby-lang.org https://bugs.ruby-lang.org/issues/20722 * Author: masterleep2 (Bill Lipa) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If you search for "String" on https://docs.ruby-lang.org/en/3.3/ the first four results returned are obscure: 1. Gem::SafeMarshal::Elements::String 2. Prism::StringFlags 3. Prism::StringNode 4. Reline::Terminfo::StringWithTiparm 5. String Would it be possible to change it so that if one types an exact class name, the class of that name is first on the list? This would make it easier to use the search feature. More generally, the prioritization of these results is surprising. Not sure if this is the right place to report a doc website issue. Apologies if not. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119637] Behavior of raising from rescue blocks when multiple rescue blocks exist
by Rodrigo Rosenfeld Rosas 29 Oct '24

29 Oct '24

Hello, I couldn't find any documentation about the subject, so I thought this behavior should be probably documented. Given the following code: def raise_error raise "runtime error message" rescue => e "StandardError: #{e.message}" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" end # same, but the order of the rescue blocks are inverted def raise_error2 raise "runtime error message" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" rescue => e "StandardError: #{e.message}" end p ["raise_error", raise_error ] begin p ["raise_error2", raise_error2] rescue => e puts "raise_error2 raised: #{e.message}" end When we run it, this is the output in Ruby 3.3.5: ["raise_error", "StandardError: runtime error message"] RuntimeError raised: runtime error message raise_error2 raised: standard error message In the first case (raise_error), the code raised from the RuntimeError rescue block is rescued by the StandardError block, but when inverting the order of the rescue blocks (raise_error2) then this won't happen. Is this part of the specs? Is this behavior documented somewhere? Could this behavior differ in different Ruby implementations and versions? Or can we rely on such behavior? This chapter doesn't include such case in its examples: https://ruby-doc.com/docs/ProgrammingRuby/html/tut_exceptions.html Or this documentation about Exceptions: https://ruby-doc.org/3.3.5/syntax/exceptions_rdoc.html Is there a recommended way for wrapping exceptions into a particular one and then handling that exception from within the same method rescue blocks? Or is this considered a bad practice?

2 2

[ruby-core:119613] [Ruby master Misc#20814] iseq optimizations on constant condition
by hurricup (Alexandr Evstigneev) 29 Oct '24

29 Oct '24

Issue #20814 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Misc #20814: iseq optimizations on constant condition https://bugs.ruby-lang.org/issues/20814 * Author: hurricup (Alexandr Evstigneev) * Status: Open ---------------------------------------- ruby 3.4-preview2 seems optimizes out some stuff when building iseq and this may lead to user unexpected behavior when debugging, because some lines just optimized out. Example: ``` def foo1 if true nil else 1 end end ``` produces: ``` == disasm: #<ISeq:foo1@/test.rb:1 (1,0)-(7,3)> 0000 putnil ( 3)[LiCa] 0001 leave ( 7)[Re] ``` Two questions: - is there way to disable such optimizations? - are there some specs on things that can be optimized. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:119633] [Ruby master Bug#20819] IO#readline does not process newlines correctly for non-ASCII compatible encodings
by javanthropus (Jeremy Bopp) 28 Oct '24

28 Oct '24

Issue #20819 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20819: IO#readline does not process newlines correctly for non-ASCII compatible encodings https://bugs.ruby-lang.org/issues/20819 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When not performing character conversion, IO#readline only processes newline characters as ASCII when reading paragraphs. However, when character conversion is involved, even when converting between 2 ASCII incompatible encodings, newline handling is correct. ```ruby require "tempfile" Tempfile.open(binmode: true) do |f| f.set_encoding("utf-16le") f.write("\n\n\n\nhello\n\nworld") f.rewind # No character conversion case. # Expecting "hello\n\n".encode(Encoding::UTF_16LE) f.readline("") # => "\0".force_encoding(Encoding::UTF_16LE) + "\n\n\nhello\n\nworld".encode(Encoding::UTF_16LE) f.set_encoding("utf-16le:utf-32le") f.rewind # Character conversion case. f.readline("") # => "hello\n\n".encode(Encoding::UTF_32LE) end ``` In the failing case, a newline character appears in the first byte of the input due to the UTF-16LE encoding. This is discarded per the normal behavior of reading paragraphs, but the following null byte is not consumed as required to consume the entire newline character in UTF-16LE encoding. This leads to a leading and invalid null byte in the output of IO#readline. Furthermore, the newlines between "hello" and "world" are not seen as a pair of newline characters sufficient to end the first paragraph because they are not ASCII newlines and instead have a null byte between them. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119614] [Ruby master Feature#20815] Fetch for nested hash
by dmytrostrukov (Dmytro Strukov) 26 Oct '24

26 Oct '24

Issue #20815 has been reported by dmytrostrukov (Dmytro Strukov). ---------------------------------------- Feature #20815: Fetch for nested hash https://bugs.ruby-lang.org/issues/20815 * Author: dmytrostrukov (Dmytro Strukov) * Status: Open ---------------------------------------- I propose adding a `fetch_nested` method to Ruby’s Hash class, allowing developers to fetch values deeply nested within a hash, with an error raised if any key in the provided path is missing. The method would be similar to dig, but with the added functionality of error handling when keys are not found, improving code readability and robustness when accessing nested data structures. **Rationale** - Enhanced Error Handling: `fetch_nested` would raise an error if a key in the specified path does not exist, which is critical for cases where the absence of specific keys indicates a data integrity issue or invalid structure. This makes debugging easier and helps catch issues early in the development process. - Improved Code Readability: Without `fetch_nested`, developers often chain multiple fetch calls or rely on error-prone conditional checks, complicating code. A single `fetch_nested` method call would simplify syntax and improve readability when working with deeply nested hashes. - Alignment with Ruby’s Error-First Philosophy: Ruby’s fetch method already offers error handling for missing keys at the top level of a hash. Extending this philosophy to nested hashes would offer consistency and convenience, aligning with Ruby’s emphasis on developer-friendly and expressive error handling. **Example Usage** ``` ruby data = { user: { profile: { name: "Alice" } } } # Current approach data.fetch(:user).fetch(:profile).fetch(:name) # Or use dig without error handling # Proposed `fetch_nested` data.fetch_nested(:user, :profile, :name) # Raises KeyError if any key is missing ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:119559] [Ruby master Feature#20805] Allow Ractor#send from a signal trap Proc
by kirs (Kir Shatrov) 25 Oct '24

25 Oct '24

Issue #20805 has been reported by kirs (Kir Shatrov). ---------------------------------------- Feature #20805: Allow Ractor#send from a signal trap Proc https://bugs.ruby-lang.org/issues/20805 * Author: kirs (Kir Shatrov) * Status: Open ---------------------------------------- It was surfaced in https://bugs.ruby-lang.org/issues/18139 that Ractor is designed to "unexpected interruption free" and it's not supposed to have a `kill`-like method. A better alternative to that would be allow the main Ractor to consume a shutdown signal from the pipe. Example: ```ruby shutdown_ractor = Ractor.new do Ractor.recv # Wait for a signal end # Signal trap for SIGTERM Signal.trap("TERM") do puts "Received SIGTERM, shutting down..." shutdown_ractor.send(:shutdown) # Send the shutdown signal end pipe = Ractor.new do loop do r, value = Ractor.select(Ractor.recv, shutdown_ractor) if r == shutdown_ractor # Shutdown signal received break else Ractor.yield(value, move: true) # Normal operation end end end ``` However, it's not possible to do `Ractor#send` from a trap Proc right now: ``` <internal:ractor>:282:in `new': can not isolate a Proc because it accesses outer variables (shutdown_ractor). (ArgumentError) ``` From what I've gathered, it makes it impossible to implement any graceful shutdown in a process with a few Ractors running. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119599] [Ruby master Bug#20810] Re-enable s390x CI Builds on Master Branch in Travis CI
by mayur.jadhav (Mayur Jadhav) 25 Oct '24

25 Oct '24

Issue #20810 has been reported by mayur.jadhav (Mayur Jadhav). ---------------------------------------- Bug #20810: Re-enable s390x CI Builds on Master Branch in Travis CI https://bugs.ruby-lang.org/issues/20810 * Author: mayur.jadhav (Mayur Jadhav) * Status: Open * ruby -v: master * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Description: Currently, the Travis CI has been temporarily disabled on the master branch via Pr(https://github.com/ruby/ruby/pull/11509). However, the s390x builds are successfully running on other branches( ruby_3_3, ruby_3_2) on Travis CI, which were previously experiencing timeouts. The issue has been addressed by the Travis team. Given the significance of multi-architecture support for Ruby, we request that the Travis CI builds be re-enabled on the master branch. please let us know we are more than happy to collaborate to make this happen. Thanks. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:119606] [Ruby master Feature#20812] Proposal for Safe Include Method in Ruby
by rogerconsul (Roger Consul) 24 Oct '24

24 Oct '24

Issue #20812 has been reported by rogerconsul (Roger Consul). ---------------------------------------- Feature #20812: Proposal for Safe Include Method in Ruby https://bugs.ruby-lang.org/issues/20812 * Author: rogerconsul (Roger Consul) * Status: Open ---------------------------------------- # Proposal for Safe Include Method in Ruby ## Description Add a new method `include_safe?` to Ruby's `Enumerable` module that safely handles nil arguments in inclusion checks. ## Problem Statement The current `include?` method raises an error when passed `nil` as an argument. This requires developers to write defensive code with explicit nil checks, leading to less readable and more error-prone code. ```ruby # Current problematic scenarios: collection.include?(nil) # Works, checks for nil in collection collection.include?(value) # Raises error if value is nil # Current workarounds: value && collection.include?(value) collection.include?(value.to_s) ``` ## Proposed Solution Add `include_safe?` method that returns `false` when the argument is `nil`: ```ruby module Enumerable def include_safe?(obj) return false if obj.nil? include?(obj) end end ``` ### Usage Examples ```ruby numbers = [1, 2, 3] document_id = nil # Current approach document_id && numbers.include?(document_id) # false # Proposed approach numbers.include_safe?(document_id) # false # Works normally for non-nil values numbers.include_safe?(2) # true numbers.include_safe?(4) # false # Edge cases handled [nil].include_safe?(nil) # false [].include_safe?(nil) # false ``` ## Benefits 1. **Improved Safety**: Eliminates a common source of runtime errors 2. **Better Readability**: Removes need for explicit nil checks 3. **Consistent Behavior**: Provides predictable handling of nil values 4. **Rails Alignment**: Similar to Rails' safe navigation patterns 5. **Reduced Boilerplate**: Eliminates common defensive coding patterns ## Implementation Notes This would be implemented in C as part of Ruby's core, but here's a Ruby reference implementation: ```ruby module Enumerable def include_safe?(obj) return false if obj.nil? include?(obj) end end ``` ## Testing Strategy ```ruby require 'minitest/autorun' class TestIncludeSafe < Minitest::Test def setup @array = [1, 2, 3] @array_with_nil = [1, nil, 3] end def test_basic_inclusion assert @array.include_safe?(1) refute @array.include_safe?(4) end def test_nil_handling refute @array.include_safe?(nil) refute @array_with_nil.include_safe?(nil) end def test_empty_collection refute [].include_safe?(nil) refute [].include_safe?(1) end end ``` ## Alternative Considerations 1. **Name Alternatives**: - `try_include?` - `safe_include?` - `includes_safely?` 2. **Alternative Approaches**: - Modify existing `include?` behavior (rejected due to backward compatibility) - Add parameter to existing `include?` (rejected for clarity) ## Impact Analysis ### Positive Impact - Reduces runtime errors - Improves code readability - Follows principle of least surprise ### Potential Concerns - Another method to learn - Possible confusion with regular `include?` ## Similar Features in Ruby - Safe navigation operator (`&.`) - `try` method in Rails - `fetch` method with default value ## Backward Compatibility This change is fully backward compatible as it introduces a new method without modifying existing behavior. ## Reference Implementation A gem implementing this feature is available at: [Link to gem if created] ## Questions for Core Team 1. Is `include_safe?` the best name for this method? 2. Should this be added to `Array` specifically rather than `Enumerable`? 3. Should we consider any additional edge cases? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119605] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Eregon (Benoit Daloze) 24 Oct '24

24 Oct '24

Issue #15381 has been updated by Eregon (Benoit Daloze). Regarding `**@`, I'm not a big fan because `**` on the caller side is very much syntax a bit like a keyword, and it has the meaning the pass the Hash/expression as keyword arguments and not as a position argument. Of course you could have `**` the syntax and `**@` the unary operator called by it, but effectively it's not really an operator in the sense of unary +/- or binary operators, e.g. it can only be used in calls and in Hash literals. Regarding trying `to_hash` then `to_h` or vice-versa it will have some overhead for the second method being tried for non-Hash. `foo(**obj.to_h)` doesn't sound too bad to me as I would expect it's needed in only a few places (compared to all `**hash` usages) and it's probably clearer what is happening that way if `obj` is not a Hash/to_hash. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110227 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0