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

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


mame (Yusuke Endoh) wrote in #note-17:


> BTW, I'd like to hear opinions from you, especially English native people=
, about the feature name. I tentatively named it "error_squiggle". Squiggle=
 means a wavy underline used to indicate an error in code. But @pocke said =
that the feature name should not depend on its output appearance because we=
 may change how to display in future.
> =

> The name is not so important because a casual user will not refer the nam=
e directly, but we need to decide it anyway. Do you have any idea about the=
 name?
> =

> * error_emph / error_emphasize
> * error_highlight
> * error_spotter
> * pretty_error
> * power_error (respected to https://github.com/ruby/power_assert)

I think `error_highlight` might be best. `error_emphasize` is a verb, which=
 is often best for a method name, but not necessarily here. Maybe `error_em=
phasis` could work. In a strict sense, 'highlight' is also presentation-spe=
cific (and also a verb besides being a noun), but in its wider sense, it wo=
rks very well.

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

* 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>