[ruby-core:104415] [Ruby master Feature#17930] Add column information into error backtrace

Issue #17930 has been updated by duerst (Martin D=FCrst).


sawa (Tsuyoshi Sawada) wrote in #note-24:
> To my understanding, the word "prettify" means and has been used to add c=
osmetics to the output, like adding line breaks and indenting or adding col=
ors. The words "emphasis" and "highlight" are in a similar vein. The functi=
onality in question here is not about cosmetics, but is to add information =
to the output, so I think it might not be appropriate to use these words.

If all of pretty/emphasis/highlight are problematic, what's your suggestion?

I can very well imagine that instead of "squiggles" (^^^^^ or so), on a col=
ored display some kind of actual highlighting (in the narrow sense) might b=
e used. Both emphasis and highlight make clear that a specific part of the =
output is more important than the rest, which is exactly what we are talkin=
g about.

----------------------------------------
Feature #17930: Add column information into error backtrace
https://bugs.ruby-lang.org/issues/17930#change-92663

* Author: mame (Yusuke Endoh)
* Status: Assigned
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
----------------------------------------
Consider the following code and error.

```
data["data"].first["field"] #=3D> undefined method `[]` for nil:NilClass
```

There are two possibilities; the variable `data` is nil, or the return valu=
e of `first` is nil. Unfortunately, the error message is less informative t=
o 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 `<main>': undefined method `[]' for nil:NilClass (NoMethodErro=
r)

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/pul=
l/4540

See https://github.com/ruby/ruby/pull/4540/commits/6ff516f4985826e9f9c56066=
38001c3c420f7cad for an example usage.
(Note that, currently, you need to build ruby with `./configure cflags=3D-D=
EXPERIMENTAL_ISEQ_NODE_ID` to enable the feature.)

To put it simply, this PR provides only a raw API, `Thread::BacktraceLocati=
on#node_id`. To get actual column information, you need to manually identif=
y `RubyVM::AbstractSyntaxTree::Node` that corresponds to `Thread::Backtrace=
Location#node_id`.
But it would be arguable to expose "node_id", so I will wrap it as the abov=
e 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 sho=
uld be enabled by default. However, the option increases memory consumption.

I performed a simple experiment: I created a scaffold app by `rails new`, a=
nd 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 th=
e difference. I will appriciate it if anyone could provide the actual memor=
y 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: <mailto:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>