Fix: check if param is assignable when parsing arrow return type annotation #11992
Conversation
| @@ -0,0 +1 @@ | |||
| 0 ? v => (v) : v => 0; | |||
There was a problem hiding this comment.
Although it is a valid javascript, tsc will throw on this production: microsoft/TypeScript#16241 Here we align to the tsc behaviour.
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/27755/ |
|
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 51e71b4:
|
| return false; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Massive use of property access is very expensive. And I guess the validation happens a lot during the parsing. Why not use a mutual parser flag in case any flags need passed by reference and use them to track is assignable?
for (a.b of []); should be parsed / transformed as an assignment pattern, not as an binding pattern as mentioned here. It's only a binding pattern if you use 'let', 'const' or 'var. But I think the Babel AST does not distinguish between a pattern and an assignment?
This case for (a.b of [] = x); illustrate it should be an assignment not an binding pattern. This case for (let a of [] = b); the LHS should be parsed as an binding pattern and the RHS should be parsed as an assignment pattern.
There was a problem hiding this comment.
for (a.b of []); should be parsed / transformed as an assignment pattern, not as an binding pattern as mentioned here.
Yeah, in the comment I wrote a.b is not a binding pattern.
Massive use of property access is very expensive.
Indeed, I plan to revisit later.
This PR applies extra
isAssignablecheck when we decide that a: TSTypeshould be parsed as a return type for arrow function.This PR also moves
isAssignablefromflowplugin tolval. And then simplifies the interface since we do not useisAssignable(#, false)in the codebase.