Named Tuple elements should allow reserved words as their names

Bug Report

🔎 Search Terms

tuple elements label reserved word
named tuple elements

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "Common "Bugs" That Aren't Bugs"

⏯ Playground Link

Playground link with relevant code

💻 Code

type x = [if: any]
// but some keywords are allowed, e.g.
type y = [void: any]

🙁 Actual behavior

Unused label.
'any' only refers to a type, but is being used as a value here.
Type expected.
'(' expected.
Unexpected keyword or identifier.
Declaration or statement expected.

🙂 Expected behavior

No errors. As a label it should allow any identifiers, including reserved words.

👩‍💻 Possible solution

Although parseTupleElementNameOrTupleElementType allows any identifier as its name:

https://github.com/microsoft/TypeScript/blob/0af2497fecef9e41d7d0260fd37932dd33912c66/src/compiler/parser.ts#L3559

before it is invoked, the isListElement requires a tuple member start a type:

https://github.com/microsoft/TypeScript/blob/0af2497fecef9e41d7d0260fd37932dd33912c66/src/compiler/parser.ts#L2091

This is no longer true after we support named tuple member after 4.0, which should start with any valid identifiers / keywords. Because isListElement returns false, the parser does not parse them as tuple elements, which results to confusing parsing errors.

We can create a new ParsingContext for named tuple members, and returns token() === SyntaxKind.CommaToken || tokenIsIdentifierOrKeyword(token()) in isListElement.

Beginne in src/compiler/parser.ts bei isListElement und parseTupleElementNameOrTupleElementType und verwende den verlinkten Playground-Code als Reproduktion. Verfolge, wie benannte Tupelmitglieder, die mit einem reservierten Wort beginnen, klassifiziert werden, füge dann einen Regressionstest hinzu, der das Beispiel abdeckt, und verifiziere, dass er keine Parsing-Fehler erzeugt.