* Always generate type & symbol baselines
* Accept changed shadowed baselines
* Accept brand new type and symbol baselines
* Allow `getTypeAtLocation` to return undefined in the type writer
* Accept baselines which had missing type information
* Bind container for dynamically names enum members so they may be printed
* Accept type/symbol baselines for enums with computed members
* First pass at reducing typeWriter memory overhead
* Use generators to allow for type and symbol baselines with no cache
* Accept new baselines for tests whose output was fixed by better newline splitting
* Hard cap on number of declarations printed, cache declaration print text
* handle differing newlines better still to handle RWC newlines
* Lower abridging count, accept abridged baselines
* Limit max RWC error output size, limit RWC type and symbol baseline input size
* Move skip logic into type and symbol baseliner to streamline error handling
* Accept removal of empty baselines
* Canonicalize path earlier to handle odd paths in input files
* Do canonicalization earlier still, also ensure parallel perf profiles for different targets do not trample one another
* No need to pathify again
* 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
* 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`.
* Fix#17023
* Be more general when handling matching references through binding elements
* Better cache key, PR feedback
* Deeper tests, better cache key handling
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
* 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
