-
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
Clean up more comments near use declarations #126776
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -120,7 +120,6 @@ use types::*; | |
use unit_bindings::*; | ||
use unused::*; | ||
|
||
/// Useful for other parts of the compiler / Clippy. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This does seem like a valuable comment being lost. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I disagree. That exact comment could be attached to many re-exports. Why would you re-export something if not because it's useful elsewhere in the compiler or other tools? |
||
pub use builtin::{MissingDoc, SoftLints}; | ||
pub use context::{CheckLintNameResult, FindLintError, LintStore}; | ||
pub use context::{EarlyContext, LateContext, LintContext}; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,19 @@ | ||
#![unstable(feature = "unicode_internals", issue = "none")] | ||
#![allow(missing_docs)] | ||
|
||
// The `pub use` ones are for use in alloc, and are not re-exported in std. | ||
|
||
pub(crate) use unicode_data::alphabetic::lookup as Alphabetic; | ||
pub use unicode_data::case_ignorable::lookup as Case_Ignorable; | ||
pub use unicode_data::cased::lookup as Cased; | ||
pub(crate) use unicode_data::cc::lookup as Cc; | ||
pub use unicode_data::conversions; | ||
pub(crate) use unicode_data::grapheme_extend::lookup as Grapheme_Extend; | ||
pub(crate) use unicode_data::lowercase::lookup as Lowercase; | ||
pub(crate) use unicode_data::n::lookup as N; | ||
pub(crate) use unicode_data::uppercase::lookup as Uppercase; | ||
pub(crate) use unicode_data::white_space::lookup as White_Space; | ||
Comment on lines
+4
to
+15
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm. Is it not possible to separate these between the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, rustfmt doesn't consider the visibility when grouping and ordering. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, it is a requested feature, it seems: rust-lang/rustfmt#5083 (comment) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update: I discovered you can use |
||
|
||
pub(crate) mod printable; | ||
mod unicode_data; | ||
|
||
|
@@ -16,16 +29,3 @@ mod unicode_data; | |
/// [Unicode 11.0 or later, Section 3.1 Versions of the Unicode Standard](https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf#page=4). | ||
#[stable(feature = "unicode_version", since = "1.45.0")] | ||
pub const UNICODE_VERSION: (u8, u8, u8) = unicode_data::UNICODE_VERSION; | ||
|
||
// For use in alloc, not re-exported in std. | ||
pub use unicode_data::{ | ||
case_ignorable::lookup as Case_Ignorable, cased::lookup as Cased, conversions, | ||
}; | ||
|
||
pub(crate) use unicode_data::alphabetic::lookup as Alphabetic; | ||
pub(crate) use unicode_data::cc::lookup as Cc; | ||
pub(crate) use unicode_data::grapheme_extend::lookup as Grapheme_Extend; | ||
pub(crate) use unicode_data::lowercase::lookup as Lowercase; | ||
pub(crate) use unicode_data::n::lookup as N; | ||
pub(crate) use unicode_data::uppercase::lookup as Uppercase; | ||
pub(crate) use unicode_data::white_space::lookup as White_Space; |
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.
Why does this comment have to go? Can't we have separate import blocks separated by comments any more?
It's not a super important comment, but being able to apply custom grouping via comments seems quite valuable so it would be concerning for rustfmt to just flat-out ignore that. Previously on Zulip it was said that rustmft would only regroup within a contiguous sequence of
use
statements, which led me to believe it wouldn't regroup across comments 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.
Depends what you mean by "contiguous sequence". Blank lines and comments don't act as separators between use statements. Other items (e.g.
mod
, type declarations) do.And "for the validation errors" seems like a low-value comment to me.
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.
For blank lines that makes sense since the entire point is for rustfmt to do the grouping. But for comments I find this highly disruptive.
As a maintainer and one of the main authors of this file, I disagree. The imports that carry this comment are unusual, usually we'd not have
*
imports of an enum at a global level, noras
aliases. So it's worth explaining why we do something strange like that.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 find it rather concerning that we should entirely lose the ability to add a comment to a group of
use
statements. The standard library also has several of these cases show up in this PR, where comments that are helpful to structure the file are now being erased because we have a tool that can't deal with them. That's a bad reason to remove comments from code.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 could take or leave this particular comment, but I do agree that commented groups are useful and would be a shame to lose. Is there any rustfmt setting we can use (or request) to keep that ability?
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.
No. rustfmt will, with
group_imports = "StdExternalCrate"
, put all theuse
declarations into three sections, with a single blank line between them. The whole concept of a single comment applying to multiple lines is suspect within this model. That's the whole point of the first commit in this PR, to get rid of such comments.The example in question looks like this:
After reformatting, it looks like this:
The comment sticks to the
use super::InterpError::UndefinedBehavior as Ub;
line, which is a reasonable choice and would be fine if the comment only applied to that line. But rustfmt can't know that it actually applies to four lines. (That fact isn't even perfectly clear to a human reader.) Maybe you could argue that the blank line before the comment should make it clear. But the formatting will be getting rid of unnecessary blank lines. Maybe you could argue that a blank line followed by a comment should be interpreted as the comment applying to multiple lines. Perhaps? But at this point it's worth mentioning that the number of comments on use items in the codebase is actually really small, and the number of comments that apply to multiple use items is even smaller. This PR deals with all of them. It's a couple of dozen comments out of many thousands of use items.In summary, rustfmt does just fine with like 99.99% of cases and for 0.01% of cases we have a slightly suboptimal experience. It's a standard autoformatting trade-off: we accept the small number of suboptimal cases for all the other benefits, such as consistency and not having to make decisions about how to style things. For this particular case, I could do something like this:
which is totally unambiguous, more so than the original comment.
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 think having a group of code with empty lines before and after it, and a comment at the top of it, makes it fairly clear to a human reader that the comment applies to the entire group. But rustfmt is frequently bad at dealing with comments and likes to move them around in ways that change their meaning (rust-lang/rustfmt#3255, rust-lang/rustfmt#3994, rust-lang/rustfmt#5485), so it is no surprise that this happens here, too. It is a constant frustration of mine that issues like that are ignored in the name of the Grand Goal Of Consistency. For basic rustfmt formatting the advantages it provides are so big that the overall tradeoff still comes out in favor of rustfmt (though it is unfortunate that fixing these rustfmt issues is nobody's priority), but for
use
statements I am not convinced that there's a significant enough problem here worth solving.That "one in 10000" number is complete guesswork on your end. A couple dozen cases in around 3k source files also shows that you are off by around 2 orders of magnitude.
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.
There are something like 18,000 use items in
compiler/
andlibrary/
alone. Maybe the correct number is 99.9% or 99.5%. No matter what the exact number is, we're having an argument about suboptimal handling of one or two actual comments in the entire codebase. Is that worth blocking this entire change from happening? In my opinion, no.