* 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
* fixUnusedIdentifier: Remove arguments corresponding to unused parameters
* Update API (#24966)
* Fix handling of deletions: Make a list of things to delete and don't delete until the end
* Remove dummy test
* Bug fixes
* Update API (#24966)
* Move code to textChanges
* Fix duplicate errors in js special assignments
* Simplify checkExpressionCached call to checkExpression
* Accept baselines after merge
* Use Map for deferredNodes and improve NoDeferredCheck comment
I added an assert when a duplicate was added, but it caused 18 failures
in our test suite.
* Remove NoDeferredCheck
* First attempt at parsing. Doesn't work
But my machine is dying, so this is an emergency commit.
* Parsing sort of works
But it's not right yet; the test I added fails. See the TODO I added.
* Parse link tag as comment
* Add refactor to convert named to default export and back
* Support ambient module
* Handle declaration kinds that can't be default-exported
* Update API (#24966)
Previously, TypeScript would resolve the reified types for the
`design:types` decorator emit in the regular `currentScope`. That scope
does not include class declaration bodies.
However when reifying types, class declarations do introduce a new scope
for any `TypeVariable`s declared on them. Because TS resolved the
EntityName for such types against the parent scope (e.g. the source
file), not the class scope, TypeScript would either fail to resolve the type (giving `TypeReferenceSerializationKind.Unknown`), or
incorrectly resolve to a different, accidentally matching symbol in the outer scope (giving `TypeWithConstructSignatureAndValue`).
This would result in an emit referencing an undeclared symbol, or
mis-referencing the wrong symbol.
__metadata("design:type", typeof (_a = typeof TypeVariable !== "undefined" && TypeVariable) === "function" && _a || Object)
__metadata("design:type", TypeVariable)
This change special cases `currentScope` for
`serializeTypeReferenceNode` to use a class scope, if present. This
changes the emit for a `TypeVariable` back to `Object`:
__metadata("design:type", Object)
* Multifaceted approach to performantly enabling fileExists outside of the synchronize step in the emit host
* make cache undefinable and handle correctly
* Remove unneeded cast
* Readd assert
* More useful failure messager
That is, only nest them if their name matches the provided parent name.
Otherwise do not nest them.
Note that this commit changes the behaviour of an incorrect typedef that
contains both an `@type` child tag and `@property` child tags.
Previously, the `@type` would be incorrectly nested under a `@property`
tag with type `object`, just like `@property` tags would be. Now, the
`@type` tag causes the entire typedef to ignore the `@property` tags and
treat the typedef as if it were an instance of the
typedef-and-nested-type pattern:
```js
/**
* @typedef {Object} name
* @type {{ the, actual, type }}
*/
```
* Don't recommend to install '@types/foo' if that already exists
* Add different extra diagnostic text if the @types package exists
* Update API (#24966)
* getDeclarationIdentifier handles undefined name
getNameOfDeclaration actually doesn't handle all declarations, only
those that produce names that could be reasonably used as an identifier.
Until now, getDeclarationIdentifier assumed that getNameOfDeclaration
always returned a name. This caused crashes whenever we tried to get the
name of something like a Constructor.
* Add test and baselines
* getNameOfDeclaration can return undefined
This requires all callers to handle it, which turns out now to be too
disruptive.
* Fix lint
* Check extends tag first in getClassExtendsHeritageClauseElement
Previously getBaseTypeNodeOfClass checked, but this is only used in a
few places.
* Fix names and add test
* Update API baseline
* Move jsdocAugments tests to conformance/jsdoc
* Better naming in checkClassLikeDeclaration
Previously, getJSDocCommentAndTags could recur up to four times if any
of four predicates matched. However, to avoid duplicates, the predicates
have been tuned to be mutually exclusive, which means that the recursion
can be turned into a while loop. The while loop is much simpler and
safer, since it is guaranteed to only walk up the tree one time. In
addition, the extra check that adds jsdoc from initializers only runs
once, before the loop, further reducing the opportunity for duplicate
jsdocs.
I thought about further simplifying the code that gets the next node to
check, but to know when to stop the loop, I'd need a predicate that is
as complicated as the code in `getNextJSDocCommentLocation`, so I kept
the existing code, just reordering it for compactness.
