* 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
* add grammar check for labeled function declaration
* fix debug failed on labeled class declaration
* move labeled statement check to binder and add more pattern for check
* update diagnostic message
* update baseline
Keep emit flags set on the original node on a namespace or enum node.
This prevents dropping flags like NoComments, which caused duplicated
comment emits.
Additionally, TypeScript would emit synthetic comments twice, once for
the variable declaration, once for the module statement. This explicitly
clears away synthetic comments on namespaces and enums if their
synthetic comments have already been emitted on the corresponding
variable statement.
Previously, TypeScript would only set the text range when transforming
import and export declarations, leading it to drop synthetic comments
and emit flags.
This commit sets the original node on the statements that contains the
generated `require()` call (or similar, depending on module system),
retaining emit flags and synthetic comments.
Variables that do not have a local variable created get transformed into
a single exports assignment expression. TypeScript previously just
created a new expression and set the text range to retain original
comments, but for synthetic comments, merging the emit nodes by setting
the original node is required.
* Explicitly typed prototype assignments:ctx sensitive
Follow up to #25619: Add the necessary code to type `prototype`
correctly in prototype assignments so that code like
`F.prototype = { ... }` properly makes the object literal context
sensitive.
* Fix lint
* Explicitly typed js assignments: context sensitive
Explicitly typed special assignments should be context sensitive if they
have an explicit type tag. Previously no special assignments were
context sensitive because they are declarations, and in the common,
untyped, case we inspect the right side of the assignment to get the
type of the left side, and inspect the right side of the assignment to
get the type of the left side, etc etc.
Note that some special assignments still return `any` from
checkExpression, so still don't get the right type.
Fixes#25571
* Change prototype property handling+update bselines
* Fix indentation in test
* Update baselines
