-
Notifications
You must be signed in to change notification settings - Fork 889
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
apply 2024 version sort algorithm to mods #6368
apply 2024 version sort algorithm to mods #6368
Conversation
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.
To make the old behavior easier to grep for I think we should change < StyleEdition::Edition2024
to <= StyleEdition::Edition2021
What makes you think that's easier to grep? I feel like that's bordering on a "glass half full vs half empty" and it would really depend on the author, but regardless, I think that anyone that wants to have a high degree of confidence that they've found all the locations of a behavior split between two style editions is going to have to search for all the (i.e. even if we try to be diligent about consistently applying one vs. the other, I don't think we can or should safely assume that a singular search 100% identified all such cases) to be clear I'm not opposed to one vs. the other, I just don't know if this is something we should block on |
Just to be clear, I don't think we'd need to block on that, though that's currently how the If you run
Conversely, if you run
|
Right, but my point is regardless of it being what we do currently, and even if we are consistent with that through the shipping of 2024 and never make any other 2021 <=> 2024 gated changes, if someone in the future finds themselves trying to find those gated changes (even if it's the two of us) I think it's highly unlikely we will remember the less than/greater than/etc. mechanism that was used and still end up having to search for all possible combinations. I think if search-ability and consistency are something we really care about here, then we will need a much more structured way of doing that. We can't just hope/rely on unenforced historical consistency at code authorship time |
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.
Totally agree with the points you're making. I don't have any suggestions for a more structured approach to this. Just wanted to highlight this while I still remembered. Feel free to merge this as is.
eeba92f
to
d8079a6
Compare
This closes the loop on all the implementation work for rust-lang/rust#123800 by applying the 2024 version sorting algorithm to mod declarations.
In practice I feel like this will functionally be nearly a no-op with zero-minimal diff on codebases when applied due to mod naming conventions, but the algorithm is required per the style guide.
The diff of this PR is exceptionally minimal in reality, I just went overboard with tests since the
reorder_modules
option is a stable option, and added a lot of emptymod.rs
filesr? @ytmimi