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.

Inizia in src/compiler/parser.ts, su isListElement e parseTupleElementNameOrTupleElementType, usando il codice Playground collegato come riproduzione. Traccia il modo in cui vengono classificati i membri di tupla denominati che iniziano con una parola riservata, quindi aggiungi un test di regressione che copra l'esempio e verifica che non produca errori di parsing.