Skip to content
This repository has been archived by the owner on May 19, 2018. It is now read-only.

NumberLiteralSeparator: Stage 1 feature plugin. Closes gh-538 #541

Merged
merged 4 commits into from
May 26, 2017

Conversation

rwaldron
Copy link
Contributor

@rwaldron rwaldron commented May 26, 2017

Signed-off-by: Rick Waldron waldron.rick@gmail.com

Q A
Bug fix? no
Breaking change? no
New feature? yes
Deprecations? no
Spec compliancy? yes
Tests added/pass? yes
Fixed tickets #538
License MIT

I modified readInt to ignore _ characters found in decimal, hex, binary and octal literals. It will also throw SyntaxError exceptions when the _ is misused.

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
@hzoo
Copy link
Member

hzoo commented May 26, 2017

Amazing, that was super quick!

A few things to note:

  • We need this to be under a flag like the other plugins. This just means creating a hasPlugin('numericSeparators) check so that this functionality isn't turned on by default.
  • Update the readme to add that numericSeparators line to the plugins list
  • Update the ast/spec.md (maybe no update needed)

@hzoo hzoo added the spec-new label May 26, 2017
@rwaldron
Copy link
Contributor Author

@hzoo thanks for the quick review turnaround, I will get these issues addressed and ping you when ready :)

@hzoo
Copy link
Member

hzoo commented May 26, 2017

Yeah, I should probably add that information to the contributing, let us know if there's anything that can be clarified or is frustrating

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
@codecov
Copy link

codecov bot commented May 26, 2017

Codecov Report

Merging #541 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #541      +/-   ##
==========================================
+ Coverage   98.13%   98.13%   +<.01%     
==========================================
  Files          22       22              
  Lines        3588     3599      +11     
  Branches     1002     1007       +5     
==========================================
+ Hits         3521     3532      +11     
  Misses         24       24              
  Partials       43       43
Flag Coverage Δ
#babel 80.41% <16.66%> (-0.22%) ⬇️
#babylon 96.8% <100%> (ø) ⬆️
Impacted Files Coverage Δ
src/tokenizer/index.js 98.4% <100%> (+0.03%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6eeb031...465d80b. Read the comment docs.

@rwaldron
Copy link
Contributor Author

  • We need this to be under a flag like the other plugins. This just means creating a hasPlugin('numericSeparators) check so that this functionality isn't turned on by default.
  • Update the readme to add that numericSeparators line to the plugins list
  • [] Update the ast/spec.md (maybe no update needed)

@hzoo changes pushed. I didn't make changes to ast/spec.md because I don't believe there are any changes to make there (I could be wrong, but need guidance)

…alSeparatorSiblings

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
if (forbiddenNumericLiteralSeparatorSiblings.includes(prev) ||
forbiddenNumericLiteralSeparatorSiblings.includes(next) ||
Number.isNaN(next)) {
this.raise(this.state.pos, "Invalid NumericLiteralSeparator");
Copy link
Member

@hzoo hzoo May 26, 2017

Choose a reason for hiding this comment

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

I might actually create a different error message for multi _, if it's at the end or the beginning, or around invalid chars but we can totally do that later too.

Could be a good 2nd PR

const prev = this.input.charCodeAt(this.state.pos - 1);
const next = this.input.charCodeAt(this.state.pos + 1);
if (code === 95) {
if (forbiddenNumericLiteralSeparatorSiblings.includes(prev) ||
Copy link
Member

@DrewML DrewML May 26, 2017

Choose a reason for hiding this comment

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

Thanks for the PR, @rwaldron! I believe we need to switch to Array#indexOf here instead of Array#includes. We don't load any polyfills in Babylon, and the minimum supported node version is 4.0.0.

Copy link
Member

Choose a reason for hiding this comment

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

Dang forgot about that 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, ok, no problem. I saw all the other modern JS and just assumed I could use it...whoops! Will fix now.

Copy link
Member

@hzoo hzoo left a comment

Choose a reason for hiding this comment

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

Looks good to me! 👍 Amazing work for the first PR

Ideally the cases that have a weird error message should be fixed to have the same error message as the others

✔ ._1_1 is Unexpected token (1:0) (module)
✔ ._1_1 is Unexpected token (1:0) (script)
✔ 0o01_8 is Unexpected token, expected ; (1:5) (module)
✔ 0o01_8 is Unexpected token, expected ; (1:5) (script)
✔ 0b2_1 is Expected number in radix 2 (1:2) (module)
✔ 0b2_1 is Expected number in radix 2 (1:2) (script)
✔ 0xZ_1 is Expected number in radix 16 (1:2) (module)
✔ 0xZ_1 is Expected number in radix 16 (1:2) (script)

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
@rwaldron
Copy link
Contributor Author

@DrewML pushed change for includes -> indexOf

Copy link
Member

@existentialism existentialism left a comment

Choose a reason for hiding this comment

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

👍

@rwaldron
Copy link
Contributor Author

Ideally the cases that have a weird error message should be fixed to have the same error message as the others

I believe most those stay as they are because they have a different violation in them before the illegal _, or are already illegal and I wanted to ensure that the new code didn't erroneously consider them a new kind of restriction.

._ is illegal today for

I think this:

0o01_8 is Unexpected token, expected ; (1:5) (module)

...is an outlier that should be fixed, but I'm not sure how. The _ is legal here, the 8 is not—it should have an error that says Expected number in radix 8. Seems like an unrelated issue for another ticket.

And this:

._1_1 is Unexpected token (1:0) (module)

... involves changing readToken_dot to raise an exception, which I could do here or in a follow up PR. A follow up might be nicer to keep the error message fixes together.

@hzoo
Copy link
Member

hzoo commented May 26, 2017

Yeah I think this is good for this PR

@hzoo hzoo merged commit b344f62 into babel:master May 26, 2017
@hzoo
Copy link
Member

hzoo commented May 26, 2017

Let's do this 😄

@jridgewell
Copy link
Member

Does _123 pass?

@diervo
Copy link
Contributor

diervo commented May 26, 2017

It shouldn't the separator is only allowed in between numeric values.

@hzoo
Copy link
Member

hzoo commented May 27, 2017

Well _123 starts with _ so it should just be parsed as an Identifier right?

@rwaldron
Copy link
Contributor Author

@jridgewell @hzoo @diervo correct, _123 is not valid DecimalDigits, because _ is a valid IdentifierStart character. I'm sure it's fine, but I will open a PR that adds a test which asserts that this remains true when the numericSeparator plugin is active.

@michaelficarra
Copy link

@rwaldron I believe there's a bug in that this allows legacy octal integer literals to have separators. Even if this does restrict them, I don't see a test for that. Do you mind sending a PR to correct that?

@michaelficarra
Copy link

Ping @rwaldron.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants