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

[ruby-core:116812] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by mame (Yusuke Endoh) 17 Feb '24

17 Feb '24

Issue #19117 has been updated by mame (Yusuke Endoh). No one seems to want to treat `rescue in` and `ensure in` as a regression. I think that we should discuss further improvements in a separate ticket. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106837 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116810] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by Dan0042 (Daniel DeLorme) 16 Feb '24

16 Feb '24

Issue #13557 has been updated by Dan0042 (Daniel DeLorme). > I think both `Kernel#raise` and `Exception#set_backtrace` would need to accept array of `Thread::Backtrace::Location`. That's an idea I fully support. Although when I need to modify an error's backtrace 95% of the time it's because I want to skip the first few frames, like `raise Error, "message", caller[3..-1]`. So it would be nice to have a shortcut idiom for this, like perhaps `raise Error, "message", skip: 3` ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-106835 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Open * Priority: Normal ---------------------------------------- When re-raising exceptions, it is sometimes useful to "massage" the backtrace (especially in DSLs). There is currently no way to do it using only backtrace locations. This causes the new exception to have #backtrace_locations return nil, and thus makes backtrace_locations unreliable as a whole. Example: ~~~ def test raise ArgumentError, "", caller_locations end begin test rescue ArgumentError => e p e.backtrace_locations end ~~~ attempting to pass `caller_location` to `Kernel#raise` in the `test` method fails with `bla.rb:2:in `set_backtrace': backtrace must be Array of String (TypeError)` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116809] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Dan0042 (Daniel DeLorme) 16 Feb '24

16 Feb '24

Issue #19117 has been updated by Dan0042 (Daniel DeLorme). If "rescue in" is removed, then what happens to the similar "block in" ? Also in terms of quotes, what are your thoughts on `from ./test.rb:16:in 'block in Concrete#oops'` vs `from ./test.rb:16:in block in 'Concrete#oops'` ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106834 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116769] [Ruby master Feature#20266] New syntax to escape embed strings in Regexp literal
by usa (Usaku NAKAMURA) 16 Feb '24

16 Feb '24

Issue #20266 has been reported by usa (Usaku NAKAMURA). ---------------------------------------- Feature #20266: New syntax to escape embed strings in Regexp literal https://bugs.ruby-lang.org/issues/20266 * Author: usa (Usaku NAKAMURA) * Status: Open * Priority: Normal ---------------------------------------- # Premise When using embed strings in Regexp literal, it is interpreted as a part of the Regexp. ```ruby foo = "[a-z]" p /#{foo}/ #=> /[a-z]/ ``` So, currently we often have to escape the embed strings. ```ruby foo = "[a-z]" p /#{Regexp.quote(foo)}/ #=> /\[a\-z\]/ ``` This is very long and painful to write every time. So, I propose new syntax to escape embed strings automatically. # Proposal Adding new token `#{=` in Regexp literal: ```ruby foo = "[a-z]" p /#{=foo}/ #=> /\[a\-z\]/ ``` When `#{=` is used instead of `#{`, ruby calls `Regexp.quote` internally. # Compatibility Current ruby causes syntax error when using `#{=`, then there is no incompatibilty. # Out of scope of this proposal I do not propose about `#{=` in another literals. They are out of scope of this proposal. -- https://bugs.ruby-lang.org/

8 7

[ruby-core:116807] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 16 Feb '24

16 Feb '24

Issue #19117 has been updated by Eregon (Benoit Daloze). I'm in favor to keep it removed, because these are implementation details. Although ideally in backtraces I think it would be best to hide the entry corresponding to `rescue in`/`ensure in`, i.e., instead of: ``` /tmp/foo.rb:7:in `rescue in rescue in raise_nested_exceptions': Third error (RuntimeError) from /tmp/foo.rb:4:in `rescue in raise_nested_exceptions' from /tmp/foo.rb:1:in `raise_nested_exceptions' from /tmp/foo.rb:11:in `<main>' ``` have: ``` /tmp/foo.rb:7:in 'Object#raise_nested_exceptions': Third error (RuntimeError) from /tmp/foo.rb:11:in '<main>' ``` Since there are no calls from Ruby semantics POV and the extra frames are a CRuby implementation detail (e.g. TruffleRuby does not have extra call frames for `rescue` and `ensure`, not sure about JRuby). ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106830 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111965] [Ruby master Bug#19365] Ractors can access non-shareable values through enumerators
by luke-gru (Luke Gruber) 16 Feb '24

