Switches the error message emitted by the parser to the more specific _"An enum member name must be followed by a ',' or '='."_ when the expected comma doesn't follow the member.
* Incrementally parse unchanged ambient declarations
* Re-parse modifiers and decorators so as not to skip errors
* Revert unnecessary change
* Undo the test change that was changed 2 years ago
* Add error message for keywords with escapes in them
* Move check into parser during advance to next token to utilize context for contextual keywords
* git add .
* Add tests for extended escapes
* Better error courtesy of @DanielRossenwaser
* Add test of browser-inconsistent case and alter condition to match spec
* Merge adjacent conditions
* Use seperate functions for checking keywords vs not
* Use flags to track unicode escape presence
* Adjust error text
* Remove error on invalid jsdoc tokens
In JSDoc:
1. In the scanner, don't issue an error, even for invalid identifiers.
2. In the binder, don't issue an error for reserved (but otherwise valid)
identifiers.
/**
* Example of 1: "\"
* Example of 2: @private
*/
* Update baselines
* Add invalid unicode escape test for JSDoc
* Add quotes around invalid unicode escape
* Add another unicode escape JSDoc test
* Parse quoted constructors as constructors, not methods
* Update baselines
* Fix disambiguation between quoted constructor and property named constructor
* Clean up parsing a bit
* Support escapes in constructor name
* Update baselines
* 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
* 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
* Use const contexts and tuple mapped types to simplify some explicitly elucidated types
* Fix lint
* Further cleanup - refactor mapped type into its own alias for readability
* Slightly more cleanup - PragmaPsuedoMap neednt be partial, thus removing tons of nonull assertions
* Remove GH#18217 comments
Arpad Borsos
OrtaandGitHub
Josh Goldberg
Alexander T
Andrew BranchandGitHub
Ron BucktonandRyan Cavanaugh
Wesley WighamandGitHub
Nathan Shively-SandersandGitHub
Orta Therox
Andrew CaseyandGitHub
Michael Crane
Sheetal Nandi
Bill TicehurstandMichael Crane
Andrew Branch
Klaus MeinhardtandRon Buckton
Wesley WighamandGitHub
Peter Šándor
AndrewandRyan Cavanaugh
Anders HejlsbergandGitHub