Issue #21795 has been updated by kddnewton (Kevin Newton). @eregon — I have tried start/end line/column extensively. It did not work at all for Rails or error highlight, and I spent too long on it to revisit it. Also, it has been rejected twice in this thread alone. If, regardless, you would like to keep pursuing it, you need to produce working code for those two examples. Arguing theoretically is not productive at this point. I agree with @Earlopain that moving the repository into ruby/ruby doesn't necessarily solve the problem, the issue is about released gem versions versus vendored versions. I also am sympathetic to @mame's point that it feels odd to keep the parser out of the main repository. I think it's the best solution for now as it is since we can move faster iterating on a smaller codebase. I don't think it's necessarily ideal, but I do think we shouldn't change it. I would like to pursue the ABI version regardless of the CRuby decision here. As @eregon noted, node_id has difficulties across versions, and that solves that problem. I also think this is a good approach because even though 2.0.0 of Prism is about to be released and it has a ton of changes inside it, it actually _wouldn't_ increase the ABI version (no node shapes changed, even though a ton of code changed). Further evidence that the ABI version is good: since the beginning of 2024, we would only have had to bump the ABI version twice. The first was for the 0.25.0 release, and the second would be for the upcoming 2.0.0 release. AST shape just does not change very much or very fast. On the other hand, we have had more than a dozen releases of the prism gem in that time. So the ABI remains stable and we can rely on node_id, but the Prism gem is still able to iterate quickly and release new code easily. It feels like the best of both worlds. ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795#change-117118 * 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/