-
Notifications
You must be signed in to change notification settings - Fork 656
LosslessTreeSinker attaching trivia to tokens #1801
Conversation
Deploying with
|
Latest commit: |
f7406ca
|
Status: | ✅ Deploy successful! |
Preview URL: | https://7fe15397.tools-8rn.pages.dev |
Test262 comparison coverage results on ubuntu-latest
|
Test262 comparison coverage results on windows-latest
|
crates/rslint_parser/test_data/inline/err/async_arrow_expr_await_parameter.rast
Outdated
Show resolved
Hide resolved
Can we delete these now? tools/crates/rslint_parser/src/ast/generated/tokens.rs Lines 9 to 49 in cbeeaaf
|
crates/rslint_parser/test_data/inline/err/binary_expressions_err.rast
Outdated
Show resolved
Hide resolved
I think we can. I will create another PR to clean everything we don't need anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really love this change, excellent work!
There are two last things that I think we should improve before moving forward.
Debug Format:
I find it a bit misleading. It looks as if an identifier was parsed as foo
or keywords/punctuations as \n!
.
Would it make sense to format the trivia more explicitly, for example
[email protected] text: (trivia) (text="foo") (trivia whitespace: " ")
Swift actually prints tokens more like nodes since they now can contain rather bulky content like comments
[email protected]
(trivia newline "\n")
(trivia whitespace " ")
(text: "foo")
(trivia whitespace: " ")
Printing the trivia pieces one by one has the benefit that changes to the trivia parsing are tested as well. In that spirit. Would you mind adding an integration test for some trivia (single line comment, mutliline comment etc.)
EOF
I believe we shoulnd't append the EOF token conditionally, only when needed. Authors would see, oh, there's an EOF token I can test for and then bum, it isn't there in some cases.
We should also make it clear where EOF tokens can appear in our grammar. I think it's sufficient to add it to the JsRoot
rule for now. We can figure out the parse_text
use case later (probably best to introduce a "fake" node for parsed text.
if self.needs_eof && !self.next_token_leading_trivia.1.is_empty() { | ||
self.do_token(SyntaxKind::EOF, 0.into()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand this correctly that the sink will insert the EOF only if there was no EOF event coming from the parser? So all files will always have an EOF token?
We need to make sure to update our grammar to reflect this (another reason why I believe it shouldn't be conditional). Can you add the EOF
to the JsRoot
for now. We need to think through what that means when we parse expressions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am forcing a EOF at the tree sink for now. This way is easier and we never loose the last trivia of the file.
[email protected] "foo" | ||
[email protected] " " | ||
[email protected] | ||
[email protected] "foo " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This format is a bit misleading. It reads as if the identifier name is foo
(with trailing space). Would it make sense to format the trivia more explicitly, for example
[email protected] text: (trivia) (text="foo") (trivia whitespace: " ")
Printing the trivia pieces one by one has the benefit that changes to the trivia parsing are tested as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about now?
[email protected]
[email protected] "let" [Comments("/**/")] [Whitespace(" ")]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me. It might be helpful to be a bit more descriptive, especially because the leading/text are now out of order
[email protected] "let" (leading: COMMENTS("/**/")) (trailing: WHITESPACE(" "))
I would be OK not printing the trivia if it's empty.
Anyhow, that's more my personal taste now.
[email protected] "foo " | ||
[email protected] ": " | ||
[email protected] | ||
[email protected] "bar\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we see the EOF
token as part of the test files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and now you can see.
ff20f0a
to
6fecb78
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Can we remove the hidden
from EOF
.
tools/crates/rslint_syntax/src/generated.rs
Lines 11 to 12 in 8adc8b5
#[doc(hidden)] | |
EOF, |
As this is now a public visible token.
part of: #1720
Improved changes of #1738
Tasks
I also needed to make some formatter changes.
SynyaxNode
with error. Seeif_stmt_err.js