Issue #21795 has been updated by Eregon (Benoit Daloze). kddnewton (Kevin Newton) wrote in #note-21:
If, regardless, you would like to keep pursuing it, you need to produce working code for those two examples.
Done: https://github.com/eregon/error_highlight/pull/1 https://github.com/eregon/rails/pull/1 The error_highlight test suite passes, and the tests I found in ActionView pass too. These PRs use the column information from `RubyVM::AbstractSyntaxTree::Node` and from `Prism` until there is a better API to get that from a `Thread::Backtrace::Location`. The error_highlight PR even shows that it's working with latest Prism (1.9.0) + Ruby 3.3 & 3.2 (which use parse.y by default). There is some adjustment needed from the location that `RubyVM::AbstractSyntaxTree::Node` reports, e.g. it reports `1.time` as the `NoMethodError#backtrace_locations[0]` for the code `1.time { a }`. I believe we can fix this, e.g. by giving the `node_id` of the `ITER` instead of the `CALL` to the bytecode in such a case, or adapting the location of the `CALL` node: ```ruby irb(main):001> RubyVM::AbstractSyntaxTree.parse("1.time { a }") => (SCOPE@1:0-1:12 tbl: [] args: nil body: (ITER@1:0-1:12 (CALL@1:0-1:6 (INTEGER@1:0-1:1 1) :time nil) (SCOPE@1:7-1:12 tbl: [] args: nil body: (VCALL@1:9-1:10 :a)))) ``` ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795#change-117132 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/