Issue #20260 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-11:
@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.
I think for call nodes it would identify uniquely, but it may not be true for all nodes.
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.
It's basically byte_offset and byte_length vs line and node_id. If all 4 are the same integer size then it's the same in memory footprint, but from byte_offset and byte_length we also have precise column information readily available without parsing again (although that means keeping the source code in memory or rereading the file, could be avoided if a file is only US-ASCII characters then only line offsets is enough), which is nice for tools, debugger, etc. ---------------------------------------- Misc #20260: ISEQ flag for prism compiler https://bugs.ruby-lang.org/issues/20260#change-106802 * 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/