* Refactor declaration emitter into declaration transformer
* Slight cleanup from code review feedback
* Incorporate fix for new test
* Swaths of PR feedback
* Merge public methods
* Per-file output
* Preserve input import ordering more often
* Unify jsdoc comment start detection under more lenient rule
* Move to per-file transformations to reduce the memory that msut be retained
* Fix typo
From #22510 and #22514, which remove lots of bogus `@param` errors and
add lots of `Object is possibly undefined` errors, respectively.
There are quite a few effects of the correct addition of undefined to
types based on postfix= in jsdoc, actually.
* No errr on unmatchable `@param` tags
Such as when the initializer is not a function, or when the function
mentions `arguments` in its body.
* Do not require dummy param for JS uses of arguments
1. JS functions that use `arguments` do not require a dummy parameter in
order to get a type for the synthetic `args` parameter if there is an
`@param` with a `...` type.
2.JS functions that use `arguments` and have an `@param` must have a
type that is a `...` type.
* Check for array type instead of syntactic `...`
* Address PR comments
* Update baselines
* Pass stackTraceLimit to parallel workers
Specifying it breaks some output, both in parallel and normal runners.
I'll look at that in another commit, probably another PR, depending on
how simple the problem is.
* Always convert stackTraceLimit to a number
Sometimes it's not a number, even though the type claims it is.
* Brackets and postfix= in `@param` add undefined
Previously they only added optionality.
Note that, unlike Typescript, when a parameter initializer is specified
in jsdoc, it does not remove undefined in the *body* of the function.
That's because TS will generate initialisation code, but JS won't, so
the author will have to manually write code to remove undefined from the
type.
```js
/** @param {number} [a=101] */
function f(a) {
// a: number | undefined here
if (!a) {
a = 101
}
// a: number here
}
```
Note that we don't check that
1. the initializer value is actually assigned to the parameter.
2. the initializer's type matches the declared type of the parameter.
Pretty much we just parse it and leave it alone.
* Address PR comments
* Harden var x=require name resolution+update chrome baseline
Chrome-devtools crashed after the new `var = require('x')` resolution
because it forgot to check whether the declaration had an initializer.
* Update chrome-devtools-frontend baseline
* Add some new user tests to test salsa
* Use current latest, not "latest"
* Add other js user tests
* Add new baselines
* Fix new user tests' typeroot. Move github to octokit/rest
