This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | A small fix in JsLexer.getTokenId | ||
|---|---|---|---|
| Product: | javascript | Reporter: | emi <emi> |
| Component: | Editor | Assignee: | Petr Hejl <phejl> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | jkovalsky |
| Priority: | P4 | ||
| Version: | 7.0 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | Patch which fixes the issue | ||
For 7.3 we have completely different lexer and parser. |
Created attachment 107183 [details] Patch which fixes the issue There is a special case in getTokenId() that looks like this: case 65535: // SIGN ERRORS! Why does this happen? The way I see it the problem seems to be this line in nextToken(): token = tokenStream.getToken() & Parser.CLEAR_TI_MASK; where if tokenStream.getToken() returns org.mozilla.nb.javascript.Token.ERROR which is actually -1 (the only negative token id), in two-s complement it has all the bits on 1. So -1 & Parser.CLEAR_TI_MASK (which is 0xFFFF) gives unsurprisingly the 65535 value. PS: The good thing is that the 'case 65535' is treated as JsTokenId.ERROR anyhow, as it should.