987287 - The js syntax errors encountered through eval() are reported with the file name of the caller of eval()

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[(no longer active)]

See the errors reported in bug 965362.  In that bug we sometimes get a partial js string which we eval().  That can lead to things like syntax errors, but the syntax error is reported as filename:linenumber, where the linenumber is correct but the file name shows the name of the file containing the eval() call, which makes the error message confusing.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is a pure JS issue, no?  If I create a file called test.js containing this single line:

  eval("foo;\n\n\n\nbar(");

and then do ../obj-firefox/dist/bin/js ~/test.js I get:

/Users/bzbarsky/test.js:5:4 SyntaxError: syntax error:
/Users/bzbarsky/test.js:5:4 bar(
/Users/bzbarsky/test.js:5:4 ....^

as in, eval() always uses the line inside the eval string and the file of the eval() caller when reporting its parse errors.

Not sure what would be a better behavior for it...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Fwiw, what Blink reports for that testcase is:

  undefined:5: SyntaxError: Unexpected end of input
  bar(
    
  SyntaxError: Unexpected end of input
    at /Users/bzbarsky/test.js:1:1

and if I examine the exception like so:

  try {
    eval("foo;\n\n\n\nbarbarous(");
  } catch (e) {
    print(e.stack);
  }

then in SpiderMonkey I get

  @/Users/bzbarsky/test.js:2:5

and in V8 I get:

  SyntaxError: Unexpected end of input
    at /Users/bzbarsky/test.js:2:5

which are both showing the line/column of the eval() call itself, apparently.

Comment 3

[(no longer active)]

I think pinning the error to the location of eval() makes a lot of sense.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Note that there was the similar bug 332176 which handled exceptions thrown by the script.  Did syntax errors just get missed?

Comment 5

[Kannan Vijayan [:djvj]]

Well, when we throw syntax errors the script hasn't gotten constructed yet, so we definitely haven't generated the "fixed up filename" for the script at that point.  This only happens when the script gets introduced.

If we wanted to fix this we'd have to just manually handle the name construction at the syntax error throw site.