* Scan backticks in jsdoc as a single token less often
Previously, matching backticks in jsdoc would always be scanned as one
token to aid parsing incorrect jsdoc that uses backticks for parameter
names:
``js
/** @param {string} `nope`
* @param {number} `not needed`
*/
```
However, this is wrong for code fences, which use triple backticks. This
fix parses a single backtick as a single token if it's immediately
followed by another backtick or by a newline. It retains the
questionable tokenisation of backticks-as-pairs in other cases, however.
A better fix might be to have the parser ignore backticks in jsdoc
instead.
* Add test case
* Handle jsdoc backticks in the parser, not scanner
Previously, the jsdoc scanner had ad-hoc handling of backticks that was
similar in structure to the normal scanner's handling, but much simpler.
This was a smaller code change, but is handled backwards: the special
case of backtick-quoted parameter names was handled in the scanner
instead of in the jsdoc identifier parsing code. That made it overapply
and block correct handling of asterisks across newlines, which was most
obvious in code fences inside jsdoc, as in #23517.
Fixes#23517
* More cleanup
* Perform excess property checking on intersection and union members
* Allow partial union props to contain the undefined type
* Add test case from #30771
* Un-terse getPossiblePropertiesOfUnionType side-effecting code
* Fix bug exposed in RWC
* Cache results of getPossiblePropertiesOfUnionType
* Fix whitespace
* 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
Even if (1) @extends is provided and (2) we're not producing
diagnostics. That's because we need to know whether the extends clause
references an imported alias.
* Added error for class properties used within their own declaration
Fixes#5987.
Usages of a class property in a preceding property already gave an error, but the following doesn't yet:
```ts
class Test {
x: number = this.x;
}
```
As with other use-before-declare checking, IIFEs are not treated as invalid uses.
* Accepted 'witness' baselines; removed unnecessary !==
* Addressed quick feedback items
* Accepted odd new baseline
* Fixed post-merge introduced lint errors
* Updated baselines again
* Change the default type parameter constraint and default to unknown from {}
* Relax unknown checking outside of strictNullChecks a bit
* Increase strictness on index signatures with type `unknown` so inference doesnt change surprisingly
* Remove redundant switch
