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: Curly rule incorrectly flagging lexical declarations (fixes #11663) #11675

Merged
merged 2 commits into from May 11, 2019

Conversation

Projects
None yet
4 participants
@BRKurek
Copy link
Contributor

commented May 4, 2019

What is the purpose of this pull request? (put an "X" next to item)

[x] Bug fix (template)

What changes did you make? (Give an overview)
Added a lexical declaration check to the multi-or-nest curly rule to prevent single line lexical declarations from being flagged as errors. See #11663

Is there anything you'd like reviewers to focus on?
Nothing specific

@eslint eslint bot added the triage label May 4, 2019

@platinumazure

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Thanks for the PR!

What should happen to var declarations? Are they allowed inside control statement bodies as single statements?

@platinumazure platinumazure added accepted bug rule and removed triage labels May 5, 2019

@BRKurek

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

I think we should keep handling var declarations the way we do now -- if they are inside a control statement body as a single statement the brackets should not be there when using curly with multi-or-nest. The reason we're adjusting the logic for const, let, function, and class is that they need to exist inside a block, so removing the brackets causes a parsing error.

@platinumazure

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Wow, I didn't realize var was valid syntax there. I had assumed it would also be invalid syntax. But I've just tested it in espree and it is indeed valid.

In that case, I agree with your proposed direction.

@platinumazure
Copy link
Member

left a comment

This looks good so far.

Do we have an existing test showing that the var case is invalid (has a lint error), and fixed to a single-statement block-less form? If not, it would be good to add one.

@BRKurek

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2019

There was not an existing test for that case, added.

@platinumazure
Copy link
Member

left a comment

LGTM, thanks! (And thank you for adding the test case!)

@BRKurek

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2019

No problem!

@ilyavolodin ilyavolodin merged commit 1a3a88d into eslint:master May 11, 2019

5 checks passed

commit-message PR title follows commit message guidelines
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
licence/cla Contributor License Agreement is signed.
Details
release-monitor No patch release is pending
Details

@BRKurek BRKurek deleted the BRKurek:issue11663 branch May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.