()
| 35609 | return result; |
| 35610 | } |
| 35611 | function parseTypeArgumentsInExpression() { |
| 35612 | if ((contextFlags & 262144 /* NodeFlags.JavaScriptFile */) !== 0) { |
| 35613 | // TypeArguments must not be parsed in JavaScript files to avoid ambiguity with binary operators. |
| 35614 | return undefined; |
| 35615 | } |
| 35616 | if (reScanLessThanToken() !== 29 /* SyntaxKind.LessThanToken */) { |
| 35617 | return undefined; |
| 35618 | } |
| 35619 | nextToken(); |
| 35620 | var typeArguments = parseDelimitedList(20 /* ParsingContext.TypeArguments */, parseType); |
| 35621 | if (reScanGreaterToken() !== 31 /* SyntaxKind.GreaterThanToken */) { |
| 35622 | // If it doesn't have the closing `>` then it's definitely not an type argument list. |
| 35623 | return undefined; |
| 35624 | } |
| 35625 | nextToken(); |
| 35626 | // We successfully parsed a type argument list. The next token determines whether we want to |
| 35627 | // treat it as such. If the type argument list is followed by `(` or a template literal, as in |
| 35628 | // `f<number>(42)`, we favor the type argument interpretation even though JavaScript would view |
| 35629 | // it as a relational expression. |
| 35630 | return typeArguments && canFollowTypeArgumentsInExpression() ? typeArguments : undefined; |
| 35631 | } |
| 35632 | function canFollowTypeArgumentsInExpression() { |
| 35633 | switch (token()) { |
| 35634 | // These tokens can follow a type argument list in a call expression. |
nothing calls this directly
no test coverage detected
searching dependent graphs…