-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Added error for numeric literals larger than 2^53 - 1 #33202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added error for numeric literals larger than 2^53 - 1 #33202
Conversation
|
Better way would be using Also looks like there are no tests for error messages related to "negative numbers". Are they needed here? |
|
@AnyhowStep as I said - not available in IE11 (both UPD. Edited this message to propose inline constant, but AnyhowStep clarified this approach first. |
|
Just copy-paste those constants into the TS source code. It's one or two lines at most and gets rid of the "unsafe" pow(2, 53) Not a big deal |
|
@typescript-bot test this |
|
Heya @DanielRosenwasser, I've started to run the parallelized community code test suite on this PR at 281e7a4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at 281e7a4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 281e7a4. You can monitor the build here. It should now contribute to this PR's status checks. |
| if (diagnosticMessage) { | ||
| const withMinus = isPrefixUnaryExpression(node.parent) && node.parent.operator === SyntaxKind.MinusToken; | ||
| const literal = (withMinus ? "-" : "") + "0o" + node.text; | ||
| return grammarErrorOnNode(withMinus ? node.parent : node, diagnosticMessage, literal); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is feeding in a userless literal parameter`. It's not a problem per se, but it is very weird to do.
| // We can quickly bail out in two common cases: | ||
| // * Literals with 15 or fewer characters, as they aren't long enough to reach 2^53 - 1 | ||
| // * Fractional numbers (e.g. 9000000000000000000000000000.000000001) are inherently imprecise anyway | ||
| if (text.length <= 15 || text.indexOf(".") !== -1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't check for other things like scientific notation (1000000000000000000000000000e1), but you can't do a simple indexOf on e because you don't want to allow 0xbeef.
| "category": "Error", | ||
| "code": 1356 | ||
| }, | ||
| "Numeric literals with absolute values equal to 2^53 or greater are too large to be represented accurately as an integer.": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as integers
|
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running |
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
| return false; | ||
| } | ||
|
|
||
| return Number(text) >= Math.pow(2, 53) - 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, per the user baselines, should allow 9007199254740991 as 2**53. Will update...
| return Number(text) >= Math.pow(2, 53) - 1; | |
| return Number(text) >= 2 ** 53; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IE does not have the exponentiation operator, according to mdn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it gets downleveled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. I forgot TS down levels syntax, but not methods.
|
Turns out this breaks more than we thought. For example, it breaks the Azure SDK with the integer The thing that's interesting is that while almost any operation on that number is lossy, I believe that the numeric literal hasn't lost any precision. That's because the mantissa |
|
I guess you can shave off the trailing |
|
In that case I'll close this PR and add a quickfix to add an |
|
The TypeScript team hasn't accepted the linked issue #29863. If you can get it accepted, this PR will have a better chance of being reviewed. |
Fixes #29863
Is there a better check for a numeric literal being too large than
Number(text) >= Math.pow(2, 53) - 1? This performance difference should be negligible given that only literals of length16or more will go throughNumber.