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

[ruby-core:120713] [Ruby master Bug#21044] Prism maximum recursion depth is 1_000, parse.y is 10_000
by kddnewton (Kevin Newton) 14 Feb '25

14 Feb '25

Issue #21044 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21044: Prism maximum recursion depth is 1_000, parse.y is 10_000 https://bugs.ruby-lang.org/issues/21044 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED ---------------------------------------- These should be aligned. This was because I misread the bison docs originally. Some folks are hitting this when trying to render Rails views too deeply. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120512] [Ruby master Bug#21008] Array#sum, Enumerator#sum, Numeric subclass
by MSP-Greg (Greg L) 14 Feb '25

14 Feb '25

Issue #21008 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21008: Array#sum, Enumerator#sum, Numeric subclass https://bugs.ruby-lang.org/issues/21008 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-06T17:07:57Z master a61c16ba42) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following code seems to show a bug or 'quirk'. When using a Numeric subclass, `Array#sum` works correctly, but `Enumerator#sum` does not. They both work fine when using a `Float`. ```ruby class Length < Numeric def initialize(val) @val = Float(val) end def to_f @val end end ary = [] #────────────────────────────────────────── Use Length ary[0] = Length.new 5 ary[1] = Length.new 10 ary[2] = Length.new 20 puts "Length ary #{ary.sum}" #=> 35.0 enum = ary.each puts "Length enum #{enum.sum}" #=> 20.0 #────────────────────────────────────────── Use Float ary[0] = 5.0 ary[1] = 10.0 ary[2] = 20.0 puts "Float ary #{ary.sum}" #=> 35.0 enum = ary.each puts "Float enum #{enum.sum}" #=> 35.0 ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120458] [Ruby master Misc#20995] exception escapes block given to IO.popen("-") in child process
by martin.dorey＠hds.com (Martin Dorey) 14 Feb '25

14 Feb '25

Issue #20995 has been reported by martin.dorey(a)hds.com (Martin Dorey). ---------------------------------------- Misc #20995: exception escapes block given to IO.popen("-") in child process https://bugs.ruby-lang.org/issues/20995 * Author: martin.dorey(a)hds.com (Martin Dorey) * Status: Open ---------------------------------------- I was surprised by the "ensure" being reached in the child process here: ``` ruby martind@stormy:~/tmp/D161730$ cat repro.rb #!/usr/bin/ruby -w parent = Process.pid() [false, true].each() { |nauseous| $stderr.puts("#{nauseous ? "" : "not "}raising exception from child:") begin IO.popen("-") { |io| unless io if nauseous raise("childish fit") end end } ensure $stderr.puts("in finalization block from #{Process.pid() == parent ? "parent" : "child"}") $stderr.puts() end } martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby --version ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] martind@stormy:~/tmp/D161730$ ~/download/ruby-3.3.4/ruby -w repro.rb not raising exception from child: in finalization block from parent raising exception from child: in finalization block from child repro.rb:11:in `block (2 levels) in <main>': childish fit (RuntimeError) from repro.rb:7:in `popen' from repro.rb:7:in `block in <main>' from repro.rb:3:in `each' from repro.rb:3:in `<main>' in finalization block from parent martind@stormy:~/tmp/D161730$ ``` In the first iteration of the loop, we don't see the surprise - the child process exits when the block is completed. Only when an exception is thrown, in the second iteration, does the control flow escape from the block. It does so even for the SystemExit exception raised by exit(0) but not, as we see above, from just leaving the block (in which case perhaps we _exit(0) at https://github.com/ruby/ruby/blob/master/io.c#L8044) My expectation was that the block would be executed in the child process much like the "main" part of a program, with the usual unhandled exception reporting, which we see demonstrated above, being invoked as soon as the exception propagated out the block, rather than first unwinding the callers. I think the behavior is unchanged since the oldest version I was conveniently able to test, which was: ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux] ... so I didn't file this report as a Bug in case users have (accidentally?) come to depend on the behavior. I didn't find any mention of this at eg https://ruby-doc.org/3.4.1/IO.html#method-c-popen but I didn't file this report as a Feature request for the documentation in case the documentation deliberately leaves open such possibilities. I didn't even find anyone else puzzling over this behavior on eg StackOverflow, but I felt that I should report it for the benefit of the next poor sap to run into it, especially in case that's Future Me. Could it be a case where a warning would be worth more than the trouble it causes? -- https://bugs.ruby-lang.org/

4 6

[ruby-core:120538] [Ruby master Bug#21014] Prism doesn't set node_id on iseqs correctly
by tenderlovemaking (Aaron Patterson) 14 Feb '25

14 Feb '25

Issue #21014 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21014: Prism doesn't set node_id on iseqs correctly https://bugs.ruby-lang.org/issues/21014 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Given this code: ```ruby f = proc { <<END } heredoc END iseq = RubyVM::InstructionSequence.of(f) p iseq.to_a[4][:node_id] ``` Output on parse.y: ``` $ ./miniruby --parser=parse.y test.rb 3 ``` Output on Prism: ``` $ ./miniruby test.rb -1 ``` I don't expect node IDs on Prism to match parse.y, but I do expect the node id to be a legitimate node id. For example, this program should work: ```ruby f = proc { <<END } heredoc END iseq = RubyVM::InstructionSequence.of(f) require "prism" node_id = iseq.to_a[4][:node_id] ast = Prism.parse(File.binread(__FILE__)) p ast.value.breadth_first_search { |node| node.node_id == node_id } ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120553] [Ruby master Bug#21017] `--with-parser=parse.y` configure option does not work
by nobu (Nobuyoshi Nakada) 14 Feb '25

14 Feb '25

Issue #21017 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21017: `--with-parser=parse.y` configure option does not work https://bugs.ruby-lang.org/issues/21017 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120443] [Ruby master Bug#20992] `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists
by tompng (tomoya ishida) 14 Feb '25

14 Feb '25

Issue #20992 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20992: `eval(ascii_encoded_code)` raises EncodingError when multibyte local variable exists https://bugs.ruby-lang.org/issues/20992 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2024-12-28T09:40:37Z master e4ec2128ae) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby #coding: utf-8 α=1 eval '1+2'.encode('ascii') ~~~ ~~~ $ ruby file.rb file.rb:3:in 'Kernel#eval': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from file.rb:3:in '<main>' ~~~ Running the file below with `LANG=C ruby file.rb` will make IRB unresponsive ~~~ruby #coding: utf-8 α=1 binding.irb ~~~ ~~~ $ LANG=C ruby file.rb From: file.rb @ line 3 : 1: #coding: utf-8 2: α=1 => 3: binding.irb irb(main):001> 1 <internal:kernel>:168:in 'Kernel#loop': invalid symbol in encoding US-ASCII :"\xCE\xB1" (EncodingError) from <internal:prelude>:5:in 'Binding#irb' from file.rb:3:in '<main>' irb(main):002> ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120524] [Ruby master Bug#21010] Endless method definition of `[]=` is SyntaxError in parse.y but allowed in Prism
by tompng (tomoya ishida) 14 Feb '25

14 Feb '25

Issue #21010 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21010: Endless method definition of `[]=` is SyntaxError in parse.y but allowed in Prism https://bugs.ruby-lang.org/issues/21010 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-06T01:50:53Z master c8e3d745fa) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These codes is SyntaxError in parse.y but accepted in Prism ~~~ruby def []=(k,v)=1 def obj.[]=(k,v)=1 ~~~ These are both SyntaxError in parse.y and Prism by design. ~~~ruby # invalid method name; a setter method cannot be defined in an endless method definition def f=(k,v)=1 def obj.f=(k,v)=1 ~~~ I think endless method definition of `[]=` should be also rejected. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120472] [Ruby master Bug#21001] unexpected nil result from proc with ensure and next
by aharpervc (Andrew Harper) 14 Feb '25

14 Feb '25

Issue #21001 has been reported by aharpervc (Andrew Harper). ---------------------------------------- Bug #21001: unexpected nil result from proc with ensure and next https://bugs.ruby-lang.org/issues/21001 * Author: aharpervc (Andrew Harper) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello, I have noticed a different program behavior in Ruby 3.4 compared to previous versions. This is a simplified example for debugging that returns the expected result in Ruby 3.3 but nil in Ruby 3.4 Here is the example program: ``` ruby puts "Ruby: #{RUBY_VERSION}" # okay all versions # RUN_ARRAY = [1] # fails ruby 3.4 only RUN_ARRAY = [1,2] MAP_PROC = Proc.new do |&blk| block_results = [] RUN_ARRAY.each do |value| block_value = blk.call(value) block_results.push block_value end block_results ensure next block_results end test_fn_results = MAP_PROC.call do |value| break if value > 1 next value end puts test_fn_results.inspect ``` For Ruby 3.3.6 the output is: ``` Ruby: 3.3.6 [1] ``` For Ruby 3.4.1 the output is: ``` Ruby: 3.4.1 nil ``` I am expecting the Ruby 3.3 output even for Ruby 3.4. This appears to be a bug, since the program implementation is unchanged. Perhaps there is a bug in the code that is now only showing up with Ruby 3.4, but that seemed unlikely since it's working as expected in other versions. Thank you -- https://bugs.ruby-lang.org/

4 3

[ruby-core:120474] [Ruby master Bug#21002] Please include license information of turbo_tests
by vo.x (Vit Ondruch) 14 Feb '25

14 Feb '25

Issue #21002 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #21002: Please include license information of turbo_tests https://bugs.ruby-lang.org/issues/21002 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It seems that [PR#12250](https://github.com/ruby/ruby/pull/12250) pulled in [turbo_tests](https://github.com/serpapi/turbo_tests). However it did so without any references to upstream, excluding license information, etc. I think it would be nice to give upstream some credit. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120476] [Ruby master Bug#21003] unexpected warning about ignored block
by decuplet (Nikita Shilnikov) 14 Feb '25

14 Feb '25

Issue #21003 has been reported by decuplet (Nikita Shilnikov). ---------------------------------------- Bug #21003: unexpected warning about ignored block https://bugs.ruby-lang.org/issues/21003 * Author: decuplet (Nikita Shilnikov) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I stumbled upon this during the upgrade to 3.4. Here's the minimal repro: ```ruby $VERBOSE = true def foo(*, &block) = block def bar(buz, ...) = foo(buz, ...) bar(:test) {} ``` It gives ``` ruby reproduce.rb reproduce.rb:6: warning: the block passed to 'Object#bar' defined at reproduce.rb:4 may be ignored ``` where I believe it shouldn't. No warning reported if I change `def bar(buz, ...)` to `def bar(...)`. -- https://bugs.ruby-lang.org/

4 3