Makes another test case pass that was taking exponential time to parse,
because now it notices that the = is not present and doesn't even try to
parse the initialiser expression.
Fail speculative parsing of arrow function expressions whenever it has a
parameter with an initialiser that is missing '='. Ordinarily this is
allowed for better error recovery in the language service, but for
speculative parsing, the errors can compound. When the initialiser is an
error, and when the '=>' is missing (which is also allowed), what is
putatively an arrow function may actually be something else.
For example, `(a / 8) + function ()
{ }` is currently parsed as if someone had intended to write
`(a = /8)+function()/) => { }` but they forgot the `=` of the
initialiser, the `=>` of the lambda, forgot to close the regular
expression, and mistakenly inserted a newline right after the regular
expression.
* Add typedef declaration space, unify typedef name gathering, strengthen errorUnusedLocal
* Bonus round: make jsdoc presence way mroe typesafe
* Be exhaustive in nameForNamelessJSDocTypedef
* Remove nonrequired casts
* Replace more casts with guards
* Cannot be internal
* Debug.fail returns never, assert never no longer needs unreachable throw to satisfy checker
* Rename type
* Add replacement message as in 18287
* Fix many no-object-literal-type-assertion lint errors
* Simple fixes
* Use a union for FlowNode
* PR feedback and remove remaining `id()` uses
* Use a union for CodeBlock
* Discriminate CodeBlock by CodeBlockKind
* Fix#17383 - issue an error when jsdoc attempts to instantiate a builtin as a generic
* Fix comment
* Fix#17377 - only get type parameters from reference target if the type is a reference
* Fix#17525 - Add SyntaxKind.AsteriskToken to isStartOfType
* Add 'name' property to Identifier
* Rename to unescapedText
* Rename 'id.text' to 'id.escapedText'
* Rename 'id.unescapedText' to 'id.text'
* Make escapeIdentifier and unescapeIdentifier do nothing
Now Typescript supports the creation of anonymous types using successive
`@param` lines in JSDoc:
```js
/**
* @param {object} o - has a string and a number
* @param {string} o.s - the string
* @param {number} o.n - the number
*/
function f(o) { return o.s.length + o.n; }
```
This is equivalent to the Typescript syntax `{ s: string, n: number }`,
but it allows per-property documentation, even for types that only need
to be used in one place. (`@typedef` can be used for reusable types.)
If the type of the initial `@param` is `{object[]}`, then the resulting
type is an array of the specified anonymous type:
```js
/**
* @param {Object[]} os - has a string and a number
* @param {string} os[].s - the string
* @param {number} os[].n - the number
*/
function f(os) { return os[0].s; }
```
Finally, nested anonymous types can be created by nesting the pattern:
```js
/**
* @param {Object[]} os - has a string and a number
* @param {string} os[].s - the string
* @param {object} os[].nested - it's nested because of the object type
* @param {number} os[].nested.length - it's a number
*/
function f(os) { return os[0].nested.length; }
```
Implementation notes:
1. I refactored JSDocParameterTag and JSDocPropertyTag to
JSDocPropertyLikeTag and modified its parsing to be more succinct. These
changes make the overall change easier to read but are not strictly
required.
2. parseJSDocEntityName accepts postfix[] as in `os[].nested.length`,
but it doesn't check that usages are correct. Such checking would be
easy to add but tedious and low-value.
3. `@typedef` doesn't support nested `@property` tags, but does support
`object[]` types. This is mostly a practical decision, backed up by the
fact that usejsdoc.org doesn't document nested types for `@typedef`.
AndyandGitHub
Armando AguirreandGitHub
Nathan Shively-SandersandGitHub
Anders HejlsbergandGitHub
Wesley WighamandGitHub
Ron BucktonandGitHub
Daniel RosenwasserandGitHub
Tingan Ho
Wesley Wigham