* Infer from usage quick fix
* Change full function singature
* Add property/element access support
* Fix a few issues
* Some cleanup
* Expose getArrayType and getPromiseType
* Switch to collecting all usage before infering
* Infer array and promise type arguments
* Handel enums in binary operators
* consolidate usage of addCandidateTypes
* Handel rest paramters
* Properly handel `+=` and `+` inference for numbers and strings
* Add print quickfixes debug helper
* Add rest param tests
* Add optional paramter tests
* Handel set accessors
* Support getters
* Support no implicit any error for variable at use site
* Support properties
* Only offer quick fix if an infered type other than any is available
* Rename functions
* Move to a separate namespace
* Check cancellation token
* Cleanup
* Check for accesibile symbols where serializing types
* Remove JS support
* Reorganize functions
* Mark APIs as internal
* Fix lint errors
* Removed conflict markers.
* Update 'createSymbol' to use '__String'.
* Fixed most problems relating to '__String' and 'includeJsDocComments' in the fix itself.
* Addressed most API changes.
* Make all helpers internal
* Use a diffrent writer and not the built-in single line write
* Infer types for all parameters in a parameter list instead of one at a time
* Accept baselines
* Code review commments
* Respond to code review comments
If there are only declarations, use the new function as the initializer
for a destructuring declaration.
If there are declarations and writes, changes all of the `const`
declarations to `let` and add `| undefined` onto any explicit types.
Use destructuring assignment to accomplish both "initialization" and
writes.
I don't believe there is a case where there are both declarations and a
return (since the declarations wouldn't be available after the return).
UNDONE: this could probably be generalized to handle binding patterns
but,
for now, only identifiers are supported.
Fixes#18242Fixes#18855
Found while updating #18285 to latest master. Not sure what this fixes, but it was definitely incorrect - `node` must be a `Block` at this point, so this cast must have been intended for `node.parent`, which was checked against `TryStatement` right before it.
Previously, only the success path did this; it was missing in the error
reporting path in resolveCall. This resulted in crashes for unsupplied
type arguments when the supplied type arguments were incorrect.
Previously, getSpreadType didn't set any flags and relied on its callers
to do so. This was error-prone because getSpreadType often returns
non-fresh types.
