Issue #20260 has been updated by mame (Yusuke Endoh). @eregon I don't think it is a good idea to try to guess a node from a code range. To identify a unique node, the Prism AST would have to avoid creating multiple nodes from the exact same code range. It may be possible to carefully design the AST that way, but I am afraid if it will prevent from future syntax extensions. Though I don't think node_id is super cool, it will no longer be an implementation detail, assuming the Prism AST. Calculating byte_offset + byte_length from node_id is trivial, and the reverse is not. By the way, is there any advantage of the representation of byte_offset and byte_length? It is larger in size than (or at best equal to) node_id. To display to the user, we need to convert it to lineno + column. It may be useful to blindly extract the corresponding code fragment from a file, but I think such a use case is rare. ---------------------------------------- Misc #20260: ISEQ flag for prism compiler https://bugs.ruby-lang.org/issues/20260#change-106790 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- In order to support error highlight, there's needs to be a way to tell which compiler generated an instruction sequence (compile.c or prism_compile.c). That's because when the file is reparsed to find the node based on the node id, we need to know which parser to use. We can't look at the current parser because it may have been dumped to binary and the parser/compile pair might not match up to the current running process. I would like to add a flag to `rb_iseq_constant_body` that indicates it came from prism, as well as the `:prism` hash key to the misc hash in the array form of iseqs. This will allow us to determine the source of the iseq from both C and Ruby. Since this is user-facing (albeit from an experimental library that shouldn't be relied upon) I wanted to make sure this way okay before merging. -- https://bugs.ruby-lang.org/