Refactor bindingProperty parsing #13929
Conversation
JLHwung
added
PR: Spec Compliance 👓
| @@ -0,0 +1 @@ | |||
| var { @foo foo } = foo; | |||
There was a problem hiding this comment.
The current main incorrectly allows decorators in pattern. This is now fixed, by not handling decorators at all in parseBindingProperty.
| class A { | ||
| +#foo; | ||
| -#foo; | ||
| } |
There was a problem hiding this comment.
The current main incorrectly parses +#foo as ClassProperty instead of ClassPrivateProperty. This is now fixed by a new parsePropertyNamePrefixOperator hook for the Flow plugin.
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/49687/ |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 2efdbf8:
|
| @@ -1,3 +1,3 @@ | |||
| class C { | |||
| #p = ({ #x: 42 }); | |||
There was a problem hiding this comment.
This file is renamed to invalid-object-property/input.js.
Co-authored-by: Nicolò Ribaudo <nicolo.ribaudo@gmail.com>
JLHwung
force-pushed
the
split-parse-property-definition
branch
from
fafff94
to
647ecd4
Compare
They are always non-ambiguous.
JLHwung
force-pushed
the
split-parse-property-definition
branch
from
a28cfbc
to
2efdbf8
Compare
github-actions
bot
added
the
outdated
The PR is extracted from my local working branch on destructuring private parsing.
parseMaybePrivateNameis inlined toparsePropertyNameparseBindingPropertyis extracted fromparsePropertyDefinitionparseClassElementName, since we already checkedprivateNameto throw private constructor error. TheparsePropertyNamenow always throws private name in object. In the future it will handle the ambiguous({ #x: x }).Two bugs are fixed during refactoring.