Fix parsing of parenthesized JSDoc parameters #25799
Conversation
Parenthesis can start a jsdoc function parameter since it is just a type, and parenthesis can start a type: ```js /** @type {function(((string))): void} */ ``` However, this is not legal in other parameter lists: ```ts function x((((a))): string) { } ``` This change makes jsdoc function parameter lists parse differently than normal parameter lists by allowing parenthesis as a start character of jsdoc parameters.
|
I added a commit that also fixes #25800 and shows that use of parenthesised types in nested jsdoc functions works. |
| // @strict: true | ||
| // @Filename: paren.js | ||
| /** @type {function((string), function((string)): string): string} */ | ||
| var x = s => s.toString() |
There was a problem hiding this comment.
Would be nice to give the arrow function 2 parameters to verify that the contextual type is correct.
There was a problem hiding this comment.
Oops, I forgot to copy over the newer version of my in-editor test buffer. Fixed.
| return isStartOfParameter(); | ||
| return isStartOfParameter(/*isJSDocParameter*/ false); | ||
| case ParsingContext.JSDocParameters: | ||
| return isStartOfParameter(/*isJSDocParameter*/ true); |
There was a problem hiding this comment.
Does anything bad happen if we just always treat ( as the start of a parameter? It's a parse error anyway, right?
There was a problem hiding this comment.
It disrupts parsing quite a bit. I'm not sure why, but it appears to cause type parameter lists to be parsed as parameter lists in arrow functions, and it also breaks function expressions inside object literal property assignments.
Parenthesis can start a jsdoc function parameter since it is just a type, and parenthesis can start a type:
/** @type {function(((string))): void} */However, this is not legal in other parameter lists:
This change makes jsdoc function parameter lists parse differently than normal parameter lists by allowing parenthesis as a start character of jsdoc parameters.
Fixes #25779
Fixes #25800