skipping narrowing if the old algorithm produces a type to which the
assigned type is not assignable.
This also means we'll no longer narrow for erroneous assignments where
the assigned type is not assignable to the declared type. This is the
reason for the numericLiteralTypes3 baseline change.
Fixes#26405.
Previously, they were mistakenly treated as private because of a check
that required all super property accesses (like `super.x()`) to be
references to a MethodDeclaration or MethodSignature. This change also
allows PrototypeProperty special assignment kinds.
* Allow special property assignments in TS
But only for functions and constant variable declarations initialised with
functions.
This specifically excludes class declarations and class expressions,
which differs from Javascript. That's because Typescript supports
`static` properties, which are equivalent to property assignments to a
class.
* Improve contextual typing predicate
Don't think it's right yet, but probably closer?
* More fixes.
The code is still fantastically ugly, but everything works the way it
should.
Also update baselines, even where it is ill-advised.
* Cleanup
* Remove extra whitespace
* Some kind of fix to isAnyDeclarationName
It's not done yet.
Specifically, in TS:
Special property assignments are supposed to be declaration sites (but not all
top-level assignments), and I think I
got them to be. (But not sure).
In JS:
Special property assignments are supposed to be declaration sites (but not all
top-level assignments), and I'm pretty sure ALL top-level assignments
have been declaration sites for some time. This is incorrect, and
probably means the predicate needs to be the same for both dialects.
* Add fourslash and improve isAnyDeclarationName
Now JS behaves the same as TS.
* Cleanup from PR comments
* This-property w/empty object init: use type annotation
* JS initializer type doesn't apply to this-property assignments
* Move getJSExpandoType into getWidenedType* functions
Plus some cleanup.
* Improved style from PR comments
* Parameters are not expando
* Classes can extend JS constructor functions
Now ES6 classes can extend ES5 constructor functions, although only
those written in a JS file.
Note that the static side assignability is checked. I need to write
tests to make sure that instance side assignability is checked too.
I haven't tested generic constructor functions yet either.
* Test static+instance assignability errors+generics
Note that generics do not work.
* Cleanup from PR comments
* Even more cleanup
* Update case of function name
* Fixes#26128 - signature comp for jsdoc @class.
Another issue caused by js functions tagged with jsdoc
`@constructor` not having construct signatures.
A jsdoc function type that constructs a type (`function(new: Ex)`),
has a construct signature and return value inferred as the
constructed type where as a jsdoc `@constructor` has no construct
signatures, and it's call signature has a void return type
(or undefined).
i.e:
```javascript
/** @constructor **/ function E() {};
// typeof E -> call signature: () => void
/** @param {function(new: E)} d */ function c(d) {}
// typeof d -> construct: () => E
```
--
This commit fixes this (in an inelegant way) by considering `@class` function signatures as construct signatures and synthesizing it's return value _only for signature comparison_.
There might be a slight performance hit, since the synthesized return value is not cached; but changing the `@class` function's return type in `getReturnTypeOfSignature` causes other issues.
* Update jsdoc function test to fix mistake.
* Allow type predicates
1. Parse type predicates. Note that they are parsed everywhere, and get
the appropriate error when used places besides a return type.
2. When creating a type predicate, correctly find the function's parameters
starting from the jsdoc return type.
* Fix type of TypePredicateNode.parent: add JSDocTypeExpression
* Update API baselines
* Handle JSDoc signature inside @type annotations
* Fix circularity when getting type predicates
Also move createTypePredicateFromTypePredicateNode closer to its use
* More cleanup based on review comments
typeMaybeAssignableTo.
typeMaybeAssignableTo decomposed unions at the top level of the assigned
type but didn't properly handle other unions that arose during
assignability checking, e.g., in the constraint of a generic lookup
type.
Fixes#26130.
* Fixes#26122.
When `resolveCall` does not resolve in `resolveNewExpression`, the error should only be thrown if there is a *defined* signature that is not-void.
* Fix other baselines to remove erroneous TS2350.
unmangled package name where appropriate.
Add a test case for an untyped sub-module of a scoped package with
typings. The other diagnostic message is covered by existing tests; I
guess no one looked at the baselines closely enough.
Fixes#23999.
* Properly infer `this` in tagged `@constructor`s.
`c.prototype.method = function() { this }` was already supported.
This commit add support to two more kinds relying on the JSDoc
`@constructor` tag. These are:
1. `/** @constructor */ function Example() { this }`
2. `/** @constructor */ var Example = function() { this }`
* Update the baseline for js constructorFunctions.
C3 and C4 `this` was set as `any`, now it is properly showing as
the class type.
* Fix lint errors
* Add circular initialisers to constructo fn tests.
* Error (`TS2348`) if calling tagged js constructors
When calling a JS function explicitly tagged with either `@class` or
`@constructor` the checker should throw a TS2348 not callable error.
* Don't resolve jsdoc classes with construct sigs.
This undoes the last commit that sought to change how js functions
tagged with `@class` were inferred. For some reason, currently
unknown, giving those functions construct signatures causes issues
in property assignment/member resolution (as seen in the
`typeFromPropertyAssignment12` test case).
Instead of changing the signature resolution, the error is explicitly
generated in `resolveCallExpression` for those functions.
* In JSDoc, resolve import types as values too
This is something that we probably should have been doing for some time.
Fixes#26049
* Fix whitespace lint
* Only bind module.exports if no local definition exists
Note that this uses `lookupSymbolForNameWorker`, which is really a
best-effort check since it only knows about symbols that it has already
encountered.
As a side-effect, even when `module` is bound as part of a
`module.exports` reference, it only declares it once instead of one
declaration per reference.
* Only type module.exports inside module files
It is an error inside script files, but the binder sometimes creates a
ModuleExports symbol because we doesn't know whether we have a commonjs
module until after binding is done.
* Only bind module.exports in a commonjs module
Note that this, too, is a best-effort check since evidence of
commonjs-ness may be found after a *reference* to module.exports. (A
reference to module.exports alone is not enough evidence that a file is
commonjs. It has to have an assignment to it.)
* Support the JSDoc @enum tag
`@enum` is used on a variable declaration with an object literal
initializer. It does a number of things:
1. The object literal has a closed set of properties, unlike other
object literals in Javascript.
2. The variable's name is resolvable as a type, but it just has the
declared type of the enum tag.
3. Each property's type must be assignable to the enum tag's declared type,
which can be any type.
For example,
```js
/** @enum {string} */
const Target = {
START: "START",
END: "END",
MISTAKE: 0, // error 'number' is not assignable to 'string' -- see (3)
}
Target.THIS_IS_AN_ERROR; // See (1)
/** @type {Target} See (2) */
var target = Target.START;
```
* Fix lint, add new test case, update API baselines
* Revert "Revert "Explicitly typed special assignments are context sensitive (#25619)""
This reverts commit 16676f2707.
* Revert "Revert "Explicitly typed prototype assignments are context sensitive (#25688)""
This reverts commit ff8c30d636.
* Initial, wasteful, solution
It burns a check flags. Probably necessary, but perhaps not.
I haven't accepted baselines, but they are a bit questionable. I'm not
sure the synthetic type is right, because I expected to see
{ "exports": typeof import("x") } but instead see { "x": typeof
import("x") }.
* Update some baselines
* module.exports= always uses lhs type
Conflicts between exports property assignments and exports assignments
should get a union type instead of an error.
* Fix lint and accept good user baselines
* Add tests based on user tests.
These currently fail.
* Fix all but 1 of user test bugs found by typing module.exports
Still quite messy and full of notes
* Follow merged symbols+allow any object type
This allows exports like `module.exports = new EE` to have properties
added to them.
Still messy, but I'm going to run user tests and look for regressions.
* Update improved user baselines
* Fix infinite recursion when checking module.exports
* Fix bogus use-before-def error
getExportSymbolOfValueSymbolIfExported should always merge its returned
symbol, whether it's symbol.exportSymbol or just symbol.
* Update user test baselines
* Cleanup
* More small cleanup
* Bind `module` of `module.exports` as a special symbol
Previously it was also special, but created during name resolution in
the checker. It made sense when there was only one special symbol for
all files, but now there is one `module` symbol per file.
* Fix parsing of parenthesized JSDoc parameters
Parenthesis can start a jsdoc function parameter since it is just a
type, and parenthesis can start a type:
```js
/** @type {function(((string))): void} */
```
However, this is not legal in other parameter lists:
```ts
function x((((a))): string) { }
```
This change makes jsdoc function parameter lists parse differently than
normal parameter lists by allowing parenthesis as a start character of
jsdoc parameters.
* Parse nested uses of jsdoc function types
* Fix test
* add grammar check for labeled function declaration
* fix debug failed on labeled class declaration
* move labeled statement check to binder and add more pattern for check
* update diagnostic message
* update baseline
* Explicitly typed prototype assignments:ctx sensitive
Follow up to #25619: Add the necessary code to type `prototype`
correctly in prototype assignments so that code like
`F.prototype = { ... }` properly makes the object literal context
sensitive.
* Fix lint
* Explicitly typed js assignments: context sensitive
Explicitly typed special assignments should be context sensitive if they
have an explicit type tag. Previously no special assignments were
context sensitive because they are declarations, and in the common,
untyped, case we inspect the right side of the assignment to get the
type of the left side, and inspect the right side of the assignment to
get the type of the left side, etc etc.
Note that some special assignments still return `any` from
checkExpression, so still don't get the right type.
Fixes#25571
* Change prototype property handling+update bselines
* Fix indentation in test
* Update baselines
* Get return type from `@type` tag
This only happens in the checker, where the type is easily accessible.
The syntax-based check in getEffectiveReturnTypeNode as a fast path, and
for other uses that don't want to make a call to getTypeFromTypeNode.
Fixes#25525
* Implement PR suggestions
* Error when type tag isn't callable
* Fix lint
Previously it did not, causing misleading excess property errors. Note
that assignability errors with conditional types are still usually
confusing. This PR doesn't address that.
Also, make sure that exact matches in getSpellingSuggestion are skipped.
Block scoped variables, classes and enums would issue a bogus
use-before-def error in jsdoc because name resolution always adds Value,
even when resolving a type.
Fixes#25097
* get return type from `@type` tags
Previously, getJSDocReturnType did not check the `@type` tag for a type
node that has a return type. Now it does.
* Improve doc comment of getJSDocReturnType
* More type predicates in type guards!
* Update API baselines with new documentation (?!)
* Index signatures contribute properties to unions
This means that in a union like this:
```ts
type T = { foo: number } | { [s: string]: string }
```
`foo` is now a property of `T` with type `number | string`. Previously
it was not.
Two points of interest:
1. A readonly index signature makes the resulting union property readonly.
2. A numeric index signature only contributes number-named properties.
Fixes#21141
* Correctly handle numeric and symbol property names
1. Symbol-named properties don't contribute to unions.
2. Number-named properties should use the numeric index signature type,
if present, and fall back to the string index signature type, not the
other way round.
Previously variable declaration+function expression worked.
Note that class expression/class declaration do not work, due to the way
they are specified. I added a test for future reference.
* Adds related spans and error grouping for duplicate identifier errors
* Trim trailing whitespace
* Record related info in error baselines
* Make error more whimsical
* Destructuring declaration prefers type annotation type
Previously, getTypeForBindingElement would always union the declarations type and
the type of the default initializer. Now, if the declaration has a type
annotation, it does not union with the initializer type. The type
annotation's type is the one used.
* Small cleanup in parentDeclarationHasTypeAnnotation
* Refactoring based on PR comments
* Combine getCombined*Flags into a single helper function
Retain the individual functions since they are used a lot.
* Remove unneeded temp
