-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Skip whitespace and asterisk in JSDoc param #26067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Which tests break without the first clause? I'd like to avoid lookahead whenever possible, but I don't know how essential it is here. (You can run the tests with |
|
Update - I pushed a new commit that passes all current tests. |
|
@sandersn without a lookahead, this sort of thing would be allowed: Update - The most recent commit avoids a lookahead, but treats the above syntax as invalid. More below. |
72ca595 to
8e10dfc
Compare
|
My take right now is that when parsing JSDoc comments, you generally want to skip whitespace or newline, whitespace, asterisk together. As things are now, after calling The The changes here parse this type of syntax: /**
* @param
* {string} x
* @param {string}
* y
*/
function f(x,y) {
}And these are invalid: /**
* @param {string} * x
* @param * {string} y
*/
function f(x,y) {
}If this looks like a good direction to go, I'll add tests. The sometimes-reliable preceding linebreak check also feels fragile - it is not correct after a call to |
174879a to
7f5c439
Compare
|
I added a conformance test. Since skipping newline + asterisk would be nice elsewhere, I'm wondering if alternative approaches have been considered - like grouping it into a single trivia token during scanning. Perhaps nobody has asked for it yet, but it would be nice to be able to have linebreaks in typedefs for example: /**
* @typedef {{
* x: number,
* y: number,
* z: number
* }} XYZ
*/I think this would be more straightforward if the newline + asterisk were treated just like a single newline token while parsing the type expression. Update: I see the linebreak in types issue is already ticked as #23667. |
|
The typedef problem is unfortunately much harder because it uses the normal Typescript parser, so you'd have to make type parsing skip arbitrary asterisks. I don't think asterisk is a common character in types, so it might work. |
|
Thanks for the fix @tschaub! |
Skip the newline, whitespace, asterisk combo while parsing param tags.
Fixes #26027