* Measure variance of aliased conditional types using variance markers
* Just do variance probing for all type aliases
* Small limiter for predictability
* Inline property set, remove unused functions
* infer from usage JSDoc:Don't emit nested comments
Previously, the trivia on a parameter name would show up inside the
emitted JSDoc comment. If the trivia contained a C-style comment, the
emitted JSDoc comment would be invalid. For example:
```js
function call(callback /*oh no*/) {
return callback(this)
}
```
Emitted this comment:
```js
/**
* @param {(arg0: any) => void} callback /*oh no*/
*/
```
* Remove misleading comment used for debugging.
* Do not merge commonsjs exports onto an alias
getCommonJSExportEquals merges export assignments and export property
assignments. Something like this, which has no equivalent structure in
TS:
```js
module.exports = function() { }
module.exports.expando = 1
```
However, it is sometimes called with an alias, when its
parent, resolveExternalModuleSymbol, is called with dontResolveAlias:
true, and when the initialiser of the export assignment is an alias:
```js
function alias() { }
module.exports = alias
module.exports.expando = 1
```
In this case, (1) the actual value `alias` will have already merged in a
previous call to getCommonJSExportEquals and
(2) getTypeOfSymbol will follow the alias symbol to get the right type.
So getCommonJSExportEquals should do nothing in this case.
This bug manifests in the code for dynamic imports, which calls
getTypeOfSymbol on the incorrectly merged alias, which now has enough
value flags--Function, for example--to take the wrong branch and
subsequently crash.
* Update baselines
* Correct indentation, using correct (I hope) indentation code
Note that part of the code, in formatting.ts, is cloned but should be
extracted to a function instead.
* Remove some possibly-superfluous code
But I see 4 failures with whitespace, so perhaps not.
* Restrict indentation change to avoid breaking baselines
The indentation code is very complex so I'm just going to avoid breaking
our single-line tests for now, plus add a simple jsdoc test to show that
multiline jsdoc indentation isn't destroyed in the common case.
* Switched over to construction for @return/@type
Still doesn't merge correctly though
* Add @return tags to emitter
* Merge multiple jsdocs
(not for @param yet)
* Merge multiple jsdoc for parameters too
* Emit more jsdoc tags
Not all of them; I got cold feet since I'll have to write tests for
them. I'll do that tomorrow.
* Many fixes to JSDoc emit
And single tests (at least) for all tags
* Cleanup in textChanges.ts
* Cleanup in formatting.ts
(Plus a little more in textChanges.ts)
* Cleanup in inferFromUsage.ts
* Fix minor omissions
* Separate merged top-level JSDoc comments with \n
instead of space.
* Don't delete intrusive non-jsdoc comments
* Cleanup from PR comments
1. Refactor emit code into smaller functions.
2. Preceding-whitespace utility is slightly easier to use.
3. Better casts and types in inferFromUsage make it easier to read.
* Fix bogus newline
* Use @andy-ms' cleanup annotateJSDocParameters
1. Sort is now stable in node 11, which exposed a lack in the sorting of
nested ranges. Ranges now sort based on last ending if the start
positions are the same. This means nested ranges sort the
containing range first, even if a range contains another range that
starts at the same position.
2. Symbol has a new member description which can't be accessed through
the prototype. In addition, Array now has flat and flatMap, which I
excluded to keep baselines the same between Node 6-11.
* Obey the excludeArgument parameter when checking JSX signature validity
* Fix conditional type extending any contextual types and accept baselines
* use flag check to also drop unknown from comparison for the same reason
* Slight refinement - make an intersection to ensure parameter constraints flow through contextual types when instantiated
* Format ternary more nicely
* Add new special assignment kinds for recognizing Object.defineProperty calls
* Add support for prototype assignments, fix nits
* Fix code review comments
* Add test documenting behavior in a few more odd scenarios
In JS, when you assign `module.exports = exports` and the entire module is
wrapped in an IIFE, the resulting `export=` symbol, after following
aliases, is the module itself. This results in trying to merge the
file's exports with itself inside `getCommonJsExportEquals`, since it
thinks that it has found new exports, possibly in an object literal,
that need to be merged with the file's exports.
For example:
```js
(function() {
exports.a = 1
module.exports = exports
})()
```
1. Merge enum with expando.
2. Merge enum member with property assignment.
3. Merge interface-declared method declaration with
prototype-property-assignment method declaration.
The reason that the enum merges crash is that getTypeOfSymbol assumes
that symbol flags are (basically) mutually exclusive. This assumption is
shredded, badly, for JS merges.
One fix is to drop the assumption of exclusivity and instead order cases
by least to most likely. This has the highest chance of working, but is
also slow, since you would prefer to order cases by most likely *first*,
not *last*.
The other fix, which is what I did here, is to add a last-chance
re-dispatch at the bottom of
`getTypeOfVariableOrParameterOrPropertyWorker`. This dispatch uses the
valueDeclaration instead of the symbol flags.
When contextual type doesnt find property in unit type, use the index signature from unit type(fix the incorrectly used union type to get the signature)
* Unify JSX Call Checking Codepaths
* Add tests for fixed issues
* Fix lint, move all error checking into the only-run-once resolveSignature call
* Remove unused (unreachable?) code path
* Consolidate a little more duplicated logic into signature checking
* Fix#19775 a bit more
* Cosmetic changes from CR
* Add helpers that understand constructor functions
* getEffectiveConstructSignatures gets construct signatures from type, and
call signatures from constructor functions if there are no construct
signatures.
* getEffectiveConstructSignatureReturnType gets the "JS Class type" for
constructor functions, and the return type of signatures for all other
declarations.
This is a first step toward making constructor functions have construct
signatures instead of call signatures, which will also contribute to
fixing instantiation of generic constructor functions, which is basically
broken right now.
Note that the baselines *improve* but, because of the previously
mentioned generic problem, are still not correct. Construct signatures
for constructor functions and generic constructor functions turns out to
be an intertwined problem.
* Correct correct originalBaseType
And, for now, return anyType for generic constructor functions used as
base types. Don't give an incorrect error based on the function's return
type, which is usually void.
* Add error examples to tests
* Add construct signatures instead of getEffective* functions
* Fix typo in baseline
* Remove pesky newline
I thought I got rid of it!
* Test of constructor tag on object literal method
It doesn't work, and shouldn't in the future, because it's a runtime
error.
* noImplicitAny as suggestion
Note that not all noImplicitAny errors turn into suggestions. In
particular,
1. reportErrorsFromWidening does not, because it doesn't log an error
that infer-from-usage fixes, and fixing it would require
otherwise-unnecessary code.
2. auto types do not have implicit any suggestions, because that would
require running control flow in noImplicitAny mode.
* Rename reportImplicitAny+forbid it for non-checkJS
In JS, you only get implicit any errors/suggestions with checkJS or
ts-check turned on.
* Update baselines
* Use isCheckJsEnabledForFile
* Remove noImplicitAny parameter since it's in scope already
