-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[Bug Fix: 15635] Fix Displaying of number literals bigger than 9 digits #18484
Conversation
[ci skip]
This is currently broken on the Octane blueprint: ``` /home/travis/build/ember-learn/super-rentals-tutorial/dist/code/super-rentals/super-rentals/tests/integration/components/jumbo-test.js: Only `import { hbs } from 'ember-cli-htmlbars'` is supported. You used: `import hbs from 'ember-cli-htmlbars';` 2 | import { setupRenderingTest } from 'ember-qunit'; 3 | import { render } from '@ember/test-helpers'; > 4 | import hbs from 'ember-cli-htmlbars'; | ^ 5 | 6 | module('Integration | Component | jumbo', function(hooks) { 7 | setupRenderingTest(hooks); ``` (cherry picked from commit 20746cc)
(cherry picked from commit d45a258)
This ensures that users of the Octane preview have the required minimum features enabled. (cherry picked from commit 5742c53)
* `optionalFeaturesMissing` was flipped * `template-only-glimmer-component` -> `template-only-glimmer-components` * indentation was slightly off (cherry picked from commit b9442f0)
[ci skip]
[ci skip]
The correct command is `ember feature:enable` 😭 😩 (cherry picked from commit 8c9a71b)
[ci skip]
(cherry picked from commit 17838f0)
In some cases, observers may cause side effects while computing their tags (aliases, primarily) which attempt to reflush the same observer (cherry picked from commit 7d1e911)
[ci skip]
(cherry picked from commit c49d732)
[BUGFIX] Using query params helper outside of link-to (cherry picked from commit f786e42)
We transform the AST for big number literals into (-parse-int "1546416000000").
|
||
NumberLiteral(number: AST.NumberLiteral): AST.Node { | ||
//See https://github.com/emberjs/ember.js/issues/15635 for the choice for [9]. | ||
if(String(number.original).length > 9) { |
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.
Needs to use length > 8
The bug can occur with values >= 536870912
and < 1000000000
. For example, 678881280
is displayed as 142010368
.
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.
I think we should just parse the number with parseInt
and test the actual value, instead of the length of the string
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.
We need to check for floats as well, maybe just use parseFloat
here, check that it is an integer (parseFloat(...) % 1 === 0
?) and is out of bounds, both the upper and lower (negative) bounds.
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.
or new Number('1').valueOf()
or +'12'
import { Arguments, VM } from '@glimmer/runtime'; | ||
import { InternalHelperReference } from '../utils/references'; | ||
|
||
function parseIntHelper({ positional }: any) { |
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.
function parseIntHelper({ positional }: any) { | |
function parseIntHelper({ positional }: CapturedArguments) { |
You'll have to import CapturedArguments
from @glimmer/interfaces
|
||
function parseIntHelper({ positional }: any) { | ||
let value = positional.at(0).value(); | ||
return parseInt(value); |
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.
return parseInt(value); | |
return parseInt(value, 10); |
this.assertTextNode(this.firstChild, '123456789'); | ||
} | ||
} | ||
); |
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.
Instead of having a unit test for the helper, I would prefer that we have an acceptance/integration test for being able to render/pass big numbers.
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.
https://github.com/emberjs/ember.js/blob/master/packages/@ember/-internals/glimmer/tests/integration/content-test.js would probably be a good place for it
class extends TransformTestCase { | ||
['@test it transforms an big number to the parseInt form']() { | ||
this.assertTransformed(`{{foo-helper 1234567890}}`, `{{foo-helper (-parse-int "1234567890")}}`); | ||
this.assertTransformed(`{{foo-helper 123456789}}`, `{{foo-helper 123456789}}`); |
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.
Can you add a few more test for things like {{1234567890}}
, {{some-helper (another-helper 1234567890)}}
, <Foo @bar={{1234567890}} />
, {{some-helper foo=1234567890}}
, etc?
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.
Overall looks good to me, left some comments for things that need to be fixed before merging
@chancancode @lifeart @Mooninaut, Thanks for the comments... Given that it was an old bug, I should have checked the replication before attempting the PR; my bad. Here are the results though: From the twiddle shared by @rwjblue in the bug description, I had {{go-boom-for-big-numbers 1234567893}}
{{go-boom-for-big-numbers 12345678933}}
<div/>
{{go-boom-for-big-numbers 1234567893232323.2323}}
{{go-boom-for-big-numbers 1234567893323232323.2323}}
<div/>
{{go-boom-for-big-numbers -1234567893232323.2323}}
{{go-boom-for-big-numbers -1234567893323232323.2323}}
<div/>
{{go-boom-for-big-numbers -1234567893}}
{{go-boom-for-big-numbers -12345678933}} The following are the results: Ember 3.0.0 Ember 3.1.4 and newer
There is also an error in the 3.1.4 results: Looks like this is fixed 'upstream' in newer versions of glimmer-vm. I was not able to locate the actual diff that fixed this in the glimmer-vm code. This makes this PR obsolete, as the relevant fixes are done on the glimmer-vm code. I'd like a go-ahead and on continuation of this PR if its still needed.. |
Rather than a test for the transform, maybe we should just have a set of runtime tests like this: let i = Number.MAX_SAFE_INTEGER;
while (i >= 1) {
let number = i;
test(`it can handle ${number}`, function() {
this.registerHelper('is-equal-integer', function([actual, expected]) {
return typeof actual === 'number' && actual === expected;
});
this.render(`[{{${number}}}][{{this.number}}][{{is-equal-integer ${number} this.number}}]`, { number });
this.assertText(`[${number}][${number}][true]`);
});
i = Math.round(i / 2);
};
let j = Number.MIN_SAFE_INTEGER;
while (j <= -1) {
let number = j;
test(`it can handle ${number}`, function() {
this.registerHelper('is-equal-integer', function([actual, expected]) {
return typeof actual === 'number' && actual === expected;
});
this.render(`[{{${number}}}][{{this.number}}][{{is-equal-integer ${number} this.number}}]`, { number });
this.assertText(`[${number}][${number}][true]`);
});
j = Math.round(j / 2);
}; |
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Workaround for the Glimmer VM bug which encodes/decodes integer literals correctly. See #15635. Based on #18484 and #18484 (comment) Fixes #15635. Closes #18484. Co-authored-by: Saravana Kumar V <vsk62.gate@gmail.com>
Fixes #15635.
What:
As suggested here #15635 (comment),
we transform the AST for big number literals into (-parse-int "1546416000000").
I've used
String(number).length > 9
to identify cases where we need to do the transform.Added tests for the AST Transform, and the new internal
-parse-int
helper.@chancancode Can you have a look at this?
I am not sure if the target branch is right though...
Need some pointers on