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

Fix location for optional params in arrow functions #9998

Merged
merged 5 commits into from May 21, 2019
Merged

Fix location for optional params in arrow functions #9998

merged 5 commits into from May 21, 2019

Conversation

danez
Copy link
Member

@danez danez commented May 19, 2019

Q                       A
Fixed Issues? Fixes #9957
Patch: Bug Fix? 👍
Major: Breaking Change? n
Minor: New Feature? n
Tests Added + Pass? 👍
Documentation PR Link
Any Dependency Changes?
License MIT

This ensures we only add +1 to the location when there is an optional parameter. In TS we currently were calling this.finishNode() even if no question mark was present, which caused comments being processed twice and as a result comments were disappearing. Not sure why though, I didn't want to dive into the comments attachment algorithm.

It also made certain expressions locations wrong.

((-10)) as const;

The numeric literal would include one of the closing parenthesis in its location.

I also made sure that the flow plugin does the same (include the question mark) as the typescript plugin.

@danez danez added PR: Bug Fix 🐛 A type of pull request used for our changelog categories area: flow pkg: parser area: typescript labels May 19, 2019
@babel-bot
Copy link
Collaborator

babel-bot commented May 19, 2019

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/10825/

@danez danez changed the title Fix location with optional params in arrow functions Fix location for optional params in arrow functions May 19, 2019
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo left a comment

Choose a reason for hiding this comment

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

We could throw in finishNode if it is already finished (maybe only when running out tests).

@danez
Copy link
Member Author

danez commented May 20, 2019

I have no idea why the preset-env tests suddenly fail. It works find here. Do we have any dependencies that are not locked?

Oh yeah of course any dependency in the packages themself. Seems the core-js (3.1.0) release broke our tests

/cc @zloirock

@zloirock
Copy link
Member

zloirock commented May 20, 2019

@danez core-js@3.1 contains some new modules, so need to rebuild preset-env fixtures.

@zloirock
Copy link
Member

Also, seems the replacing of esnext.string.match-all (and living it as a stub only) to es.string.match-all in some entry points broke core-js-compat/entries autogeneration. Need to fix it in core-js@3.1.1.

zloirock added a commit to zloirock/core-js that referenced this pull request May 20, 2019
…eration of `core-js-compat/entries` and backward `preset-env` compatibility

babel/babel#9998 (comment)
@nicolo-ribaudo nicolo-ribaudo merged commit 54d257c into babel:master May 21, 2019
@danez danez deleted the fix-optional-location branch May 21, 2019 16:56
@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: flow area: typescript outdated A closed issue/PR that is archived due to age. Recommended to make a new issue pkg: parser PR: Bug Fix 🐛 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

leadingComments drops last line comment before expression
5 participants