Issue #20260 has been updated by Eregon (Benoit Daloze). It would be great if `ErrorHighlight` can work on other Ruby implementations too, which means not relying on `RubyVM`. `Thread::Backtrace::Location#node_id` might not be ideal because other Ruby implementations AFAIK don't keep a `node_id` (for footprint reasons). TruffleRuby OTOH keeps the byte offset and byte length of each node, so this could be used to identify a given call node. That also seems similar to the 2nd paragraph in https://github.com/ruby/prism/issues/2401. I think ErrorHighlight could even use the byte offset + byte length to reparse just that part of the file and find where the `.`/`[`/etc is. Then the generic implementation-agnostic API could be `Thread::Backtrace::Location#{byte_offset,byte_length}` (or `{first_column,first_lineno,last_column,last_lineno}` but it seems less efficient/convenient). Or even `Thread::Backtrace::Location#code` which would return a String containing the source code of that call node. @mame WDYT, would one of these be enough for `ErrorHighlight`? If so it sounds ideal because it avoids needing implementation details like `node_id`, `iseq`, etc. ---------------------------------------- Misc #20260: ISEQ flag for prism compiler https://bugs.ruby-lang.org/issues/20260#change-106770 * 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/