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

[ruby-core:119406] [Ruby master Bug#20777] 3.3: `RUBY_DESCRIPTION` is corrupt when `--yjit` and `--parser=prism`
by nobu (Nobuyoshi Nakada) 04 Nov '24

04 Nov '24

Issue #20777 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20777: 3.3: `RUBY_DESCRIPTION` is corrupt when `--yjit` and `--parser=prism` https://bugs.ruby-lang.org/issues/20777 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Note the last garbages. ```shell-session $ ruby3.3 -W0 --yjit --parser=prism -e 'p RUBY_DESCRIPTION' "ruby 3.3.5 (2024-09-03 revision ef084cc8f4) +YJIT +PRISM [arm64-darwin\x00\x00\x00" ``` commit:76ea5cde2a0f4834a5228104249b6b3346ddfc94 is needed. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119124] [Ruby master Bug#20723] `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler.
by ioquatix (Samuel Williams) 04 Nov '24

04 Nov '24

Issue #20723 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20723: `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler. https://bugs.ruby-lang.org/issues/20723 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.3: REQUIRED ---------------------------------------- The following program seems to work okay on Ruby 3.2 but hangs on Ruby 3.3: ```ruby #!/usr/bin/env ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'async' end require 'socket' def close_while_reading(io) thread = Thread.new do Thread.current.report_on_exception = false io.wait_readable end # Wait until the thread is blocked on read: Thread.pass until thread.status == "sleep" Async do io.close end thread.join end begin client, server = Socket.pair(:UNIX, :STREAM) close_while_reading(client) rescue => error $stderr.puts error.full_message end ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:119117] [Ruby master Bug#20721] Gem executables have a .lock file in Ruby 3.3.5
by k0kubun (Takashi Kokubun) 04 Nov '24

04 Nov '24

Issue #20721 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #20721: Gem executables have a .lock file in Ruby 3.3.5 https://bugs.ruby-lang.org/issues/20721 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- With Ruby 3.3.5, every gem executable under `$prefix/bin` has a `.lock` file. This is [an unintended change](https://github.com/ruby/ruby/pull/11252#issuecomment-2337520641), which was fixed in rubygems master at https://github.com/rubygems/rubygems/pull/7939. I filed this ticket to make sure we backport that before the Ruby 3.3.6 release. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119091] [Ruby master Bug#20718] Objects created with Data_Make_Struct and the default free function are not freed
by jcalvert (Jonathan Calvert) 04 Nov '24

04 Nov '24

Issue #20718 has been reported by jcalvert (Jonathan Calvert). ---------------------------------------- Bug #20718: Objects created with Data_Make_Struct and the default free function are not freed https://bugs.ruby-lang.org/issues/20718 * Author: jcalvert (Jonathan Calvert) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I discovered a memory leak when using the FFI gem prior to version 1.16 and Ruby 3.3 and up. During debugging I found that this earlier version of FFI uses Data_Make_Struct (https://github.com/ffi/ffi/blob/v1.15.5/ext/ffi_c/Pointer.c#L57) instead of TypedData_Make_Struct and it uses -1 as the free function, which is RUBY_DEFAULT_FREE When the object goes to get garbage collected, it enters into rb_data_free and it is passed to the RTYPEDDATA_EMBEDDED_P macro even though it is not of RTypedData. Because of that, the conditional is evaluated to false and xfree is never called. This was discovered by using jemalloc leak detection. I have attached a somewhat minimal replication of the issue. The fix would appear to check the type of the obj before casting it. ---Files-------------------------------- pointer_bug.rb (418 Bytes) Gemfile.txt (104 Bytes) -- https://bugs.ruby-lang.org/

3 3

[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