From: eregontp@... Date: 2021-06-11T10:01:34+00:00 Subject: [ruby-core:104234] [Ruby master Feature#17930] Add column information into error backtrace Issue #17930 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-14: > If needed, we can implement `Thread::Backtrace::Location#code_location` by using `AST.of`. > If @eregon wants this, we may introduce this as a built-in method. I think it is good to add, as basically `Thread::Backtrace::Location`-backtraces (caller_locations, backtrace_locations) then get column information, which might be nice in debugger, user-formatted backtraces (e.g. in HTML one could highlight that region of code), etc. > But as @yuki24 said, I believe this is less useful because it is too rough for the underline feature. To clarify, you mean it would show: ``` data["data"].first["field"].bar ^^^^^^^^^^^^^^^^^^^^^^^^^^^ json.first.fisrt.bar ^^^^^^^^^^^^^^^^ ``` instead of: ``` data["data"].first["field"].bar ^^^^^^^^^ json.first.fisrt.bar ^^^^^^ ``` That seems enough to know which one it was, but it is indeed less clear. @mame How do you think about something like `NoMethodError#code_location` (or some other name) that would return the lines&cols for that second region? I think that would be possible when we have the call node or bytecode's node_id, and then can find the receiver node's last column (& line) from there. It might not always be available, e.g., from `public_send` or from `rb_funcall()`, but that seems unavoidable anyway. ---------------------------------------- Feature #17930: Add column information into error backtrace https://bugs.ruby-lang.org/issues/17930#change-92418 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: mame (Yusuke Endoh) ---------------------------------------- Consider the following code and error. ``` data["data"].first["field"] #=> undefined method `[]` for nil:NilClass ``` There are two possibilities; the variable `data` is nil, or the return value of `first` is nil. Unfortunately, the error message is less informative to say which. This proposal allows to help identifying which method call failed. ``` $ ruby -r ./sample/no_method_error_ext.rb err1.rb err1.rb:2:in `
': undefined method `[]' for nil:NilClass (NoMethodError) data["data"].first["field"] ^^^^^^^^^ ``` ## Proposal I'd like to propose a feature to get column information from each `Thread::BacktraceLocation`. Maybe it is good to provide the following four methods: * `Thread::BacktraceLocation#first_lineno` * `Thread::BacktraceLocation#first_column` * `Thread::BacktraceLocation#last_lineno` * `Thread::BacktraceLocation#last_column` These names came from `RubyVM::AbstraceSyntaxTree::Node`'s methods. ## Implementation Here is a proof-of-concept implementation: https://github.com/ruby/ruby/pull/4540 See https://github.com/ruby/ruby/pull/4540/commits/6ff516f4985826e9f9c5606638001c3c420f7cad for an example usage. (Note that, currently, you need to build ruby with `./configure cflags=-DEXPERIMENTAL_ISEQ_NODE_ID` to enable the feature.) To put it simply, this PR provides only a raw API, `Thread::BacktraceLocation#node_id`. To get actual column information, you need to manually identify `RubyVM::AbstractSyntaxTree::Node` that corresponds to `Thread::BacktraceLocation#node_id`. But it would be arguable to expose "node_id", so I will wrap it as the above four methods if this is accepted. Credit: the original implementation was done by @yui-knk. ## Drawback To use this feature, we need to enable `-DEXPERIMENTAL_ISEQ_NODE_ID` to add "node_id" information (a subtree ID of the original abstract syntax tree) into each byte code instruction. If we provide this feature, the option should be enabled by default. However, the option increases memory consumption. I performed a simple experiment: I created a scaffold app by `rails new`, and measured the memory usage after `rails s`. The result was 97 MB without `-DEXPERIMENTAL_ISEQ_NODE_ID`, and 100 MB with the option enabled. In my opinion, it is not so large, but requiring more gems will increase the difference. I will appriciate it if anyone could provide the actual memory increase in a more practical Rails app. Do you think this feature deserves the memory increase? ---Files-------------------------------- image.png (73.3 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: