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`.
This means that JSDoc types can include the full range of Typescript
types now. It also means that Typescript annotations can include JSDoc
types. This is disallowed with a new error, however. But Typescript can
still give the correct types to JSDoc that shows up in .ts files by
mistake. This can easily happen, for example with types like
```ts
var x: number? = null;
var y: ?string = null;
var z: function(string,string): string = (s,t) => s + t;
// less likely to show up, but still understood.
var ka: ? = 1;
```
In the future, I will add a quick fix to convert these into the correct
types.
Fixes#16550
It's very ambiguous in expression position, so impossible to give a
better message from the parser. For example:
let f = (x: number) => number => x + 1;
~~
Should be ':'
But the parser doesn't know that 'number' isn't an expression now.
* Created a branded type for escaped strings
Then flowed it throughout the compiler, finding and fixing a handful of
bugs relating to underscore-prefixed identifiers in the process.
Includes a test for two cases noticed - diagnostics from conflicting
symbols from export *'s, and enum with underscore prefixed member emit.
* Correctly double underscores WRT mapped types
* Add fourslash tests for other fixed issues
* use function call over cast
* Update forEachEntry type accuracy
* Just use escaped names for ActiveLabel
* Remove casts from getPropertyNameForPropertyNameNode
* This pattern has occurred a few times, could use a helper function.
* Remove duplicated helper
* Remove unneeded check, use helper
* Identifiers list is no longer escaped strings
* Extract repeated string-getting code into helper
* Rename type and associated functions
* Make getName() return UnderscoreEscapedString, add getUnescapedName()
* Add list of internal symbol names to escaped string type to cut back on casting
* Remove outdated comments
* Reassign interned values to nodes, just in case
* Swap to string enum
* Add deprecated aliases to escapeIdentifier and unescapeIdentifier
* Add temp var
* Remove unsafe casts
* Rename escaped string type as per @sandersn's suggestion, fix string enum usages
* Reorganize double underscore tests
* Remove jfreeman from TODO
* Remove unneeded parenthesis
Nathan Shively-Sanders
Anders HejlsbergandGitHub
Wesley WighamandGitHub
AndyandGitHub
Ron BucktonandGitHub
Daniel RosenwasserandGitHub
Tingan Ho
Wesley Wigham