-
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
2229: Update signature for truncate function #88267
Conversation
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 should push the &mut
arguments through more thoroughly
if place.base_ty.is_unsafe_ptr() { | ||
return truncate_place_to_len(place, curr_mode, 0); | ||
truncate_place_to_len_and_update_capture_kind(&mut place, &mut curr_mode, 0); |
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.
we used to return here, but now we don't? maybe this function also wants to take &mut
arguments?
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.
we just return once at the bottom. Otherwise each of these has a return (place, curr_mode)
@@ -1880,7 +1873,7 @@ fn restrict_capture_precision<'tcx>( | |||
place: Place<'tcx>, | |||
curr_mode: ty::UpvarCapture<'tcx>, | |||
) -> (Place<'tcx>, ty::UpvarCapture<'tcx>) { | |||
let (place, curr_mode) = restrict_precision_for_unsafe(place, curr_mode); | |||
let (mut place, mut curr_mode) = restrict_precision_for_unsafe(place, curr_mode); |
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.
as above, I suspect this could take &mut
place arguments
What do you think about having the general pattern be to take |
I personally feel returning is more functional and gives the reader of the code an exact idea of what's going on / being upadted (though so does the name). Also returning the tuple makes it closer to how the algorithm is written out in the reference. But If you prefer |
@arora-aman I see your point. Let's keep it as is. @bors r+ |
📌 Commit ed43e02 has been approved by |
…eulArtichaut Rollup of 16 pull requests Successful merges: - rust-lang#87944 (add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells) - rust-lang#88156 (Adjust / fix documentation of `Arc::make_mut`) - rust-lang#88157 (bootstrap.py: recognize riscv64 when auto-detect) - rust-lang#88196 (Refactor `named_asm_labels` to a HIR lint) - rust-lang#88218 (Remove `Session.trait_methods_not_found`) - rust-lang#88223 (Remove the `TryV2` alias) - rust-lang#88226 (Fix typo “a Rc” → “an Rc” (and a few more)) - rust-lang#88267 (2229: Update signature for truncate function) - rust-lang#88273 (Fix references to `ControlFlow` in docs) - rust-lang#88277 (Update books) - rust-lang#88291 (Add SAFETY comments to core::slice::sort::partition_in_blocks) - rust-lang#88293 (Fix grammar in alloc test) - rust-lang#88298 (Errorkind reorder) - rust-lang#88299 (Stabilise BufWriter::into_parts) - rust-lang#88314 (Add type of a let tait test) - rust-lang#88325 (Add mutable-noalias to the release notes for 1.54) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
r? @nikomatsakis