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
in object literal methods inside an object literal with a type
annotation.
Note that this does not change:
1. The type of `this` in object literal methods.
2. The fact that this-property assignments are still declarations. They
just don't block contextual typing like most declarations do.
This change is a bit expensive. It first calls getThisContainer, which
walks the tree upward. Then it calls checkThisExpression, which will
usually call getContextualType on the object literal method. If the new
code then returns true, it will proceed to redo much of that work.
Calling checkThisExpression should not cause incorrect circularity
failures; we only have to inspect the shape of the object literal and
not the types of its properties to determine its type.
* codeFixInferFromUsage: Assume that using `x[0]` means that `x` is an array
* Remove unnecessary '||' with non-falsy LHS
If only there were some kind of type-checker for JavaScript that could detect this sort of thing
* Start adding survey event
* Add surveyReady event
* Remove old notes
* Move event, simplify type, add test
1. Move the survey event to sendProjectTelemetry so that it happens on
open instead of on editing tsconfig.
2. Remove URL from the survey type; VS code should control this
information.
3. Add test based on large files event test. I'm not sure it's in the
right place, though.
* Fix tests and update API baseline
* Split survey sending from telemetry
Based on tests requested during review.
* Add additional assertion
* getEditsForFileRename: Avoid changing import specifier ending
* Support .json and .jsx extensions
* Restore typeRoots tests
* Fix json test
* When --jsx preserve is set, import ".tsx" file with ".jsx" extension
* Support ending preference in UserPreferences
* Get [type] parameter types from @type tag
Previously only the return type was used in cases like this:
```js
/** @type {<T>(param?: T) => T | undefined} */
function g(param) {
return param;
}
```
Now the type parameters from the type tag are used, and the compiler
gets the type of the parameter by using the position in the signature of
the type tag.
Fixes#25618
* Fix split ifs according to PR comments
Sam Lanning
Tim Schaub
Wenlu Wang
Nathan Shively-Sanders
Sheetal Nandi
csigs
Andy
Anders Hejlsberg
Andrew Casey
Ryan Cavanaugh