Conversation
rust-highfive
added
the
S-waiting-on-review
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
I think you missed this suggestion.
|
@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? |
|
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 So do you go through each error code one by one even though you have never seen them? |
|
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. |
|
Pick one for me? |
|
A reviewer. |
@poliorcetics might be interested in reviewing, but they don't have bors permissions. I'm happy to cherry stamp their doc approvals though. |
|
I'm ok with reviewing any doc changes, I'll just defer to someone else if I feel unable to proper review. |
|
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 |
|
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? |
|
looks good to me @bors r+ rollup |
|
📌 Commit 76ae3ec0e124c7ce27785e46de85e73dd8b0cd9a has been approved by |
bors
added
S-waiting-on-bors
|
@pickfire apply suggestion |
|
☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
S-waiting-on-author
jyn514
added
the
A-docs
GuillaumeGomez
force-pushed
the
cleanup-e0764
branch
from
76ae3ec to
153f966
Compare
|
📌 Commit 153f966 has been approved by |
bors
added
S-waiting-on-bors
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
8 participants
r? @Dylan-DPC