[Merged by Bors] - Adds rustfmt configs to wrap and limit comment width#1603
[Merged by Bors] - Adds rustfmt configs to wrap and limit comment width#1603mnmaita wants to merge 2 commits intobevyengine:mainfrom
Conversation
These options are unstable and depend on the following PR's: rust-lang/rustfmt#3347 rust-lang/rustfmt#3349
|
This should work, especially as the situation around #1309 improves :) Yes please to |
alice-i-cecile
added
A-Build-System
Check rust-lang/rustfmt#3350 to track stabilization of this option.
alice-i-cecile
added
the
S-Ready-For-Final-Review
|
The output looks good to me. Im sold |
|
bors r+ |
Aims to close #1594. These options are unstable and depend on the following PR's: [wrap_comments](https://rust-lang.github.io/rustfmt/?version=v1.4.36&search=#wrap_comments): rust-lang/rustfmt#3347 [comment_width](https://rust-lang.github.io/rustfmt/?version=v1.4.36&search=#comment_width): rust-lang/rustfmt#3349 [normalize_comments](https://rust-lang.github.io/rustfmt/?version=v1.4.36&search=#normalize_comments): rust-lang/rustfmt#3350 @alice-i-cecile do you think this will solve the issue? When enabled, running the formatter locally should take the configurations into account to format comments. `--check` runs should also be considering them. This should be testable on the `nightly` toolchain. ~I didn't delve into normalizing `//` vs `/* */` though, should I take a look into that too? [normalize_comments](https://rust-lang.github.io/rustfmt/?version=v1.4.36&search=#normalize_comments) seems to be the solution for that but it's also unstable (tracking issue: rust-lang/rustfmt#3350). I can also add this configuration (commented out, of course) if it's desirable.~ Added `normalize_comments` option.
|
Pull request successfully merged into main. Build succeeded: |
bors
bot
changed the title
|
I think this might not be accounting for indentation? See #1647, the doc on new methods has a line that's just long enough to fit without indentation, and CI passes. |
|
CI doesn't run the new checks at all (note that they are "unstable" features and are commented out). |
|
I'm planning on using them like I currently use the "merge imports" setting. Its "nice to have" and I'll run it periodically, but its not enforced. |
|
... oh, I completely missed that. I guess I was confused by the relevant issue getting closed. |
|
Ah yeah we should probably leave it open until it stabilizes (or we move to nightly formatting). |
4 participants
Aims to close #1594.
These options are unstable and depend on the following PR's:
wrap_comments: rust-lang/rustfmt#3347
comment_width: rust-lang/rustfmt#3349
normalize_comments: rust-lang/rustfmt#3350
@alice-i-cecile do you think this will solve the issue? When enabled, running the formatter locally should take the configurations into account to format comments.
--checkruns should also be considering them. This should be testable on thenightlytoolchain.I didn't delve into normalizingAdded//vs/* */though, should I take a look into that too? normalize_comments seems to be the solution for that but it's also unstable (tracking issue: rust-lang/rustfmt#3350). I can also add this configuration (commented out, of course) if it's desirable.normalize_commentsoption.