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

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

19 Jan '24

Issue #19117 has been updated by Dan0042 (Daniel DeLorme). It's not so much the length but the redundancy. "connection_adapters/abstract/database_statements" is repeated as "ActiveRecord::ConnectionAdapters::DatabaseStatements" It's hard for me to say if I would like the feature or not, without seeing a full Rails backtrace. Just one line gives a certain foretaste, but not enough for a clear opinion. And at least the test.rb example certainly looked better. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106362 * Author: byroot (Jean Boussier) * Status: Open * 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:116335] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by byroot (Jean Boussier) 19 Jan '24

19 Jan '24

Issue #19117 has been updated by byroot (Jean Boussier). > Please try it with a Rails backtrace, so you get something like: @Dan0042 I find that is much better than the existing backtrace. ¯\\\_(ツ)_/¯ I mean, we're including more information, so yes it's longer, but in your example it's the file location that is causing the line to be too long. You are already at 163 characters, including 131 for the path itself. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106361 * Author: byroot (Jean Boussier) * Status: Open * 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:116334] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Dan0042 (Daniel DeLorme) 19 Jan '24

19 Jan '24

Issue #19117 has been updated by Dan0042 (Daniel DeLorme). Please try it with a Rails backtrace, so you get something like: ``` #before from /opt/ruby/3.1/lib/ruby/gems/3.1.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:531: in 'with_multi_statements' #after from /opt/ruby/3.1/lib/ruby/gems/3.1.0/gems/activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:531: in 'ActiveRecord::ConnectionAdapters::DatabaseStatements#with_multi_statements' ``` Much less beautiful than the (contrived) example, imho. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106360 * Author: byroot (Jean Boussier) * Status: Open * 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:116324] [Ruby master Bug#8973] Allow to configure archlibdir for multiarch
by vo.x (Vit Ondruch) 19 Jan '24

19 Jan '24

Issue #8973 has been updated by vo.x (Vit Ondruch). Can this be reopened or should create new ticket? ---------------------------------------- Bug #8973: Allow to configure archlibdir for multiarch https://bugs.ruby-lang.org/issues/8973#change-106350 * Author: vo.x (Vit Ondruch) * Status: Feedback * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.1.0dev (2013-09-22 trunk 43011) [x86_64-linux] ---------------------------------------- Since r39347, there is impossible to configure placement of rubylib.so when build is configured with "--with-multiarch". That is probably OK for Debian, but it breaks Fedora :/ The attached patch allows to configure the archlibdir, but I feel that it is suboptimal, since the "--with-rubyarchprefix" should probably be the parameter which influences placement of the arch specific libraries. Any chance that this patch is accepted or better if rubyarchprefix is respected for every arch specific library, including libruby.so. Thanks. ---Files-------------------------------- ruby-2.1.0-Enable-configuration-of-archlibdir.patch (479 Bytes) -- https://bugs.ruby-lang.org/

1 0

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

19 Jan '24

Issue #19117 has been updated by byroot (Jean Boussier). I tried the following (contrived) script: ```ruby class Abstract def oops yield end end class Concrete < Abstract class << self def oops(&block) new.oops { 1 + "1" } end end def oops(&block) tap do super(&block) end end end Concrete.method(:oops).call ``` 3.3: ``` test.rb:10:in `+': String can't be coerced into Integer (TypeError) from test.rb:10:in `block in oops' from test.rb:3:in `oops' from test.rb:16:in `block in oops' from <internal:kernel>:90:in `tap' from test.rb:15:in `oops' from test.rb:10:in `oops' from test.rb:21:in `call' from test.rb:21:in `<main>' ``` Your branch: ``` ./test.rb:10:in `Integer#+': String can't be coerced into Integer (TypeError) from ./test.rb:10:in `block in Concrete.oops' from ./test.rb:3:in `Abstract#oops' from ./test.rb:16:in `block in Concrete#oops' from <internal:kernel>:90:in `Kernel#tap' from ./test.rb:15:in `Concrete#oops' from ./test.rb:10:in `Concrete.oops' from ./test.rb:21:in `Method#call' from ./test.rb:21:in `<main>' ``` I think it very significantly improve the backtrace readability. Things like `call` becoming `Method#call` is really great. I also love in your example that `toplevel` is displayed as `Object#toplevel`, I think it could help quite a few people realize that defining a method at the top level defines it in `Object`. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106347 * Author: byroot (Jean Boussier) * Status: Open * 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:116320] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by byroot (Jean Boussier) 19 Jan '24

