-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add tidy-alphabetical-start/end around feature lists and, in some cases, allow/warn/deny lists #114766
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
The Miri subtree was changed cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in compiler/rustc_codegen_gcc cc @antoyo Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Portable SIMD is developed in its own repository. If possible, consider making this change to rust-lang/portable-simd instead. cc @calebzulawski, @programmerjake Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in src/tools/rust-analyzer cc @rust-lang/rust-analyzer This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino
cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in GUI tests. |
10ccf6e
to
7c1bec2
Compare
This comment has been minimized.
This comment has been minimized.
7c1bec2
to
1130ab4
Compare
1130ab4
to
eaaa89b
Compare
This comment has been minimized.
This comment has been minimized.
eaaa89b
to
1a23bd0
Compare
This comment has been minimized.
This comment has been minimized.
…es, allow/warn/deny lists
1a23bd0
to
2a752c2
Compare
This comment has been minimized.
This comment has been minimized.
#![warn(unreachable_pub)] | ||
#![warn(unused_lifetimes)] | ||
// tidy-alphabetical-end |
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.
Could you please skip this for cg_clif? There is nothing in place in https://github.com/bjorn3/rustc_codegen_cranelift to enforce this and because of this it will only cause issues when syncing between that repo and this repo.
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.
Same applies to rust-analyzer, I'd say this should not be done for subtrees in general.
// Note: please avoid adding other feature gates where possible | ||
#![feature(rustc_private)] |
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 comment was intentionally before the feature gate as you did likely add new feature gates after the last one, which is exactly where the comment is positioned.
#![warn(rust_2018_idioms)] | ||
// tidy-alphabetical-end | ||
// We are not implementing queries here so it's fine | ||
#![allow(rustc::potential_query_instability)] |
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 don't think it is a good idea to enforce this for code in subtrees. This code will be updated by PRs from Miri, where no tidy runs. Having tidy check this code will make syncing changes back to rustc harder.
src/tools/miri is already excluded from rustfmt checking in the rustc repo. Please also don't add other tidy checks here. (The same probably goes for clippy, but I am speaking as a miri maintainer here.)
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.
Just want to add that I strongly agree with Ralf here that subtrees should be excluded, and I wouldn't want this enforced on the rustfmt source via tidy either
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, this shouldn't be enforced in clippy either. I'm not opposed to enforcing this in specific, I think forcing them to be alphabetical is a fine idea, but it's that tidy is never ran outside of rustc and this shouldn't be enforced from the rustc side.
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--I don't really have anything more to add, but we have no mechanism for enforcing this in std::simd and it will probably make syncing difficult.
Isn't it better to have rustfmt sort features? Doing that manually not fun. |
However the error should really say that, since I totally did not expect that either. |
@@ -1,4 +1,7 @@ | |||
#![feature(no_core, lang_items)] | |||
// tidy-alphabetical-start |
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 don't think we need to enforce this on a test file.
@@ -8,7 +11,7 @@ | |||
trait Sized {} | |||
|
|||
#[link(name = "extern_1", kind = "raw-dylib")] | |||
extern { | |||
extern "C" { |
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 the extraneous formatting-related changes should be removed from this and the other files below.
// tidy-alphabetical-start | ||
#![allow(unused_features)] | ||
#![cfg_attr(not(bootstrap), allow(internal_features))] | ||
#![feature(profiler_runtime)] | ||
#![feature(staged_api)] | ||
// tidy-alphabetical-end |
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.
It feels somewhat arbitrary what lists are mixing allow
/deny
+ feature
and what lists are sorting them separately.
I think that this PR should be broken up between compiler / library / other tools. There's no reason to do it all at once imo, and it means that all these nits above wouldn't be blocking landing fully separable parts (e.g. changes to |
☔ The latest upstream changes (presumably #114786) made this pull request unmergeable. Please resolve the merge conflicts. |
HELLO. |
Okay, so, after causing a giant mess and alerting everyone, I'm going to just close this for now. I made sure I excluded submodules, but with the presence of subtrees in the code, it's very difficult to track what is "internal code" and what isn't. So, I'm going to try and take a stab at this later with a much smaller scope, and figure out how I can sift out subtrees too. Apologies for the excess of notifications, which… in hindsight I should have expected that, but I somehow didn't. |
Problem
A lot of crates in the code include a large header with feature flags and lint overrides sorted in no particular order. The
tidy-alphabetical-start
andtidy-alphabetical-end
flags for tidy were added to solve this problem, and they're used in some key places like thestd
cratelib.rs
file. However, most of the crates in the code do not use this. Because sorting is not enforced, merge conflicts are common because every feature is usually just appended to the end of the list, and these changes often happen concurrently.Solution
I used a command to narrow down the scope of my search to just
lib.rs
files without atidy-alphabetical-
comment anywhere in the file. (usingfish
,kakoune
, andripgrep
)$ kak (rg -F '#![feature' --files-with-matches --glob '**/lib.rs' | xargs rg -F 'tidy-alphabetical-' --files-without-match)
In these files, I added flags based upon the following heuristic:
tidy-alphabetical
tags were added around feature lists more than one feature in size, and if there were any lint overrides, I often included those in this central list as well. This has the side-effect of splitting up lint overrides between feature flags if they include bothallow
ordeny
andwarn
attributes, so, I made two lists in those cases (and sometimes more).cfg_attr
-based feature flags were left out of this list, both because the sorting would be mostly meaningless for these (depending on the condition, not the feature) in addition to the fact that they're likely to have comments nearby explaining why the flags are conditional.Is this a perfect solution? No. However, it's something I could both apply in a reasonable amount of time, could be reviewed in an easy amount of time, and could be tweaked in the future without causing too much disruption. I suspect that this PR will create a large amount of merge conflicts immediately after it's merged, but it will help reduce merge conflicts going forward.
IMHO, any aesthetic tweaks can be added on a case-by-case basis, and doing so will most likely still limit the scope of merge conflicts since the contents of the list will be already sorted and thus easy to move around in a single unit. Additionally, anyone reviewing changes made to these files would help ensure that features and lints are grouped together anyway, limiting the chance of the problem reappearing in the future.
Prior Art
I did this large, sweeping change after I did a rather localised version in #113295 for libcore tests.
I have also undertaken multiple large refactoring projects unprompted in the past (see: #42523, #56932) that were mostly well-received, but I still feel the need to apologise for dropping such a large, sudden change on reviewers without much notice. I suggest using the GitHub UI to hide files that you've reviewed so you can make sure that you both actually look at all the changes, and don't miss anything.
Final notes
I am definitely willing to help out with merge conflicts until this is merged, but would strongly prefer it being merged sooner rather than later due to the extremely high chance of merge conflicts. My goal is not to create a perfect solution, as I stated, but to objectively and immediately improve the situation first before any aesthetic improvements.
If you have any particular files you feel strongly should be removed from the list of changes, or if you have any suggestions for additions, please feel free to mention them, but beyond simply removing files from this list, additional changes will likely be done in a separate PR.