16 Feb '24

Issue #19365 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19365: Ractors can access non-shareable values through enumerators https://bugs.ruby-lang.org/issues/19365 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I don't think enumerators should be able to be passed to `Ractor.new` ```ruby obj = Object.new # unshareable value p obj Ractor.new([obj].each) {|f| p f.first }.take ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:112155] [Ruby master Bug#19395] Process forking within non-main Ractor creates child stuck in busy loop
by luke-gru (Luke Gruber) 16 Feb '24

16 Feb '24

Issue #19395 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19395: Process forking within non-main Ractor creates child stuck in busy loop https://bugs.ruby-lang.org/issues/19395 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby def test_fork_in_ractor r2 = Ractor.new do pid = fork do exit Ractor.count end pid end pid = r2.take puts "Process #{Process.pid} waiting for #{pid}" _pid, status = Process.waitpid2(pid) # stuck forever if status.exitstatus != 1 raise "status is #{status.exitstatus}" end end test_fork_in_ractor() ``` $ top # shows CPU usage is high for child process -- https://bugs.ruby-lang.org/

2 5

[ruby-core:116801] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by byroot (Jean Boussier) 16 Feb '24

16 Feb '24

Issue #13557 has been updated by byroot (Jean Boussier). I'll try to find some time to implement this in the near future, because I just ran into this today, and resorted to the following hack: ```ruby unless exception.backtrace begin raise exception rescue exception.class => raised_exception raised_exception.backtrace.shift raised_exception.backtrace_locations.shift exception = raised_exception end end ``` I think both `Kernel#raise` and `Exception#set_backtrace` would need to accept array of `Thread::Backtrace::Location`. ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-106824 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Open * Priority: Normal ---------------------------------------- When re-raising exceptions, it is sometimes useful to "massage" the backtrace (especially in DSLs). There is currently no way to do it using only backtrace locations. This causes the new exception to have #backtrace_locations return nil, and thus makes backtrace_locations unreliable as a whole. Example: ~~~ def test raise ArgumentError, "", caller_locations end begin test rescue ArgumentError => e p e.backtrace_locations end ~~~ attempting to pass `caller_location` to `Kernel#raise` in the `test` method fails with `bla.rb:2:in `set_backtrace': backtrace must be Array of String (TypeError)` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116797] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by byroot (Jean Boussier) 16 Feb '24

16 Feb '24

Issue #19117 has been updated by byroot (Jean Boussier). > I can probably restore rescue in and ensure in with the above inconsistency. Do you like it? I honestly don't mind either way, I noticed this while updating the Rails test suite, figured I'd report it in case it wasn't intentional. I suppose you could argue that `rescue in` has some value, as it shows there was some error handling, but I'm not particularly attached to it. I'm totally fine with removing it. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106820 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116796] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by mame (Yusuke Endoh) 16 Feb '24

16 Feb '24

Issue #19117 has been updated by mame (Yusuke Endoh). You've been found out! During this work, I noticed a problem with the inconsistency of `ensure in`. ```ruby begin ensure p caller(0) #=> ["test.rb:3:in `<main>'"] end begin raise ensure p caller(0) #=> ["test.rb:9:in `ensure in <main>'", "test.rb:9:in `<main>'"] end ``` If it enters into the ensure clause with an exception, you will see `ensure in`. But if it enters normally (without an exception), you will not see `ensure in`. This depends on the implementation details of `ensure` in RubyVM. I discussed this with @ko1, and we decided to remove `ensure in` (and `rescue in` as well). So I removed it intentionally and hoped no one noticed it :-P I can probably restore `rescue in` and `ensure in` with the above inconsistency. Do you like it? ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106819 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0