Issue #21795 has been updated by Eregon (Benoit Daloze). I discussed this in detail with @mame and @matz. One observation from me is the addition of `Ruby::Node` (which duplicates a very large part of the Prism Ruby API, >100 classes) is mostly motivated from using `node_id`, because reusing `node_id` when mixing different prism_compile.c and prism gem versions is incorrect. But if we use start/end line/column instead then there is no need for `Ruby::Node`, we can return `Prism::Node` in that case and I think that's better because e.g. gems using that can specify which versions of Prism they want, and avoid unexpected breaking change they cannot control e.g. if Ruby 4.1 ships with Prism 1.9 and Ruby 4.2 ships with Prism 2.0. @matz then said that if these methods return `Prism::Node`, then it would make sense that Prism itself defines such methods. I'm not sure it's warranted to monkey-patch core classes like that so I think `Prism.find(Method|UnboundMethod|Proc)` is better. To implement this in Prism we need to know start/end line/column, so #21998. Other advantages of using start/end line/column: * It works with `--parse=parse.y` * It doesn't force Ruby implementations to add `node_id` if they don't otherwise need it. There is also the idea that using `node_id` could be a transparent optimization for the case that prism_compile.c and prism gem versions are the same (and still return `Prism::Node`). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795#change-117086 * 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/