-
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
[WIP] Massive cosmetic PR, take 2 #58036
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
I'm going to put WIP in the title to reflect that this is "a 'tracking PR' for now" that shoud not be merged as is. |
☔ The latest upstream changes (presumably #57916) made this pull request unmergeable. Please resolve the merge conflicts. |
@pnkfelix Sure. I’ll try to finish the commit splitting later today. In the meanwhile, please let me if I can reorganise things any mire to help get this merged. |
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'm not quite clear what the rules are where comments start with a capitalized letter and where they start with a lower case letter. As far as I can see there's both happening.
I reviewed the first commit, but I might have missed some things
src/librustc/ty/context.rs
Outdated
@@ -835,7 +835,7 @@ pub type CanonicalUserType<'gcx> = Canonical<'gcx, UserType<'gcx>>; | |||
|
|||
impl CanonicalUserType<'gcx> { | |||
/// Returns `true` if this represents a substitution of the form `[?0, ?1, ?2]`, | |||
/// i.e. each thing is mapped to a canonical variable with the same index. | |||
/// i.e., each thing is mapped to a canonical variable with the same index. |
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.
these .,
look really weird 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.
It's weird, but it's standard in U.S. English. :-) Not in British English. The American motivation is that you're abbreviating "id est, ...", which is Latin for "that is, ...". In that sense, it makes sense, but I know what you mean still.
src/librustc_apfloat/ieee.rs
Outdated
@@ -186,7 +186,7 @@ impl Semantics for X87DoubleExtendedS { | |||
/// exponent = all 1's, integer bit 0, significand 0 ("pseudoinfinity") |
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 we're supposed to keep the librustc_apfloat
crate (docs) in sync with llvm's. So the best course of action would be an additional patch against llvm.
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.
Hard to tell... it looks like some docs have already been Rustified.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #58079) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -327,7 +327,7 @@ fn map_lib_features(base_src_path: &Path, | |||
} | |||
becoming_feature = None; | |||
if line.contains("rustc_const_unstable(") { | |||
// `const fn` features are handled specially. | |||
// Const fn features are handled specially. |
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'm not sure this is a good change.
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.
Okay, happy to undo!
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.
On second thought, I ran a search, and it seems "const fn" without the quotes is much more common in comments. I think it's okay personally, since "fn" can be considered an abbreviation for "function", and "const" and attribute/adjective.
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.
(But I'll still revert it if you prefer.)
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'm not entirely sure that commonality is the right argument here. I don't think that either of these is particularly bad, but given that it's a specific rust feature, and that's it's name, const fn
seems like its "proper name". Dunno.
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 might not be... I am just of the mind to opt for consistency when in doubt as to which is "morally" better. "Fn" is used as an abbreviation all over the codebase without backticks as well, it's worth saying. Will leave this for now, but just tell me to revert if you decide on that. Just pushed BTW, so feel free to continue reviewing. Thanks!
(About to push some changes, FYI. @steveklabnik) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #57973) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #58495) made this pull request unmergeable. Please resolve the merge conflicts. |
Blocked on #58619 |
Cosmetic improvements to doc comments This has been factored out from rust-lang/rust#58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
Various cosmetic improvements Related to the larger effort of rust-lang/rust#58036.
These are not legally required and are mostly noise. See: * rust-lang/rust#58036 * rust-lang/rls#1326
Cosmetic improvements to doc comments This has been factored out from rust-lang/rust#58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
Cosmetic improvements to doc comments This has been factored out from rust-lang/rust#58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far! [git filter-repo] original commit: rust-lang/rust@b244f61
Cosmetic improvements to doc comments This has been factored out from rust-lang/rust#58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
This is my second take on #57016, where I am doing a few things differently:
This is sort of like a "tracking PR" for now, and probably shouldn't be merged as-is unless someone is happy with all my changes.
CC @nikomatsakis @steveklabnik