@amcasey: Preserve leading trivia when organizing imports
When organizing imports, we used to move the leading and trailing trivia
of each individual import with that import as it was repositioned or
deleted. This had the unfortunate effect of repositioning or deleting
the header comment of the file.
Our new approach is to leave the leading trivia of the first import
ahead of the resulting block of imports (i.e. it no longer follows the
first import as it is repositioned or deleted). Trailing trivia on the
first import and trivia on subsequent imports are treated as before.
There are times when the directory watcher for failed lookup locations isnt invoked and is not very determinitstic
So as a fallback, when we receive typeRoots watch event, handle failed lookup locations as well
* Track thisContainer for this-property-assignments in JS
Previously it would update on every block, not just those that could
bind `this`.
In addition, if the constructor symbol still can't be found, then no
binding happens. This is usually OK because people don't add new
properties in methods too often.
* Update additional baselines
* Add lib:dom to new test
* Address PR comments
* Correct new name for saveThisParentContainer
* Add test case and temporarily disable inference
(Inference of class members from this-assignments inside a
prototype-assigned function.)
* Update baselines
* In blocks and source files, bind functions first
* Add tests from other bugs
* Remove temporary failsafe
* Update tests to restore intent and clean up errors
* Restore intent even better
* Restore intent even better x2
* Add missed baselines
* 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
