Repository navigation
[4.7-beta] Parsing failure for arrow function expr in conditional expr #48733
Description
Activity
This is a crash
I can't reproduce this. Neither locally nor in the playground it crashes.
I can't reproduce this. Neither locally nor in the playground it crashes.
Sorry I forgot remove this from template.
Reacted by Martin JohnsThe OP's statement is accurate as the playground proves that there are no parsing errors in the version he mentions. However, if it helps resolve the problem, changing his code as follows resolves the error in the current version, leaving you with just the any type inference for param.
(false ? ((param): string => param) : null);
I'd like Jake Bailey (@jakebailey) to confirm but this seems like it might be intentional. Your code might terminate at the legal JS expression
false ? (param) : string
so parsing the
: stringas a type annotation might require "too much" lookahead.No doubt this is #16241 / #47550, yes. The reason why the workaround in typescript-eslint/typescript-eslint#4829 works is because the parser can see the
:inside of the parens and says "that's definitely a parameter", and allows the colon before the return type.When the (what I can only describe as) heuristics don't "prove" that it's an arrow function, my change disallows the
:when parsing, preferring it to end the conditional.The test case in the issue is similar to one I wrote in my PR, but then throws an extra case on the end.
I'd have to think about how I might fix this; the "heuristic" I described previously mainly checks things to do with parameters. It doesn't go and parse all the way past an error expression.
The gotcha with lookahead is when conditionals are nested, though I can't seem to produce an example that actually parses in JS. I thought the following would be a counter example, but this fails to parse when I run it in node.
true ? false ? (a) : b => c : null : null(If anyone can come up with an example, let me know. This is tricky.)
Regardless, I think all of this is going to have to be figured out for the types-in-JS proposal, since all of these parsing choices will have to be made and our parser changed to fix any differences.
FYI here is a case of how this bug caused problems in a real product https://github.com/typescript-eslint/typescript-eslint/pull/4829/files#diff-d9d4dc5af184a093e1caab204aa0ed6da56d008309ff90294561a64bec2e6663
SUZUKI Sosuke (@sosukesuzuki) Can you try taking a peek using the build on my PR here? #48788 (comment)
To link it here, here are various variations of "fixes" to this:
- Permissive (Allow return type in conditional if body is followed by a colon #48788): Playground Link
- Strict (Demo: make colon always terminate in conditional expression #48791): Playground Link
- Strict only on the left (Demo: make colon always terminate in conditional expression on true side #48792): Playground Link
Bug Report
🔎 Search Terms
conditional4.7 betasyntax error🕗 Version & Regression Information
This is a crash⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
Parsing failure for arrow function expr that has type annotations for return type, but doesn't have type annotations for parameters, in conditional expression.
🙂 Expected behavior
Parsing successfull.