-
Notifications
You must be signed in to change notification settings - Fork 656
fix(rome_js_formatter): don't add spaces to comments #2515
Conversation
let next_piece = pieces.peek(); | ||
let leading_trivia = if let Some(previous_piece) = previous_piece { | ||
if previous_piece.is_whitespace() { | ||
space_token() |
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 thinking that maybe we can do another optimisation here, where we create a new token out of the trivia, by keeping the same text.
It would an optimization similar to what Micha did recently. This would work only for comments, as they are the only ones that contain actual strings.
Parser conformance results on ubuntu-latestjs/262
jsx/babel
ts/babel
ts/microsoft
|
Deploying with
|
Latest commit: |
8c01cb4
|
Status: | ✅ Deploy successful! |
Preview URL: | https://586b3e9a.tools-8rn.pages.dev |
!bench_formatter |
Formatter Benchmark Results
|
|
||
let mut pieces = pieces.peekable(); | ||
|
||
while let Some(piece) = pieces.next() { |
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.
If I'm reading this correctly, we should be checking for the pieces that are not comments to see if they are whitespace and changing has_seen_whitespace
to true, no? Because currently we do not print a space when there's a line of code followed by a space then a single line comment: Playground
empty_element() | ||
}; | ||
|
||
let trailing_trivia = if next_piece.map_or(false, SyntaxTriviaPiece::is_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.
We don't always want to print a space if the next trivia piece is whitespace. For instance if we have foo( /* bar */ )
, this should be formatted as foo(/* bar */)
: Playground
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 hoped this could have been consistent but it seems that the spacing of the comments depends on where they are placed.. meaning in which nodes they are.
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.
Yes, the formatting is specific to what the previous/next token is. See the related issue, I outlined the rules.
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'm currently looking into how we should format comments. I do like this implementation but believe that we should instead test if the next/previous token is a punctuation token and, if so, not insert a space. I haven't yet figured out how to do this best in here with skipped token trivia but I'm honestly inclined to just bail out formatting for skipped token trivia
Prettier categories comments as:
And Prettier has an extensive rules on when it diverges from these simple rules |
I'm closing this PR because #2701 implements the spacing before/after inline comments based on the previous/next token. |
Summary
Fixes #2447
No big changes in this one, I had to make the iterator a
peekable
as it needs to check if there's a trailing trivia and keep the whitespace in that case.Test Plan
Added two test cases that cover the cases we want to fix