* 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
* 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
The assert is over-optimistic and should be removed until we can parse
every possible thing that people might put in a JSDoc type position.
Fixes#26693
* unknownify accesses
* Move to simplify to break less with fewer changes
* Accept baselines for now
* Always propegate any as an index type
* Fix flow control in the presence of simplifiable types
* Add spy repro from #25181
* Retain errorType when it is used as a marker for the lack of a constraint
* Small refinement
* Add new test
* Move most potentially recursive types from isIdenticalTo into structuredTypeRelatedTo to match the non-identity relations
* Fix nits
* Doesnt need to be undefineable at all
* Declaration emit includes function properties
It does this by printing the type as an object literal type:
```ts
function f() { }
f.p = 1
```
Appears in a d.ts as
```ts
declare var f: {
(): void;
p: number;
}
```
It would also be possible to represent it as a namespace merge. I'm not
sure which is better.
```ts
declare function f(): void;
declare namespace f {
export var p: number;
}
```
In order to avoid a private-name-used error (though I think it was
actually *unused*), I also had to change the nodeBuilder code to match.
This is arguably harder to read. So it's possible that I should instead
keep the nodeBuilder version as `typeof f` and make an exception for
private name use.
* Emit namespace merge instead of object type
This makes the change smaller, overall.
* Fix isJSContainerFunctionDeclaration+namespace merges
Also improve emit style to match other namespace emit.
* Add isPrivate + test case from PR comments
Previously, intersections were only allowed as targets, but this was
just an artifact of the original implementation, which operated inside
the structural part of isRelatedTo. Removing this restriction catches
subtle bugs in React user code, where a function named `create` returns
a mapped type whose types are all branded numbers. The display of these
properties, for some original type `T`, is not `number & { __ }` but
the much-less-obvious `RegisteredStyle<T>`.
Previously, getWidenedTypedFromJSPropertyAssignment was not called for
Typescript code. Since property assignments on functions, it is. That
meant that property assignments would incorrectly create a JS container
for empty object literals in a property assignment, even in Typescript:
```ts
const one = () => 1
one.p = {}
one.p.q = {} // should not work in Typescript!
```
Now empty object literals never create expando objects in Typescript,
because getJSExpandoObjectType requires the declaration to be in a JS
file.
* Use context free expression types in evolving array checking and cache context free type
* Simplify second test
* Low max depth a tad just so node 8 wont stack out
* By request make flow control a round number
