- ruby-core - ml.ruby-lang.org

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

17 Feb '24

Issue #19117 has been updated by Eregon (Benoit Daloze). > I think that we should discuss further improvements in a separate ticket. OK: #20275 ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106846 * 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:116818] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 17 Feb '24

17 Feb '24

Issue #19117 has been updated by Eregon (Benoit Daloze). @Dan0042 I think `block in` should stay because those must be calls and have their own frame semantically. The quotes are around the `block in` (on master), which makes sense because that's the name of the "thing being called". I.e. the block is being called, the surrounding method might not be on the stack at all, e.g.: ``` $ ruby -e 'def m = proc { raise }; m.call' -e:1:in 'block in Object#m': unhandled exception from -e:1:in '<main>' ``` ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106841 * 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:116812] [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). 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