My motivation here is I would like to implement `Thread::Bactrace::Location#source_range`. For this to work in `--parser=parse.y` mode it needs to return the same start/end line/column as Prism in all cases of `RubyVM::AbstractSyntaxTre...Eregon (Benoit Daloze)
The current locations are like this: ``` foo(1, 2, kw: :arg) { 123 } |---------ITER------------| |------FCALL------| |SCOPE| ``` When `foo` does not exist, it's a `NoMethodError`, and `RubyVM::AbstractSyntaxTree.of e.backtrace_locations...Eregon (Benoit Daloze)
I think this is safe to reject, I think it's not feasible to change this. One should avoid mutating the Array while iterating, otherwise this kind of behavior is expected.Eregon (Benoit Daloze)
IMO it's not reasonable for `Array#delete_if` to do anything else than what it already does. How can `Array#delete_if` know which element you deleted and whether it should delete or not? The block returns true for the second 2nd block ca...Eregon (Benoit Daloze)
@tikkss I think there is an issue with your accounting of memory because it doesn't match the RSS of the worker process. This is running your example as-is. ``` $ ruby -v ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux]...Eregon (Benoit Daloze)
Eregon (Benoit Daloze) wrote in #note-10: > I'm not sure if [@matz (Yukihiro Matsumoto)](/users/13) made his mind on: Start position: from the `p` of `proc`? Or from the `{`? I confirmed with both @mame and @matz, and matz said it sh...Eregon (Benoit Daloze)
For ```ruby l = -> x, y { x + y } l.call(1) ``` ErrorHighlight shows: ``` test.rb:1:in 'block in <main>': wrong number of arguments (given 1, expected 2) (ArgumentError) caller: test.rb:5 | l.call(1) ^^^^...Eregon (Benoit Daloze)