3.9 regression: varargs in declaration files for JavaScript files break declaration syntax

[TimvdLippe]

TypeScript Version: 3.9.1-rc

Search Terms: jsdoc, varargs, declaration

Code

vararg.js:

/**
 * @param {!Object<string, function(string, ...*):*>} formatter
 * @param {string} format
 * @param {...*} var_args
 */
function takesVarargs(formatter, format, ...var_args) {
 formatter['pattern'](format, var_args);
}

tsconfig.json:

{
 "compilerOptions": {
 "module": "esnext",
 "target": "esnext",
 "outDir": "lib",
 "declaration": true,
 "allowJs": true,
 "checkJs": true
 },
 "files": [
 "vararg.js"
 ]
}

Expected behavior:
(Run with TypeScript 3.8.3)

/**
 * @param {!Object<string, function(string, ...*):*>} formatter
 * @param {string} format
 * @param {...*} var_args
 */
declare function takesVarargs(formatter: {
 [x: string]: (arg0: string, ...arg1: any[]) => any;
}, format: string, ...var_args: any[]): void;

Actual behavior:
(Run with TypeScript 3.9.1-rc)

/**
 * @param {!Object<string, function(string, ...*):*>} formatter
 * @param {string} format
 * @param {...*} var_args
 */
declare function takesVarargs(formatter: {
 [x: string]: (arg0: string, arg1: ...*) => any;
}, format: string, ...var_args: ...*): void;

Note that the function arguments varargs are not properly changed to ...arg1: any[] anymore and are now only arg1: ...*. This means that a subsequent composite usage of this declaration file will crash, as the syntax is not valid.

Playground Link: n/a as Playground doesn't allow me to show the declaration files if the language=JavaScript. Instead it shows me // Using JavaScript, no compilation needed.

Related Issues: A wild guess that #37757 might be related?

[DanielRosenwasser]

I believe this is because we reuse nodes from the source more aggressively, though * is not a reusable type node in a .d.ts file. Is that accurate Wesley Wigham (@weswigham)?

[weswigham]

Yep. The root cause was actually that we don't visit jsdoc node children in our node visitor. (Or even acknowledge jsdoc nodes in it at all). In any case, the named tuple types PR coincidentally already contains a fix.