Project

General

Profile

Actions

Feature #19451

open

Extract path and line number from SyntaxError?

Feature #19451: Extract path and line number from SyntaxError?

Added by ioquatix (Samuel Williams) over 2 years ago. Updated over 2 years 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 - Feature #19452: `Thread::Backtrace::Location` should have column information if possible.OpenActions

Updated by ioquatix (Samuel Williams) over 2 years ago Actions #1 [ruby-core:112504]

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

Updated by ioquatix (Samuel Williams) over 2 years ago Actions #2

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

Updated by zverok (Victor Shepelev) over 2 years ago Actions #3 [ruby-core:112506]

FWIW, SyntaxError#path was added in 3.2

Updated by Eregon (Benoit Daloze) over 2 years ago Actions #4 [ruby-core:112511]

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 2 years ago Actions #5 [ruby-core:112513]

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 2 years ago Actions #6 [ruby-core:112515]

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 2 years ago Actions #7 [ruby-core:112518]

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 2 years ago Actions #8 [ruby-core:112519]

@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 2 years ago Actions #9 [ruby-core:112705]

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: PDF Atom