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

[ruby-core:116848] [Ruby master Feature#11446] Possible work around for the requirement to supplying arguments like this: .map(&:method, <arguments>)
by artemb (Artem Borodkin) 19 Feb '24

19 Feb '24

Issue #11446 has been updated by artemb (Artem Borodkin). Are there any proposal issues regarding the addition of argument and block support for the ```.each(&:method, args) do; end``` syntax? It seems quite feasible to support it natively. ``` ruby module Enumerable def each_call(method, *args, &) = each { _1.send method, *args, & } def map_call!(method, *args, &) = map! { _1.send method, *args, & } # ... end # [1,2].map! &:+, 1 [1,2].map_call! :+, 1 # [].each &:instance_eval do %w[1 2].each_call :instance_eval do @v = 1 end ``` ---------------------------------------- Feature #11446: Possible work around for the requirement to supplying arguments like this: .map(&:method, <arguments>) https://bugs.ruby-lang.org/issues/11446#change-106877 * Author: jikkujose (Jikku Jose) * Status: Open * Priority: Normal ---------------------------------------- Any chance this [work around](http://stackoverflow.com/questions/23695653/can-you-supply-argument… can be considered to be part of the language. Seems to be a pretty neat. NB: Matz seems to be interested in having this added: Check his [tweet](https://twitter.com/yukihiro_matz/status/632016695016620033). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116845] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by byroot (Jean Boussier) 19 Feb '24

19 Feb '24

Issue #18576 has been updated by byroot (Jean Boussier). Proposed patch: https://github.com/ruby/ruby/pull/10018 I used my initial suggestion: `ASCII-8BIT (BINARY)`, but if the parentheses are deemed to much, I'm happy to adjust. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106871 * 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:116844] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by byroot (Jean Boussier) 19 Feb '24

19 Feb '24

Issue #13557 has been updated by byroot (Jean Boussier). > So it would be nice to have a shortcut idiom for this, like perhaps raise Error, "message", skip: 3 With my patch it would be: ```ruby raise Error, "message", caller_locations(3) ``` Which I think is simple enough to not warrant and extra `skip:` parameter to `raise`. ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-106870 * 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:116843] [Ruby master Feature#13557] there's no way to pass backtrace locations as a massaged backtrace
by byroot (Jean Boussier) 19 Feb '24

19 Feb '24

Issue #13557 has been updated by byroot (Jean Boussier). Proposed patch here if someone feels like reviewing it: https://github.com/ruby/ruby/pull/10017 ---------------------------------------- Feature #13557: there's no way to pass backtrace locations as a massaged backtrace https://bugs.ruby-lang.org/issues/13557#change-106869 * 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:116837] [Ruby master Misc#20279] `respond_to_missing?` in BasicObject documentation correct?
by ioquatix (Samuel Williams) 19 Feb '24

19 Feb '24

Issue #20279 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Misc #20279: `respond_to_missing?` in BasicObject documentation correct? https://bugs.ruby-lang.org/issues/20279 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- Considering the documentation here: https://ruby-doc.org/3.2.2/BasicObject.html Introduced in: https://github.com/ruby/ruby/commit/3eb7d2b33e3f8555d81db5369eb6fb7100a91e63 I wondered if `or super` is correct in `respond_to_missing?`. For example: ``` irb(main):001* class MyObjectSystem < BasicObject irb(main):002* DELEGATE = [:puts, :p] irb(main):003* irb(main):004* def method_missing(name, *args, &block) irb(main):005* return super unless DELEGATE.include? name irb(main):006* ::Kernel.send(name, *args, &block) irb(main):007* end irb(main):008* irb(main):009* public def respond_to_missing?(name, include_private = false) irb(main):010* DELEGATE.include?(name) or super irb(main):011* end irb(main):012> end => :respond_to_missing? irb(main):013> MyObjectSystem.new.respond_to_missing?(:foo) (irb):5:in `method_missing': super: no superclass method `respond_to_missing?' for an instance of MyObjectSystem (NoMethodError) from (irb):10:in `respond_to_missing?' from (irb):13:in `<main>' from <internal:kernel>:187:in `loop' from /home/samuel/.gem/ruby/3.3.0/gems/irb-1.11.2/exe/irb:9:in `<top (required)>' from /home/samuel/.gem/ruby/3.3.0/bin/irb:25:in `load' from /home/samuel/.gem/ruby/3.3.0/bin/irb:25:in `<main>' ``` It looks wrong to me. In addition, I'd like to know in what situations `BasicObject` should define `respond_to_missing?` - because I was under the impression it was called by `method_missing`. Does `BasicObject#method_missing` have this behaviour? Maybe we can improve the documentation cc @burdettelamar -- https://bugs.ruby-lang.org/

2 4

[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