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

[ruby-core:116814] [Ruby master Feature#20273] Disable callcc when compiled with ASAN
by kjtsanaktsidis (KJ Tsanaktsidis) 18 Feb '24

18 Feb '24

Issue #20273 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #20273: Disable callcc when compiled with ASAN https://bugs.ruby-lang.org/issues/20273 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- Currently, all of the callcc related tests in the Ruby test suite fail when Ruby is compiled with ASAN (CFLAGS="-fsanitize=address"). Unfortunately, I don't believe it's possible for calcc to be supported with ASAN at all. callcc is implemented by: * When saving a continuation, we take a copy of C the stack, and a jmpbuf with `setjmp`. * When calling a continuation, we memcpy the C stack back from the saved copy (using `alloca` to move the current top-of-stack out of the way of this copying), and then `longjmp`'ing back to the saved state There are a few reasons this can't work with ASAN - some fixable, some not: * The copying of the original stack when creating a continuation requires reading stack memory from outside the current function, which ASAN does not allow (and, likewise with copying the stack back). This _can_ be fixed by using a custom memcpy implementation which has `__attribute__((no_sanitize("address")))`. * When we restore the original stack, we _also_ need to restore the shadow-words for that memory range (which record the state of what memory is and is not valid according to ASAN). ASAN does not expose a pointer to the shadow stack to allow it to be copied like this, but this is _in theory_ something which we could patch in LLVM if we wanted to. * With ASAN, many local variables are not actually on the stack - rather, they're stored in a special "fake stack" (i think to enable detecting cases of stack-use-after-return). (I think) ASAN essentially malloc's memory for each function frame to hold these fake values, and frees them when the function returns. With callcc, some functions whose fake frames have already been freed might be re-entered, but the "fake stack" holding their local variables will have been freed. I don't believe there's a way to fix this that I can think of. --- Therefore, I propose that: * When cruby is compiled with `-fsanitize=address` in CFLAGS, `Kernel#callcc` is `rb_f_notimplement`. * That means `Kernel#respond_to?(:callcc) == false`, and `Kernel#callcc` raises `NotImplementedError` * Tests in the cruby test suite which use `callcc` check `respond_to?(:callcc)` and skip themselves if so. Since callcc is deprecated and meant only to be used for... um... "fun" things (https://bugs.ruby-lang.org/issues/10548) I think this is an acceptable tradeoff. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116830] [Ruby master Bug#20278] syntax error, unexpected local variable or method, expecting ')' (SyntaxError) - but I think it should report that a ',' is missing, or alternatively, that suggesting ')' is the most likely cause but not always (e. g. reword it a bit)
by rubyFeedback (robert heiler) 18 Feb '24

18 Feb '24

Issue #20278 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Bug #20278: syntax error, unexpected local variable or method, expecting ')' (SyntaxError) - but I think it should report that a ',' is missing, or alternatively, that suggesting ')' is the most likely cause but not always (e. g. reword it a bit) https://bugs.ruby-lang.org/issues/20278 * Author: rubyFeedback (robert heiler) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- So this is not quite a bug, but I thought it may fit better here, as it is neither a feature, and also not quite fitting under misc. Before I will explain the issue, let me copy/paste the code I use so that others can reproduce what I mean: class Foobar def foo1 var1 = 1 var2 = 2 Foobar.some_method( var1 var2 ) end def self.some_method(a, b) puts a end end Foobar.new If it helps, the faulty lines are those between line 7 and 8, where I passed two variables var1 and var2, but I forgot a ',' between these two. I actually had this happen just now in another (real) code, and the error message confused me. Anyway, there are two things I want to report here. First, the smaller issue - the description show on the commandline is strange: expected a `)` to close the argumentsexpected a newline or semicolon after the statementcannot parse the expression Normally it should read "to close the arguments expected". It seems the ' ' space character between "arguments expected" is swallowed; same with the "statementcannot". But that is just description - I report it in the event someone else also finds it strange. I actually did not see it at first as I always look at the bottom first, so I tend to miss what appears on top. Anyway. The second one, and reason why I wrote this issue here, is that the error shown is a bit confusing: ack.rb:8: syntax error, unexpected local variable or method, expecting ')' (SyntaxError) var2 So ruby indicates that there is an issue with var2 and a ')' was expecting. But I think ruby should instead have expected a ','. I don't know whether ruby can distinguish between this; both var1 and var2 were already defined prior, so I think in theory the ruby parser could find out that there are two separate variables, and assume that a ',' could also be missing. I don't know if this is always the case, but at the least I think in the example code I showed, ruby saying that a ')' was expected, was wrong, in my opinion. Again, perhaps ruby has no way to distinguish, but as ruby gives a specific suggestion that there is a missing ')', when in reality I was missing the ',', is in my opinion incorrect. Perhaps it is not worth to fix it, but being able to distinguish at the least between two local variables (as in var1 and var2) should be possible, and perhaps the overall message shown could be improved a bit. For instance, the line " the argumentsexpected" could perhaps not only NOT swallow the ' ' but also be displayed on two lines. I am not sure if this makes it better or worse, since people's preferences are different. Either way I wanted to bring this to attention here. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116828] [Ruby master Feature#16495] Inconsistent quotes in error messages
by ioquatix (Samuel Williams) 17 Feb '24

17 Feb '24

Issue #16495 has been updated by ioquatix (Samuel Williams). For reference, so far I had to make one fix: - https://github.com/socketry/async/compare/2c5f92ed2027...44b2060dffd7 It was minor and compatibility with both styles is trivial. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106853 * Author: Kolano (Kenneth Kolano) * Status: Closed * 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: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) 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