staging: add workspace-wide rustfmt lints #552
Conversation
epilys
requested review from
stsquad,
vireshk and
stefano-garzarella
as code owners
|
Making this into a draft PR since CI lacks rustfmt on nightly toolchain |
staging/rustfmt.toml
Outdated
| # Reorder import and extern crate statements alphabetically in groups (a group is separated by a newline). (default value) | ||
| reorder_imports = true | ||
| # Reorder mod declarations alphabetically in group. (default value) | ||
| reorder_modules = true |
There was a problem hiding this comment.
Do we set these to default values? Any reason why we set them at all then? I think we probably want to follow the overall Rust defaults but only tweak a few options that we find useful?
There was a problem hiding this comment.
I thought to include them in case the defaults change. They are not unreasonable to have and sometimes rust rolls back on choices. Is it that bad, you think?
There was a problem hiding this comment.
I am just worried that nobody will ever review the delta that we got compared to Rust default. Then we are left with code laws that only exist because they happened to be default at some point. IMHO saying "we track Rust defaults, expect these few stricter rules" keeps our rule set simpler.
There was a problem hiding this comment.
Yes you're right. We're not able to easily see changes against current defaults so it can confusing. I'll remove them
There was a problem hiding this comment.
The convention I tend to see is the defaults are described but commented out.
.buildkite/custom-tests.json
Outdated
| @@ -20,7 +20,7 @@ | |||
| }, | |||
| { | |||
| "test_name": "staging: style", | |||
| "command": "cd staging && cargo fmt --all -- --check --config format_code_in_doc_comments=true" | |||
| "command": "cd staging && cargo +nightly fmt --all -- --config-path rustfmt.toml --check" | |||
There was a problem hiding this comment.
Should we maybe ping the nightly version number down to prevent a nightly update breaking CI? Or does that already happen elsewhere?
Would it make sense to add an overview of which of the format options are nightly only? Eventually, we would probably want to drop the nightly dependency, right?
There was a problem hiding this comment.
I also suggest to leave custom-tests.json as much as possible equal to the one used out of staging (maybe we should change the name).
So my suggestion is to add another file with change, where we can also run it on no-staging crates. WDYT?
There was a problem hiding this comment.
Yes we do want to drop it, I am not familiar with how rustfmt rules get stable though. What would be the best approach you think?
There was a problem hiding this comment.
@stefano-garzarella a separate .json file with just the nightly fmt? is that possible?
There was a problem hiding this comment.
I think so, I just need to update buildkite with that file.
Should we also run the same on no-staging crates?
There was a problem hiding this comment.
If we add that commit to
.git-blame-ignore-revsfile, what could be other issues?(Anyway, for now I'm fine to enable it only for staging)
None, just the amount of lines to review at once. Sometimes rustfmt has bugs and we should be on the lookout in general.
There was a problem hiding this comment.
My approach would be to gradually lift these rules everywhere. For example it was in
soundonly at first. Now it'sstaging. Then the root workspace in a follow up PR.
Yep, I agree on that!
I'll send a PR to change custom-tests.json to staging-tests.json with a comment to explain that we want to leave it aligned with the rust-vmm-ci tests.
There was a problem hiding this comment.
If we add that commit to
.git-blame-ignore-revsfile, what could be other issues?
I think that file is still opt-in, or did something change?
There was a problem hiding this comment.
We can do one commit per rule in root crates then, and at the end add the rustfmt.toml file for all crates. What do you think?
Yep, I agree on that. 1 commit per rule with the parameters described in the commit description.
There was a problem hiding this comment.
We can do one commit per rule in root crates then, and at the end add the rustfmt.toml file for all crates. What do you think?
Sounds good to me. Except, I would probably add the rules in some rust-vmm wide manner.
|
Ah, sorry. I missed that this is for staging only... So maybe my comments were overly strict... |
There's no reason to use 2018, 2021 is the default nowadays. Switch the versions in the rustfmt files of sound and video while at it. Signed-off-by: Manos Pitsidianakis <[email protected]>
Both staging crates had the same rustfmt.toml file, let's make it workspace default. Signed-off-by: Manos Pitsidianakis <[email protected]>
Add a new test json file with a cargo-fmt check with the nightly toolchain. This allows to use nightly rustfmt rules in rustfmt.toml. Signed-off-by: Manos Pitsidianakis <[email protected]>
Add doc comments for each rule and a bunch of new rules. Signed-off-by: Manos Pitsidianakis <[email protected]>
Signed-off-by: Manos Pitsidianakis <[email protected]>
Add previous formatting commit SHA to .git-blame-ignore-revs The filename does not seem to be standardised, but must be configured explicitly. Note: to use this file always, you must set: git config --local blame.ignoreRevsFile .git-blame-ignore-revs (or --global) or use git blame with `--ignore-revs-file .git-blame-ignore-revs` Signed-off-by: Manos Pitsidianakis <[email protected]>
Summary of the PR
Closes #488
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s), and the commitmessage has max 60 characters for the summary and max 75 characters for each
description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafecode is properly documented.