Disallow octal literals in strict mode and ES5 #385
Conversation
|
👍 |
|
I will add tests for those cases, but they do seem to behave correctly. -03 does fail. The parser does not need to check negatives because the minus sign is part of the parent node (prefix unary expression). Same for +03 and ++03. 009 has two errors, which matches the behavior of the old compiler. The scanner yields 00 and 9 as 2 separate numbers, so even though the regex would match 009, it will never see a number with this spelling. Maybe I should add a comment to that effect. The only deviation from the ecmascript spec is that 09 succeeds, whereas the spec considers it malformed. I did this to align with the old compiler's behavior. |
| // we would get 00 and 9 as two separate tokens. | ||
| // We also do not need to check for negatives because any prefix operator would be part of a | ||
| // parent unary expression. | ||
| if (/0[0-7]+/.test(numberLiteralSource)) { |
There was a problem hiding this comment.
I would just test the first and second char in the source instead of a regex
There was a problem hiding this comment.
Additionally, I'd simply do this check first and do the ES5/strict mode checking in the body, since you're less likely to be writing octal literals and that'll short-circuit the check.
There was a problem hiding this comment.
V8 allows 009 in strict mode, and treats it as 9.
Perhaps TS should either follow the same behaviour, or generate a warning.
|
👍 |
|
V8 considers 009 a valid literal for number 9 (both strict and non-strict). I wonder whether TS should follow, or at least give a warning if it deviates. After all TS itself runs in node half the time. |
|
That is true, but we'd like to align as best we can with the ecmaScript 5 spec, and with the TypeScript 1.0 compiler. That is the rationale for these rules. Rejecting 009 is consistent with both the spec and the old compiler, so it would not break any existing code. |
Disallow octal literals in strict mode and ES5
This change alters the way we parse octal literals to match the behavior of the old compiler. We also error now on octal literals in strict mode and -t es5.
There is one breaking change from the old compiler. Namely, in strict mode in ES3 (which doesn't exist in javascript anyway), we will error on octal literals, whereas the old compiler did not.
Next work item is octal escape sequences, which the old compiler did not detect.