Skip to content
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

Closed
wants to merge 20 commits into from

Conversation

saravanak
Copy link
Contributor

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

  • Updating the guides (This is internal, so imho, we don't need to update the documentation)

kategengler and others added 20 commits September 19, 2019 22:57
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)
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)
The correct command is `ember feature:enable` 😭 😩

(cherry picked from commit 8c9a71b)
(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)
(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").
@saravanak saravanak changed the title [Bug Fix: 15635] [Bug Fix: 15635] Fix Displaying of number literals bigger than 9 digits Oct 12, 2019

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) {
Copy link

@Mooninaut Mooninaut Oct 15, 2019

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.

Copy link
Member

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

Copy link
Member

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.

Copy link
Contributor

@lifeart lifeart Nov 11, 2019

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'

@chancancode chancancode changed the base branch from beta to master November 7, 2019 22:22
@chancancode chancancode changed the base branch from master to release November 7, 2019 22:22
import { Arguments, VM } from '@glimmer/runtime';
import { InternalHelperReference } from '../utils/references';

function parseIntHelper({ positional }: any) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return parseInt(value);
return parseInt(value, 10);

this.assertTextNode(this.firstChild, '123456789');
}
}
);
Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}}`);
Copy link
Member

@chancancode chancancode Nov 7, 2019

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?

Copy link
Member

@chancancode chancancode left a 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

@saravanak
Copy link
Contributor Author

saravanak commented Nov 12, 2019

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
(No display, console error) : Uncaught TypeError: reference$$1.value is not a function

Ember 3.1.4 and newer

160826069 12345678933
1234567893232323.2 1234567893323232300
-1234567893232323.2 -1234567893323232300
-160826069 -12345678933

There is also an error in the 3.1.4 results: 1234567893 is displayed as 160826069. I think this should be treated as a glimmer-vm bug and tracked separately.

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..

@chancancode
Copy link
Member

chancancode commented Dec 16, 2019

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);
};

chancancode added a commit that referenced this pull request Feb 8, 2020
chancancode added a commit that referenced this pull request Feb 8, 2020
chancancode added a commit that referenced this pull request Feb 8, 2020
chancancode added a commit that referenced this pull request Feb 11, 2020
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 11, 2020
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>
chancancode added a commit that referenced this pull request Feb 12, 2020
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>
(cherry picked from commit 69fc6dd)
chancancode added a commit that referenced this pull request Feb 12, 2020
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>
(cherry picked from commit 69fc6dd)
chancancode added a commit that referenced this pull request Feb 12, 2020
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>
(cherry picked from commit 69fc6dd)
chancancode added a commit that referenced this pull request Feb 12, 2020
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>
(cherry picked from commit 69fc6dd)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants