fix getParameterSymbolFromJSDoc

[sandersn]

getParameterSymbolFromJSDoc didn't correctly track back to the source of a @param tag in a lot of cases, because it didn't match the lookup code in getJSDocCommentsAndTags. Now both functions share the same utility functions.

Note that the utility functions return Node | undefined, and the top-down uses from getParameterSymbolFromJSDoc take advantage of the return value, while the bottom-up uses from getJSDocCommentsAndTags just use the truthiness. I can annotate it as such, but didn't in the initial pass.

Fixes #19268

[sandersn]

@mhegazy we should put this in 2.6 because it fixes a new error for 2.6.

[mhegazy]

Please port this to release-2.6

[sandersn]

It's now in release-2.6

[ajafff]

@sandersn This changes how JSDoc comments apply to VariableStatements with multiple VariableDeclarations:

/** @deprecated */
var a, b;
a; // deprecated
b; // not deprecated, used to be deprecated in ts@<2.6.0

Is it intentional that JSDoc only applies to the first VariableDeclaration?

[ghost]

No need to export.

Please annotate potentially undefined return values (although as written this is potentially false).
I would prefer multiple statements with local variables instead of writing it all as one expression that has to be formatted on different lines anyway.

if (isExpressionStatement(node)) {
    const { expression } = node;
    if (isBinaryExpression(expression)) {
        const { operatorToken, right } = node;
        return operatorToken.kind === SyntaxKind.EqualsToken ? right : undefined;
    }
}

[ghost]

I need to leave a comment indicating the requested changes.

[ghost]

May be obviated by #18832.

[sandersn]

@ajaff It is intentional. Here are the reasons:

1. After a big discussion in the Typescript room, there were more fussy people than messy ones (we do make a compiler, after all).
2. We are also running a twitter poll and opinions are about evenly split there. So whatever we do, it will be surprising to about half of all people.
3. As far as I can tell from closure discussions, the closure compiler behaves (behaved?) this way too, even issuing a warning.
4. It's easier to implement this way. (This was the deciding factor given how mixed the other indicators were.)