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.

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

Remove duplicate remove_outer_derefs and refactor mod deref #573

Open
wants to merge 5 commits into
base: tests.refs.fields
Choose a base branch
from

Conversation

kkysen
Copy link
Contributor

@kkysen kkysen commented Aug 2, 2022

This refactors mod deref, implementing most of the functions there in terms of one try_remove_outer_deref_as_ref so that we know they're all in sync. Also, try_remove_outer_deref is added so that you don't have to do separate has_outer_deref and remove_outer_deref calls.

Then I used this to de-duplicate the 1 has_outer_ref and 2 remove_outer_deref calls in the RValue::{AddressOf,Ref} match arms by combining the arms and using try_remove_outer_deref.

Then I used apply to simplify the conditional builder logic. It's quite a small but useful dependency for functional, chaining code.

The remaining code is still quite similar between the RValue::AddressOf and Rvalue::Ref match arms, so maybe we can refactor that into common code as well.

@kkysen kkysen changed the title Kkysen/tests.refs.fields/remove outer deref refactor Remove duplicate remove_outer_derefs and refactor mod deref Aug 2, 2022
@kkysen kkysen requested a review from aneksteind August 2, 2022 07:18
It encouraged an anti-pattern anyways, using `has_outer_deref` and then `remove_outer_deref` instead of `try_remove_outer_deref`.
Copy link
Contributor

@aneksteind aneksteind left a comment

Choose a reason for hiding this comment

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

I'm not in favor of combining the match arms. I do however like your original idea outlined here in order to bind source in the match arm for use in the body and would support that change.

Rvalue::AddressOf(_, p) => {
// Instrument which local's address is taken
self.loc(location.successor_within_block(), addr_local_fn)
let source = try_remove_outer_deref(*p, self.tcx())
Copy link
Contributor

Choose a reason for hiding this comment

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

i don't want to combine these, there are more complicated cases incoming and it'll be much clearer if they're separate

// this is a reborrow or field reference, i.e. _2 = &(*_1)
let source = remove_outer_deref(*p, self.tcx());
if let BorrowKind::Mut { .. } = bkind {
let source = try_remove_outer_deref(*p, self.tcx());
Copy link
Contributor

Choose a reason for hiding this comment

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

i don't want to combine these, there are more complicated cases incoming and it'll be much clearer if they're separate

@kkysen
Copy link
Contributor Author

kkysen commented Aug 3, 2022

I'm not in favor of combining the match arms. I do however like your original idea outlined here in order to bind source in the match arm for use in the body and would support that change.

My original idea uses #![feature(if_let_guard, let_chains)], though. It is a lot nicer, though, I think, but I don't want to add unstable features.

@kkysen
Copy link
Contributor Author

kkysen commented Aug 3, 2022

#![feature(let_chains)] is already merged and stabilizing in Rust 1.64 (rust-lang/rust#94927), so since we're pinned to a nightly, too, I think using that should be fine, but #![feature(if_let_guard)] is not close to stabilization (rust-lang/rust#51114).

@kkysen
Copy link
Contributor Author

kkysen commented Aug 3, 2022

I understand there might be more complex logic coming, so I shouldn't combine the logic in the way I did, but I don't think combining match arms into one per Rvalue variant is bad. We can then do more complex branching within each Rvalue match arm rather than be limited to only guards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants