-
Notifications
You must be signed in to change notification settings - Fork 660
Rename Pattern to Bindings and share parsing logic with Assignment Target #1839
Conversation
Test262 comparison coverage results on ubuntu-latest
|
Test262 comparison coverage results on windows-latest
Fixed tests (16):
|
f2dba6c
to
914f0c2
Compare
Deploying with Cloudflare Pages
|
|
||
let mut opt = None; | ||
|
||
if p.at(T![?]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the TypeScript handling for now. The recovery logic here is incorrect and we need to re-think the logic now that assign pattern is no longer a thing
@@ -898,42 +913,42 @@ pub fn primary_expr(p: &mut Parser) -> Option<CompletedMarker> { | |||
} else { | |||
// `async a => {}` and `async (a) => {}` | |||
if p.state.potential_arrow_start | |||
&& token_set![T![ident], T![yield], T!['(']].contains(p.nth(1)) | |||
&& token_set![T![ident], T![yield], T![await], T!['(']].contains(p.nth(1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes an issue where async await => {}
isn't recognized as a arrow function
{ | ||
let mut guard = p.with_state(ParserState { | ||
let in_async_p = &mut *p.with_state(ParserState { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the parameters must be parsed with async set to true to detect if e.g. await
is a valid or invalid identifier.
@@ -156,14 +156,6 @@ fn parse_object_member(p: &mut Parser) -> ParsedSyntax { | |||
parse_method_object_member_body(p); | |||
Present(m.complete(p, JS_METHOD_OBJECT_MEMBER)) | |||
} else if let Some(mut member_name) = member_name { | |||
// test object_expr_assign_prop | |||
// let b = { foo = 4, foo = bar } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't valid JS nor TS syntax...???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not a valid syntax
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a lot of code and it will take time for me to review. For now I leave some feedback and question:
- we should add new tests to the formatter for array binding. It seems we don't have them, other than
simple.js
; - why did you use traits in this case? what's the endgame? The documentation doesn't explain that part and I can see you implemented the traits just once, which means that it could have been a
struct
or anenum
;
@@ -156,14 +156,6 @@ fn parse_object_member(p: &mut Parser) -> ParsedSyntax { | |||
parse_method_object_member_body(p); | |||
Present(m.complete(p, JS_METHOD_OBJECT_MEMBER)) | |||
} else if let Some(mut member_name) = member_name { | |||
// test object_expr_assign_prop | |||
// let b = { foo = 4, foo = bar } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not a valid syntax
Thanks for taking the time!
I'm not sure if that code is final. I just moved the files from the
The traits are implemented twice: Once for |
969b05d
to
fb9f941
Compare
// let let = 5; | ||
// const let = 5; | ||
// let a, a; | ||
pub(crate) fn parse_identifier_binding(p: &mut Parser) -> ConditionalParsedSyntax { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should start documenting those methods that are ConditionalParsedSyntax
and explain why they return this type (and have it as a rule inside the CONTRIBUTING.md
file). To be more precise, we know that ConditionalParsedSyntax
can be used for different reasons (languages features, super language, browser version, etc.), although by looking at method, it's difficult to know. Having a documentation with some snippet might help?
We should explain what's the syntax that can differ.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that makes sense. I also need to revisit the ConditionalParsedSyntax
. The way it currently works (where Absent
values can be invalid too`) is super awkward to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also still figuring this out. So far I thought it's a good idea to make the or_invalid_to_unknown
conversion right inside of the parse function but it turned out that is dangerous.
For example, the class or function id, a single arrow function parameter or an object rest pattern don't support JsAnyBinding
and, therefore, returning a JsUnknownBinding
is invalid in these cases. So it seems, all we can do in these cases is to bubble up the error until we come to a place where we can handle it.
This is a bit annoying. An alternative would be to just add a diagnostic and keep the binding as is. This would certainly be easier but we then no longer have a strict rule when to use unknown:
- any syntax error (additional syntax) -> Content is inside of an
Unknown
node - missing syntax -> Empty slot, handled in the AST facade
We need to get some more experience how to handle and we may come back to this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I bumped into this too while refactoring class.rs
, where some function uses or_invalid_to_unknown
under to hood but it is "hidden" and we don't know what's happening
Update on I added one more check to disallow |
Sorry, it seems this escalated quite a bit. I wasn't aware, that patterns are used in so many different places in our codebase
Summary
#1805 separated assignment targets out from patterns. This PR now renames the "remaining" patterns to bindings. Bindings are different from assignment targets because they bind a new name in the current scope and assign a value to it rather than assigning a value to an existing name.
This PR further restructures Patterns as specified in #1719.
Pattern
toJsAnyBinding
AssignPattern
withJsBindingWithDefault
PatternOrExpr
SinglePattern
withJsIdentifierBinding
RestPattern
withJsArrayRestBinding
andJsObjectRestBinding
. Remove it from thePattern
union (only permitted inside of arrays/objects)ObjectPattern
toJsObjectBinding
KeyValuePattern
withJsShorthandPropertyBinding
andJsPropertyBinding
ArrayPattern
toJsArrayBinding
ExprPattern
SpreadElement
andJsSpread
InitializedProp
(not valid JS nor TS syntax???)This PR extracts the common logic for parsing
Patterns
fromassignment_target
as traits intopattern.rs
that I then used to parse bindings.Part of #1725
Test Plan
Verified coverage, added new test cases.
All libs are now parsing without panicking. Performance is roughly the same