* Fix crash in type resolution in JS IIFEs
We recognise IIFEs as JS special assignment initialisers, but not as
containers otherwise. That means that IIFEs will not have a symbol
unless they have an *outside* assignment.
The permanent fix will be to make IIFEs a container, based on the
containership of the value that they return. This fix does not do that;
it just makes type resolution return undefined instead of crashing.
* Comment the IIFE-fix line
* Undo 'any' inference propagation
Removing this only changes one test slightly, and fixes JQuery types,
which rely on the old method of inference.
* Add jquery regression test and update baselines
* Restore any inference propagation to wildcard only
* Combine keyof T inferences
* Extract covariant inference derivation into function
* Test:keyof inference lower priority than return inference
for #22376
* Update 'expected' comment in keyofInferenceLowerPriorityThanReturn
* Update comment in test too, not just baselines
* Fix typo
* Move tests
* 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
* 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
Wesley Wigham
Nathan Shively-Sanders
Andy
Anders Hejlsberg
Sheetal Nandi
Matt Bierner
Daniel Rosenwasser
Mohamed Hegazy