Project

General

Profile

Actions

Feature #19451

open

Extract path and line number from SyntaxError?

Added by ioquatix (Samuel Williams) over 1 year ago. Updated over 1 year ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:112503]

Description

There doesn't seem to be any official way to extract the path and line number from a syntax error.

There are two ways I can see us dong this:

  • Provide explicit path and line_number attributes.
  • Prepend them to backtrace_locations.

The nice thing about the latter approach is that it will just work with existing tools which understand how to highlight code based on backtrace locations.

Maybe we should do both?


Related issues 1 (1 open0 closed)

Related to Ruby master - Feature #19452: `Thread::Backtrace::Location` should have column information if possible.OpenActions

Updated by ioquatix (Samuel Williams) over 1 year ago

(and while we are at it, how about column information?)

Actions #2

Updated by ioquatix (Samuel Williams) over 1 year ago

  • Related to Feature #19452: `Thread::Backtrace::Location` should have column information if possible. added

Updated by zverok (Victor Shepelev) over 1 year ago

FWIW, SyntaxError#path was added in 3.2

Updated by Eregon (Benoit Daloze) over 1 year ago

The calling backtrace and the location of the syntax error are separated things, so I don't think we should mix them.
Adding SyntaxError#lineno would make sense IMO.

Updated by rubyFeedback (robert heiler) over 1 year ago

Is it #lineno or #line_number? I would think #line_number would look prettier,
if we add a method to SyntaxError. (Not saying we should do, or should not do,
either; just pointing at the different names above ^^^.)

Also good to see zverok knows the API really well now due to his documentation
effort. :D

Updated by schneems (Richard Schneeman) over 1 year ago

It's also worth mentioning that not all syntax errors have an associated path. eval, code piped to STDIN, and ruby -e can have invalid syntax but might not have an associated path. In the discussion around adding SyntaxSuggest to Ruby 3.2 I asked for something like SyntaxError#source that would let me access the source code for these elements, but it was not implemented before 3.2 was released.

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

SyntaxError can contain multiple error locations.
I'm trying https://github.com/nobu/ruby/tree/SyntaxError%23diagnostics.

I can't get what "prepend them to backtrace_locations" means.

Updated by ioquatix (Samuel Williams) over 1 year ago

@nobu (Nobuyoshi Nakada) most text editors need a single line and column for each backtrace location.

As it stands, just looking at the backtrack locations is not enough. For SyntaxError, the editor needs to know the "first location" which is the point the syntax error occurred.

There are two ways this can be done:

(1) SyntaxError#path / #line / #column information + SyntaxError#backtrace_locations
(2) SyntaxError#backtrace_locations[0] contains the above #path #line and #column information, followed by the normal backtrace.

By "prepend them to the backtrace_locations" I mean option (2), which is far easier for the editor to consume, since it won't have to know the specific details of how "SyntaxError" works, it will just put markers at each backtrace_locations, with the error details itself on backtrace_locations[0].

Updated by mame (Yusuke Endoh) over 1 year ago

Unfortuantely, the description of this proposal is very poor. It is not at all clear what is being proposed for what use case.

Actions

Also available in: Atom PDF

Like1
Like0Like0Like0Like0Like0Like0Like0Like0Like0