* 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
Eg. constructor.js was adding constructor function to aquisition.include which
resulted in the mismatch between typing installer's typeAquisition (which was passed as JSON string and parsed back to null) and one in project
That meant we kept on queuing the new typing installation request.
Fixes#27435
* Now adding @type to variable declarations, at least
Probably everything else, but not as well.
* Improve @param output and add test
It's still bad, but at least it's not wrong.
* Add some js/inferFromUsage tests and fixes
Also, remove redundant is(Set|Get)Accessor functions.
* Fix @typedef refactor
* Emit JSDoc optional parameters
By surrounding the parameter name with brackets. It is super, super ugly
right now.
* Get rest of existing tests working
* Correct location of comments
* Handle @param blocks
1. Format multiple params nicely in a single-multiline block.
2. Generate only params that haven't already been documented. Existing
documentation is not touched.
* Re-add isGet/SetAccessor -- it is part of the API
* Move isSet/GetAccessor back to the original location
* Oh no I missed a newline and a space
* Switch to an object type
* A lot of cleanup
More to come, though. annotate is only called in
annotateVariableDeclaration where we don't know whether we're in JS or
not.
* Move and delegate to annotateJSDocParameters
* Address PR comments
* Lint: newline problems!!!!
* Switch another call to getNonformattedText
* Update baseline missed after merge