19 Jan '24

Issue #19117 has been updated by byroot (Jean Boussier). > What do you think? I think it's beautiful. I'll try to get some time to build your branch and play with it, see how it behave in more corner-casy situations. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106346 * Author: byroot (Jean Boussier) * Status: Open * 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:114997] [Ruby master Bug#19918] Should `a[&b]=c` be syntax valid?
by tompng (tomoya ishida) 19 Jan '24

19 Jan '24

Issue #19918 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19918: Should `a[&b]=c` be syntax valid? https://bugs.ruby-lang.org/issues/19918 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-11T04:46:58Z master 40ab7b8c24) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These codes are syntax valid now. Prism parses it as syntax error. ~~~ruby a[&b]=c a[&b]+=c a[&b]&&=c a[&b]||=c ~~~ Is this syntax intentional or should be error? Issue of Prism https://github.com/ruby/prism/issues/1636 It's added in test_parse.rb https://github.com/ruby/ruby/blob/40ab7b8c244de20007cb45846f41de3a01f7ea0c/… -- https://bugs.ruby-lang.org/

5 6

[ruby-core:116313] [Ruby master Feature#16495] Inconsistent quotes in error messages
by mame (Yusuke Endoh) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by mame (Yusuke Endoh). I prototyped it: https://github.com/ruby/ruby/pull/9608 Still need to update prism and ruby/spec. For information in impact assessment: this change made 140 tests fail in `make test-all`. Many of them examined error messages, which could be fixed by simply updating the expected regular expression. But there were some non-trivial effects, e.g., irb converts the error message from `` `top (required)' `` to `` `<main>' ``, so this conversion code is also updated. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106337 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

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

18 Jan '24

Issue #19117 has been updated by mame (Yusuke Endoh). I prototyped this proposal: https://github.com/ruby/ruby/pull/9605 Fortunately, this would bring neither perrformance degredation nor extra memory usage when an exception is raised because I just replaced the method id with the method entry object in Thread::Backtrace::Location. (To get the method id, we need to read it via the method entry object, but I believe it is ignorable.) The notation is as follows. * Instance methods of named classes are `ClassName#method_name`. * Class methods for named classes are `ClassName.method_name`. * Only `method_name` otherwise I think I properly support `block in ClassName#method_name` and so on. ``` $ cat test.rb def toplevel = raise class Foo def self.class_meth = toplevel def instance_meth = Foo.class_meth end obj = Foo.new def obj.singleton_meth = instance_meth obj.singleton_meth $ ./miniruby test.rb test.rb:1:in 'Object#toplevel': unhandled exception from test.rb:4:in 'Foo.class_meth' from test.rb:6:in 'Foo#instance_meth' from test.rb:11:in 'singleton_meth' from test.rb:13:in '<main>' ``` @byroot What do you think? This causes some tests to fail, but I haven't fixed the test yet. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106336 * Author: byroot (Jean Boussier) * Status: Open * 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:116310] [Ruby master Feature#16495] Inconsistent quotes in error messages
by mame (Yusuke Endoh) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by mame (Yusuke Endoh). Let me add a little to the matz's decision. At the dev meeting, he said that we will replace with a single quote, not only the backticks for `NameError#message`, but also the ones for other exception messages (e.g., ``no superclass method `foo'``) and the ones surrounding the names of methods in the backtrace (e.g., ``from test.rb:2:in `foo'``). Matz also wants to experiment with #19117 as well, and I am writing an experimental patch for that. If this is also applied, each line of the backtrace will be ``` before: from test.rb:9:in `foo' after : from test.rb:9:in `Kernel#p' ``` We recognize that both this ticket and #19117 are not small incompatibilities, so if they actually change, it would be nice to change them both at once. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106334 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0