* Allow JSContainers to merge with namespaces
Expando functions marked with JSContainer previously failed to merge
with namespaces. This change adds JSContainer to ValueModuleExcludes,
allowing this kind of merge.
* Improve symbol flags to fix namespace/expando merging
Calls to bindPropertyAssignment now provide which special assignment
kind they originated from. This allows better symbol flags to be set:
1. Property assignments get the FunctionScopedVariable flag, since they are
equivalent to a `namespace` exporting a `var`.
2. Prototype property assignments get the Method flag if the initialiser
is functionlike, and Property otherwise.
3. Prototype assignments get the flag Property.
(3) is still not entirely correct (it's missing the Prototype flag),
but is what existed previously. I'll try adding the Prototype flag to
see whether it changes any baselines.
* Add cross-file merge test
* Update missed baselines
* Namespace declarations are primary for merging purposes
Also, property-assignments go back to being property declarations, not
function-scoped variable declarations
* Revert unneeded changes
* Revert unneeded changes (in a codefix this time)
* Put JSContainer on all assignment declarations
This allows most of the new special-case merge code to go away. It now
uses the JSContainer special-case code, which already exists.
* Missed comment
* Fix extra newline lint
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
