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

[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) 19 Jan '24

19 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) 19 Jan '24

19 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

[ruby-core:116299] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Eregon (Benoit Daloze) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Eregon (Benoit Daloze). Great to see progress on this issue. Agreed, for method names and file names, single quotes are best. Backticks are best for quoting source code, and there is no source code in Ruby backtraces. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106321 * 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:116298] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 18 Jan '24

18 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). I think everyone's opinion on the thread is pretty clear and not everyone agrees, that's fine. @matz Could you decide whether it's OK to experiment with the Encoding#name changing to "BINARY" or not? If not, is @byroot's proposal in https://bugs.ruby-lang.org/issues/18576#note-33 accepted? ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106320 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116296] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Dan0042 (Daniel DeLorme) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Dan0042 (Daniel DeLorme). I'd like something that's convenient to copy-paste. Testing: with single quote pair: undefined local variable or method 'foobar' for main:Object (NameError) `undefined local variable or method 'foobar' for main:Object (NameError)` ``undefined local variable or method 'foobar' for main:Object (NameError)`` with backtick pair: undefined local variable or method `foobar` for main:Object (NameError) `undefined local variable or method `foobar` for main:Object (NameError)` ``undefined local variable or method `foobar` for main:Object (NameError)`` At first I preferred backticks but given how the above are rendered in markdown I've ended up preferring single quotes. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106318 * 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:116295] [Ruby master Feature#16495] Inconsistent quotes in error messages
by matz (Yukihiro Matsumoto) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by matz (Yukihiro Matsumoto). I agree with giving up backquotes. I'd rather use single quote pairs, unless any compatibility issues are caused. Matz. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106317 * 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