Issue #21005 has been updated by tenderlovemaking (Aaron Patterson). mame (Yusuke Endoh) wrote in #note-12:
tenderlovemaking (Aaron Patterson) wrote in #note-11:
I think we should add a reader method on RubyVM::InstructionSequence to get the node id.
I don't think it is good for a user to handle `node_id` explicitly. Rather, I think Prism should provide a simple method to directly retrieve a node subtree of a Method/Proc object given, like `RubyVM::AST.of`.
I agree. The problem is that `RubyVM::AST` is built in to Ruby, so it has access to `rb_iseq_t` members. Prism cannot access fields on `rb_iseq_t`. My idea is to apply a patch like this to iseq.c: https://github.com/tenderlove/ruby/commit/9a54230012d8837a981e0ddec88384ab6e... Then add code to Prism like this: ```ruby require "prism" # Put the following code in Prism module Prism def self.ast_for iseq ast = Prism.parse(File.read(iseq.absolute_path)) node_id = iseq.node_id ast.value.breadth_first_search { |node| node.node_id == node_id } end end # User code is below f = proc { <<END } heredoc END iseq = RubyVM::InstructionSequence.of(f) tree = Prism.ast_for(iseq) p tree ``` I implemented the Prism method as a monkey patch just as demonstration. But the idea is the same as `RubyVM::AbstractSyntaxTree.of`, where `Prism.ast_for` takes an iseq object and returns the AST for that iseq. ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005#change-111357 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/