Don't parse duplicate JSDoc for ExpressionStatement starting with ParenthesizedExpression #36289
Conversation
|
@typescript-bot user test this |
| @@ -5391,7 +5391,7 @@ namespace ts { | |||
| // Avoiding having to do the lookahead for a labeled statement by just trying to parse | |||
| // out an expression, seeing if it is identifier and then seeing if it is followed by | |||
| // a colon. | |||
| const node = <ExpressionStatement | LabeledStatement>createNodeWithJSDoc(SyntaxKind.Unknown); | |||
| const node = <ExpressionStatement | LabeledStatement>createNodeWithJSDoc(token() === SyntaxKind.Identifier ? SyntaxKind.Unknown : SyntaxKind.ExpressionStatement); | |||
There was a problem hiding this comment.
What other things can token be here? Why is it that only Identifier leaves the node's kind as unknown?
There was a problem hiding this comment.
This change is necessary so we can correctly handle ExpressionStatement inside createNodeWithJSDoc. You are right, that it would've been set later anyway, but that's too late as the JSDoc would already be attached to the ExpressionStatement node.
Identifier has a special handling here, because it's the only token that could be the start of a LabeledStatement. This change is only about ExpressionStatements starting with parentheses. Hence we can leave this as Unknown and avoid the lookahead to determine whether we are actually dealing with a LabeledStatement.
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
|
User tests look fine; I think all the failures are also failures on master. |
Fixes: #36179
Before this change the
ExpressionStatementand theParenthesizedExpressionhad equal JSDoc as they started at the same position. First of all this doesn't make much sense to have the same information on two different nodes. In addition this caused@typedefto be bound twice causing aDuplicate identifiererror.After this change, we skip parsing JSDoc of ExpressionStatements that start with a ParenthesizedExpression.