Uh oh!
There was an error while loading. Please reload this page.
[WIP] Massive cosmetic PR, take 2 - #58036
Conversation
rust-highfive
commented
Jan 31, 2019
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
pnkfelix
commented
Feb 1, 2019
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. |
bors
commented
Feb 1, 2019
☔ The latest upstream changes (presumably #57916) made this pull request unmergeable. Please resolve the merge conflicts. |
alexreg
commented
Feb 1, 2019
@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. |
oli-obk
left a comment
There was a problem hiding this comment.
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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
these ., look really weird to me.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Hard to tell... it looks like some docs have already been Rustified.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
bors
commented
Feb 3, 2019
☔ The latest upstream changes (presumably #58079) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
I'm not sure this is a good change.
There was a problem hiding this comment.
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.
(But I'll still revert it if you prefer.)
There was a problem hiding this comment.
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.
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!
Uh oh!
There was an error while loading. Please reload this page.
alexreg
commented
Feb 4, 2019
(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.
bors
commented
Feb 5, 2019
☔ The latest upstream changes (presumably #57973) made this pull request unmergeable. Please resolve the merge conflicts. |
rust-highfive
commented
Feb 5, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Feb 5, 2019
☔ The latest upstream changes (presumably #58189) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
alexreg
commented
Feb 6, 2019
@steveklabnik So, which commits do you think I can factor out into a separate PR, for you to have another quick glance at then r+ hopefully? :-) |
This comment has been minimized.
This comment has been minimized.
bors
commented
Feb 7, 2019
☔ The latest upstream changes (presumably #58125) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
bors
commented
Feb 8, 2019
☔ The latest upstream changes (presumably #58191) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
bors
commented
Feb 17, 2019
☔ The latest upstream changes (presumably #58495) made this pull request unmergeable. Please resolve the merge conflicts. |
petrochenkov
commented
Feb 23, 2019
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