Issue #21795 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-27:
That said, it is also an unshakable fact that perfect behavior is hard to guarantee with a different version of prism.
Yes, as I have shown above it is incorrect in some cases and as more time passes/prism changes/the syntax changes it will happen for more cases. I will make a proposal for `Thread::Backtrace::Location#source_range` soon, which addresses that concern by using `[start line, start column, end line, end column]` which is far more stable across versions. Also, importantly it will work regardless of the `--parser=...` option value, and on all Ruby implementations. And it will remove the need for `node_id_for_backtrace_location` which only works on CRuby. mame (Yusuke Endoh) wrote in #note-27:
With `--parser=parse.y`, `Proc#syntax_tree` returns an instance of `RubyVM::AbstractSyntaxTree::Node`.
I think this makes this new method unusable and very brittle, because no gem should have to handle both kinds of node (at least new gems using this new method, I know some gems currently handle both kinds), especially since they are so different APIs. It's also a problem because Prism is the official API to parse Ruby code, but this would add a core method returning a RubyVM::AST::Node. That's exposing RubyVM::AST::Node more when it's marked experimental and already kind of deprecated. ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795#change-118163 * 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/