Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Clean up E0764 #76059

Merged
merged 1 commit into from
Sep 1, 2020
Merged

Clean up E0764 #76059

merged 1 commit into from
Sep 1, 2020

Conversation

GuillaumeGomez
Copy link
Member

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 29, 2020
pickfire
pickfire reviewed Aug 29, 2020
View reviewed changes
src/librustc_error_codes/error_codes/E0764.md Outdated
Comment on lines 18 to 22
constant essentially mutable. While there could be a more fine-grained scheme
in the future that allows mutable references if they are not "leaked" to the
final value, a more conservative approach was chosen for now. `const fn` do not
have this problem, as the borrow checker will prevent the `const fn` from
returning new mutable references.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
constant essentially mutable. While there could be a more fine-grained scheme
in the future that allows mutable references if they are not "leaked" to the
final value, a more conservative approach was chosen for now. `const fn` do not
have this problem, as the borrow checker will prevent the `const fn` from
returning new mutable references.
constant essentially mutable.
While there could be a more fine-grained scheme in the future that allows
mutable references if they are not "leaked" to the final value, a more
conservative approach was chosen for now. `const fn` do not have this problem,
as the borrow checker will prevent the `const fn` from returning new mutable
references.

I think it would look better splitting these. I find hard to read when the paragraph is too long.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you missed this suggestion.

@pickfire
Copy link
Contributor

pickfire commented Aug 29, 2020 •
edited
Loading

@GuillaumeGomez I think you could just add me as a reviewer for these kind of changes (even though I am not in the team).

Similarly, I have also been sending patch on documentation. I saw that it looks weird having some parts in docs shows "See its documentation for more" and some doesn't. I will fix those that I saw without too but usually I don't know who to add as a reviewer.

@jyn514 Do you know who is in the docs team that I should add as reviewer for those kind of changes?

@GuillaumeGomez
Copy link
Member Author

Sure, it's just out of habit. And you can put me as reviewer for your error codes PRs.

@pickfire
Copy link
Contributor

pickfire commented Aug 29, 2020 •
edited
Loading

Sure, it's just out of habit. And you can put me as reviewer for your error codes PRs.

I never did error codes PRs as of the moment. I rarely found issue with it except when reviewing your PR. I found areas to improve in alloc vec documentation when I was coping it word by word to my own crate ve.

So do you go through each error code one by one even though you have never seen them?

@GuillaumeGomez
Copy link
Member Author

I created a lot of them, currently it's mostly "unification" and cleanup. For "global" documentation, I guess you can let bors pick one for you.

@pickfire
Copy link
Contributor

Pick one for me?

@GuillaumeGomez
Copy link
Member Author

A reviewer.

@jyn514
Copy link
Member

jyn514 commented Aug 29, 2020

Do you know who is in the docs team that I should add as reviewer for those kind of changes?

@poliorcetics might be interested in reviewing, but they don't have bors permissions. I'm happy to cherry stamp their doc approvals though.

@poliorcetics
Copy link
Contributor

I'm ok with reviewing any doc changes, I'll just defer to someone else if I feel unable to proper review.

@Dylan-DPC-zz
Copy link

Depends on teh doc changes, I normally review the smaller ones and reassign the larger ones if needed, and some of them often need a pair of eyes from libs and/or compiler team

@pickfire
Copy link
Contributor

I guess I will just assign the pull requests next time for doc to either @poliorcetics or @Dylan-DPC. By the way, I just created a few pull requests just now. Maybe you all want to review those?

@Dylan-DPC-zz
Copy link

looks good to me

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Aug 29, 2020

📌 Commit 76ae3ec0e124c7ce27785e46de85e73dd8b0cd9a has been approved by Dylan-DPC

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 29, 2020
@pickfire
Copy link
Contributor

@pickfire apply suggestion

@bors
Copy link
Contributor

bors commented Aug 30, 2020

☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 30, 2020
@jyn514 jyn514 added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Aug 30, 2020
@GuillaumeGomez
Copy link
Member Author

Updated and I applied @pickfire suggestion too. ;)

@bors: r=Dylan-DPC,pickfire

@bors
Copy link
Contributor

bors commented Aug 31, 2020

📌 Commit 153f966 has been approved by Dylan-DPC,pickfire

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 31, 2020
@tmandry tmandry mentioned this pull request Sep 1, 2020
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 1, 2020
@bors
Auto merge of rust-lang#76186 - tmandry:rollup-49nliiy, r=tmandry
445f34b 
Rollup of 12 pull requests

Successful merges:

 - rust-lang#75945 (Use `env::func()`, not 'the function env::func' in docs for std::env)
 - rust-lang#76002 (Fix `-Z instrument-coverage` on MSVC)
 - rust-lang#76003 (Adds two source span utility functions used in source-based coverage)
 - rust-lang#76059 (Clean up E0764)
 - rust-lang#76103 (Clean up E0769)
 - rust-lang#76139 (Make `cow_is_borrowed` methods const)
 - rust-lang#76154 (Fix rustdoc strings indentation)
 - rust-lang#76161 (Remove notrust in rustc_middle)
 - rust-lang#76163 (README: Adjust Linux and macOS support platform and architecture)
 - rust-lang#76166 (Make `StringReader` private)
 - rust-lang#76172 (Revert rust-lang#75463)
 - rust-lang#76178 (Update expect-test to 1.0)

Failed merges:

r? @ghost
@bors bors merged commit 5033203 into rust-lang:master Sep 1, 2020
@GuillaumeGomez GuillaumeGomez deleted the cleanup-e0764 branch September 1, 2020 08:23
@cuviper cuviper added this to the 1.48.0 milestone Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pickfire pickfire pickfire left review comments

Assignees

@Dylan-DPC-zz Dylan-DPC-zz

Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Milestone
1.48.0
Development

Successfully merging this pull request may close these issues.
8 participants
@GuillaumeGomez @pickfire @jyn514 @poliorcetics @Dylan-DPC-zz @bors @cuviper @rust-highfive