* Undo 'any' inference propagation
Removing this only changes one test slightly, and fixes JQuery types,
which rely on the old method of inference.
* Add jquery regression test and update baselines
* Restore any inference propagation to wildcard only
* Support services settings
* Code review
* More review
* Use different names for Options and GetCompletionsAtPositionOptions (todo: come up with better names)
* More renames
* More renaming
* Support quote style in importFixes
* Add `importModuleSpecifierPreference` option
* Support quote style for `throw new Error('Method not implemented.')` (#18169)
* options -> preferences
* Do not add undefined for this assignments in functions
* Test:constructor functions with --strict
* First draft -- works, but needs a stricter check added
* Update baselines
* Make undefined-skip stricter and more efficient
Symbol-based now instead of syntactic
* Exclude prototype function assignments
* Add explanatory comment
* Correctly parse JSDoc type *=
* Allow `markdown` quoted param names in JSDoc
* Add tests and update baselines
* Get correct span for the type '*'
* Fix whitespace lint
* Add unbracketed type test
* Combine keyof T inferences
* Extract covariant inference derivation into function
* Test:keyof inference lower priority than return inference
for #22376
* Update 'expected' comment in keyofInferenceLowerPriorityThanReturn
* Update comment in test too, not just baselines
* Fix typo
* Move tests
* Fix type when annotated with a JSDoc function type
Previously,
1. A variable annotated with a JSDoc function type would not require all
its parameters to be provided. This should only apply to functions
without a type annotation.
2. A parameter in a function with a JSDoc function type annotation would
still have the type 'any'.
3. Two `var` declarations in a Typescript and Javascript file,
respectively, would error even when they had identical function types.
* Update baselines and add constructor test
* Handle ConstructorType too
* Add test:method sig inside literal type
* Contextually type parameters by parent sig's JSDoc
Instead of a syntactic check in getJSDocTag
* Remove redundant check:isUntypedSignatureInJSFile
* Positive check for value signatures
Instead of excluding type signatures piecemeal.
* Parse JSDoc ...T and T= only at top-level JSDoc
...T and T= should only be legal at the top level of a type, and only in
JSDoc, since at least T= is ambiguous elsewhere. This PR changes parsing
to make that happen. The resulting parse tree is now simpler, allowing
me to get rid of some code I had to add in the checker.
* Extract JSDoc type parsing into its own function
* PR comments:return from parseJSDocType
* jsdoc ?Type adds optionality to parameters
Chrome devtools expects that parameters with type `?T` (or `T?`) add
null to `T` and optionality to the parameter. Previously it only added
null to the type.
Currently the PR does *not* add undefined to the type of
`T`, which is expected by chrome-devtools-frontend, but is inconsistent
with typescript's rules. The implementation achieves this inconsistency by
exploiting the fact that checking the signature adds optionality and
checking the parameter adds `undefined`.
* Update chrome-devtools-frontend baseline
* Add optionality only for jsdoc postfix=
* Skip jsdoc prefix types in isJSDocOptionalParameter
Previously isJSDocOptionalParameter was incorrect for types like
`?number=`, which are optional but have JSDocNullableType as their root
type node.
* Refactor declaration emitter into declaration transformer
* Slight cleanup from code review feedback
* Incorporate fix for new test
* Swaths of PR feedback
* Merge public methods
* Per-file output
* Preserve input import ordering more often
* Unify jsdoc comment start detection under more lenient rule
* Move to per-file transformations to reduce the memory that msut be retained
* Fix typo
* No errr on unmatchable `@param` tags
Such as when the initializer is not a function, or when the function
mentions `arguments` in its body.
* Do not require dummy param for JS uses of arguments
1. JS functions that use `arguments` do not require a dummy parameter in
order to get a type for the synthetic `args` parameter if there is an
`@param` with a `...` type.
2.JS functions that use `arguments` and have an `@param` must have a
type that is a `...` type.
* Check for array type instead of syntactic `...`
* Address PR comments
* Update baselines
* Pass stackTraceLimit to parallel workers
Specifying it breaks some output, both in parallel and normal runners.
I'll look at that in another commit, probably another PR, depending on
how simple the problem is.
* Always convert stackTraceLimit to a number
Sometimes it's not a number, even though the type claims it is.
