* First draft
Solves the initial problem but breaks commentCommentParsing. I also
found a couple more interesting cases.
* Add more tests and fix their bugs
* Another test case
* Some cleanup
I may try do a little more; `margin += tag.end - tag.pos` bothers me a
bit.
* More cleanup
* Use const contexts and tuple mapped types to simplify some explicitly elucidated types
* Fix lint
* Further cleanup - refactor mapped type into its own alias for readability
* Slightly more cleanup - PragmaPsuedoMap neednt be partial, thus removing tons of nonull assertions
* Remove GH#18217 comments
* Skip asterisks after newline when parsing JSDoc types
* Single boolean expression
* Test for parsing and printing multiline function signatures with *
* Allow type predicates
1. Parse type predicates. Note that they are parsed everywhere, and get
the appropriate error when used places besides a return type.
2. When creating a type predicate, correctly find the function's parameters
starting from the jsdoc return type.
* Fix type of TypePredicateNode.parent: add JSDocTypeExpression
* Update API baselines
* Handle JSDoc signature inside @type annotations
* Fix circularity when getting type predicates
Also move createTypePredicateFromTypePredicateNode closer to its use
* More cleanup based on review comments
* Support the JSDoc @enum tag
`@enum` is used on a variable declaration with an object literal
initializer. It does a number of things:
1. The object literal has a closed set of properties, unlike other
object literals in Javascript.
2. The variable's name is resolvable as a type, but it just has the
declared type of the enum tag.
3. Each property's type must be assignable to the enum tag's declared type,
which can be any type.
For example,
```js
/** @enum {string} */
const Target = {
START: "START",
END: "END",
MISTAKE: 0, // error 'number' is not assignable to 'string' -- see (3)
}
Target.THIS_IS_AN_ERROR; // See (1)
/** @type {Target} See (2) */
var target = Target.START;
```
* Fix lint, add new test case, update API baselines
* Fix parsing of parenthesized JSDoc parameters
Parenthesis can start a jsdoc function parameter since it is just a
type, and parenthesis can start a type:
```js
/** @type {function(((string))): void} */
```
However, this is not legal in other parameter lists:
```ts
function x((((a))): string) { }
```
This change makes jsdoc function parameter lists parse differently than
normal parameter lists by allowing parenthesis as a start character of
jsdoc parameters.
* Parse nested uses of jsdoc function types
* Fix test
* navigateTo: Collect results from all referenced projects.
* Don't use project references, just source maps
* Move more code to session
* Test when implementation file is deleted
* Use tsserver tests instead of fourslash tests to ensure session is used
* Support find-all-references
* Restore fourslash tests
* Update emit baselines (added missing newline)
* Support rename
* @weswigham code review
* Don't open/close files
* Avoid growing `toDo` too eagerly
* @sheetalkamat code review
* Also get symlinked projects for originalLocation
* Update API (#24966)
* More @sheetalkamat code review
* Remove unnecessary test
* Update API (#24966)
Andrew
Anders Hejlsberg
Nathan Shively-Sanders
Andrew Branch
Wesley Wigham
Andrew Branch
Wenlu Wang
Sheetal Nandi
Klaus Meinhardt
Andy
Caleb Sander
Ryan Cavanaugh
Tim Schaub
Tim Schaub
Matt McCutchen