Spurious syntax error for certain switch-case-if scenario

[lucaswerkmeister]

TypeScript Version:

master (a535460), built from source. Also occurs on current Playground.

Code

switch (1) {
case (a): {
    if (c) {}
}
}

Expected behavior:

Error about the unknown names a and c. Compiles to exactly the same JS, since the code is already plain JavaScript.

Actual behavior:

Syntax errors.

tmp.ts(3,12): error TS1005: ';' expected.
tmp.ts(4,1): error TS1005: ':' expected.
tmp.ts(5,1): error TS1128: Declaration or statement expected.

On Playground, you get some more errors (looks like CLI aborts at the syntax errors while Playground continues with type checking).

Type '(a: any) => { if(c: any): any; }' is not assignable to type 'number'.

A function whose declared type is neither 'void' nor 'any' must return a value.

Also, a is documented as “parameter”. So apparently the parser thinks this is a function expression, not a case clause and following block.

This is fairly fragile. Many changes to the code will result in the error vanishing, including:

• Changing a to 1
• Changing c to 1
• Removing the parentheses around a
• Adding an extra pair of parentheses around a
• Removing the curly braces of the case block
• Replacing the empty if block with the empty statement ;
• Replacing the empty if block with the nonempty statement console.log("foo");
• Completely removing the if statement

[DanielRosenwasser]

What's happening here is that you have what appears to be the beginning of an arrow function with a type annotation. (x):. Unfortunately, that block body looks like the beginning of a type literal, so we erroneously parse that out as a type, assuming that you just have syntactic errors in your block (see #2496 for a similar issue).

Unfortunately this ends up breaking valid code. Any ideas Vladimir Matveev (@vladima) or Cyrus Najmabadi (@CyrusNajmabadi)?

[CyrusNajmabadi]

Any ideas ... ?

Here's what the EcmaScript grammar has to say about this production:

case Expression[In, ?Yield] : StatementList[?Yield, ?Return]opt

So technically, you could have a case <arrow function>: (though it would be pretty nonsensical). I can think of a few ways to do things:

1. Do speculative lookahead to decide what sort of expressoin this is, and parse the code appropriately. Pros: correct. Cons: slower.
2. Tighten up the existing speculative lookahead for arrow functions to not match here since there is no =>. Pros: improves this situation. Cons: may miss some other. Also, the lookahead on arrow functions is already pretty complex.
3. Don't allow parsing arrow functions here. Pros: nice and simple and pretty much always what you want. Cons: not matching emascript spec anymore.
4. Don't do anything. There are simple workarounds (for example, removing the parens in the expression).

I'm not sure what i'd go with. The ambiguity between type literals and blocks makes speculation and proper determination hard in TS. So both '1' and '2' are hard. I might just go with '3' or '4' myself.

[CyrusNajmabadi]

Daniel Rosenwasser (@DanielRosenwasser) Didn't you have to deal with the object-literal/object-tyep ambiguity before? Did you write any sort of helper to help out here?

[vladima]

there are other cases when we prefer parse-and-recover case for arrow function to legal scenarios.
Now this is an error:

(a / b
)
{

}

but this is not:

(a / b)
{

}

[CyrusNajmabadi]

hrmm: Why is:

(a / b
)
{

}

An error? I'm not quite sure i got the reasoning there. Thanks!

[vladima]

first we try to parse expression as parenthesized arrow function:

• ( - ok, proceed with parameter list
• parse parameter name, got a - ok
• try parse type annotation, current token is not : - do nothing
• try parse initializer, current token is not =, assume that user missed this token, show error that = is expected and continue
• parse expression in initializer - current token is / - rest of the line is parsed as unterminated regex literal
• current token is ) - done with a parameter list
• current token is { - assume that used has missed => and continue.

As a result we have parsed

(a / b
)

as a beginning of parenthesized arrow function

[RyanCavanaugh]

Similar to weird constructions that can end up looking like type arguments, this is an edge case deviation from JS semantics that I think we just have to bite the bullet on. This program

let string = 0, a = 1;
switch (1) {
  case (a): string => null;
}

In JS parses as

let string = 0, a = 1;
switch (1) {
  case a:
    string => null;
}

but TypeScript sees it as

let string = 0, a = 1;
switch (1) {
  case ((a): string => null)
}

and expects a :. Without an impractically large amount of lookahead I don't think this is something we can fix.