Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
avoid inserting newline between opening curly brace and comment #6265
base: master
Are you sure you want to change the base?
avoid inserting newline between opening curly brace and comment #6265
Changes from 1 commit
25c2382
c2fe0d8
8595fbb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
SO there's no way to adjust the
shape
that we pass torewrite_comment
to tell it how much space it actually has available?How does it usually know how much space it has (e.g. to account for indentation)? I would have thought it looks at the cursor position in the current line in the output, which should always be reliable, but that doesn't seem to be the case.
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.
The original PR did
self.last_pos + BytePos(first_line_snip.len() as u32)
here. That led to a bunch of test failures where rustfmt inserts seemingly random characters into previously empty blocks. I think what happens is that if thetrim()
above removes characters from the start of the string, we'd advancelast_pos
by too little here, and so the cursor doesn't quite point to the end of the comment -- so the last characters of the comment get duplicated.I'm not sure what the proper fix for that is. Skipping to the end of the line seemed to make most sense, since we should have processed the entire line.
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.
Probably good to add a test case with a multi-line block comment that doesn't have bare lines. Something like this for example:
I noticed that the indentation of the first line was the only one that got updated. Maybe the other's should have as well since they're part of the same block comment? I imagine that might be tougher to get right though. This is the output that I'm currently getting when formatting with this branch:
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.
Yeah, the entire approach is based on processing just the code from the
{
to the end of the line, so it doesn't take into account the other lines at all. I have no idea how to fix this.The alternative originally implemented by #4745 was to not touch
/*
-style comments at all, but that does not seem better: the result looks nicer but is more likely to change the semantic meaning of the comment.