Bugzilla – Full Text Bug Listing
| Summary: | The ILLEGAL token sounds bad | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> | ||||||
| Component: | JS Tools | Assignee: | Michael Rennie <Michael_Rennie> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | curtis.windatt.public, mamacdon | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 5.0 M2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 426406 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Created attachment 239242 [details]
screen shot
It is indeed a parser error. The problem with computing what the bad token (etc) is referring to is that a parser error only gives you a start offset, column number (offset from the start of the line) and a line number and the editor context does not have a way to ask for the start of the line offset. Created attachment 239360 [details]
proposed fix
The patch adds hooks for unexpected tokens and the unexpected end of file. It changes the error messages to be:
Syntax error on token '<tokenname>', delete this token
and
Sytax error, incomplete statement
respectively
I like the end result but it's unfortunate that the validator has to request the buffer again from the editorContext. We do have access to the tokens list from the parse tree. Would it be sufficient to find the token nearest to error.index, then use that that token's start & end offsets as the problem range in these cases? That would remove the need for the buffer... (In reply to Mark Macdonald from comment #4) > We do have access to the tokens list from the parse tree. Would it be > sufficient to find the token nearest to error.index, then use that that > token's start & end offsets as the problem range in these cases? That would > remove the need for the buffer... That would make the most sense. Pushed fix + tests to: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=347ce7444c7bef4a93fd7b29c89731956eed76ff This fix uses the token stream to find ranges and gets rid of all the extra deferreds except for the getAST call (which we absolutely need) |
Consider the following snippet: /*jslint browser:true */ function x(a) {\n f After eslint runs you get an error as shown in the screen shot. It turns out ILLEGAL refers to the '\'. Could we not mention that in the error and have said bad token be the range for the error? I haven't debugged it yet, but perhaps thats actually a parser error and not an eslint error.