* Bind non-expando property assignments at toplevel
Previously, only property assignments with expando initialisers were
bound in top-level statements. Now, all property assignments are bound.
This requires a matching change in the checker to make sure that these
assignments remain context sensitive if their valueDeclaration is a
'real' declaration (ie a non assignment-declaration).
* Add baselines for new test
* Allow special assignments to have a contextual type of their declared type if present
* Expand change to cover all js special assignments
* Remove extraneous line
* Skip asterisks after newline when parsing JSDoc types
* Single boolean expression
* Test for parsing and printing multiline function signatures with *
* check for expando initializers in resolveEntityName
when resolving type parameters in a prototype property assignment
declaration. For example, this already works:
```js
/** @template T */
function f(x) { this.x = x }
/** @returns {T} */
f.protototype.m = function () { return this.x }
```
This now works too:
```js
/** @template T */
var f = function (x) { this.x = x }
/** @returns {T} */
f.prototype.m = function () { return this.x }
```
Fixes#26826
* Lookup type parameters on prototype-assignment methods
In the same way that they're looked up on prototype-property methods.
That is, this previously worked:
```js
/** @template T */
function f() { }
/** @param {T} p */
f.prototype.m = function () { }
```
And this now works too:
```js
/** @template T */
function f() { }
f.prototype = {
/** @param {T} p */
m() { }
}
```
Note that the baselines still have errors; I'll file a followup bug for
them.
* Look up types on property assignments too
As `files` always contains declaration files of external libraries, lib files and declaration files from typeRoots, the previous condition evaluated to false for probably all projects out there.
This changes the condition to compare array length after filtering out all declaration files.
That avoids unnecessary work of path normalization in the common case where everything is ok.
equalOwnProperties would incorrectly report two map-like objects as equal in
the case where a property defined in `left` was not defined in `right` and
whose value was considered "equal" to undefined by the equalityComparer.
This bug was found by an alert on LGTM.com
Nathan Shively-Sanders
TypeScript Bot
Daniel Rosenwasser
Ron Buckton
Wesley Wigham
Tim Schaub
Klaus Meinhardt
Minh Nguyen
christian
王文璐
Anders Hejlsberg
Matt McCutchen
Sheetal Nandi
Ryan Cavanaugh
csigs
csigs
Benjamin Lichtman
Benjamin Lichtman
Mine Starks
Sam Lanning