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

Lint needless_borrow and explicit_auto_deref on most union field accesses #11508

Merged
merged 2 commits into from Nov 12, 2023

Conversation

Jarcho
Copy link
Contributor

@Jarcho Jarcho commented Sep 15, 2023

Changes both lints to follow rustc's rules around auto-deref through ManuallyDrop union fields rather than just bailing on union fields.

changelog: [needless_borrow] & [explicit_auto_deref]: Lint on most union field accesses

@rustbot
Copy link
Collaborator

rustbot commented Sep 15, 2023

r? @blyxyas

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Sep 15, 2023
@blyxyas
Copy link
Member

blyxyas commented Sep 17, 2023

It seems like #11477 fixed #11474. Is this PR still applicable?
Edit: If it's still applicable, could you provide some more description about what the fix is about?

@Jarcho
Copy link
Contributor Author

Jarcho commented Sep 17, 2023

It's still relevant. Both the PR and the issue in question seem to have some misunderstandings why the suggestion doesn't compile. Auto-deref only doesn't apply on ManuallyDrop fields of unions when the result is used to access a field. In other words, x.y.z isn't valid when x is a union, y is a ManuallyDrop field, and z is used mutably.

@bors
Copy link
Collaborator

bors commented Sep 17, 2023

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

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

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

The first commit is looking pretty good, just some preliminary feedback

Comment on lines +220 to +234
let _ = &mut (&mut x.u).x;
let _ = &mut (&mut { x.u }).x;
let _ = &mut ({ &mut x.u }).x;

let mut x = U {
u: Wrap(ManuallyDrop::new(Foo { x: 0 })),
};
let _ = &mut (&mut x.u).x;
let _ = &mut (&mut { x.u }).x;
let _ = &mut ({ &mut x.u }).x;

let mut x = U { u: Wrap(Foo { x: 0 }) };
let _ = &mut (&mut x.u).x;
let _ = &mut (&mut { x.u }).x;
let _ = &mut ({ &mut x.u }).x;
Copy link
Member

Choose a reason for hiding this comment

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

Could you add //~ ERROR annotations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought we weren't going to enforce this until ui_test worked the way we wanted it.

Copy link
Member

Choose a reason for hiding this comment

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

If I understand correctly, the conclusions from the Zulip thread talking about this were that we soft-mandated //~ERROR annotations (without a body). Even if they aren't obligated by the CI, I just find them to increase legibility 🐱

Copy link
Member

Choose a reason for hiding this comment

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

Are we sure these brackets are necessary? Is there some special behaviour about references in blocks?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

GitHub isn't showing code here, so I assume you're referring to the mid expression blocks. The final expression in a block is moved before the parent expression runs. Since rustc only disallows x.y.z not any other form (e.g. { x.y }.z) tests around that are needed.

@@ -172,8 +172,7 @@ pub struct Dereferencing<'tcx> {
#[derive(Debug)]
struct StateData<'tcx> {
/// Span of the top level expression
Copy link
Member

Choose a reason for hiding this comment

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

This comment is outdated

if parent_id == data.first_expr.hir_id {
return;
}
(cx.tcx.hir().get(parent_id).expect_expr().span, true)
Copy link
Member

Choose a reason for hiding this comment

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

Could you replace this expect_expr with a fallible alternative? Or is there a guarantee that the parent id is an expression?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There has to be at least one deref expression as direct parents.

Comment on lines +716 to +723
// Checks if the adjustments contains a deref of `ManuallyDrop<_>`
fn adjust_derefs_manually_drop<'tcx>(adjustments: &'tcx [Adjustment<'tcx>], mut ty: Ty<'tcx>) -> bool {
adjustments.iter().any(|a| {
let ty = mem::replace(&mut ty, a.target);
matches!(a.kind, Adjust::Deref(Some(ref op)) if op.mutbl == Mutability::Mut) && is_manually_drop(ty)
})
}

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure about the logic of this function. The original ty passed into the function is never read because from the first iteration it is already replaced with an adjustment.

Also, the doc-comment isn't a doc-comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The result of mem::replace on the first iteration is the passed in value.

@blyxyas
Copy link
Member

blyxyas commented Oct 19, 2023

I think that this two commits can be squashed, as all changes made to clippy_lints/src/dereference.rs made by the first one are deleted by the second one, and the changes left are just to tests.

@bors
Copy link
Collaborator

bors commented Nov 2, 2023

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

@Jarcho
Copy link
Contributor Author

Jarcho commented Nov 11, 2023

The first commit made changes to some logic. The second commit uses the changed logic, but extracted into a function. Diffs sometimes do a bad job at showing things.

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

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

LGTM, thanks! ❤️

@blyxyas
Copy link
Member

blyxyas commented Nov 12, 2023

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 12, 2023

📌 Commit 1a01132 has been approved by blyxyas

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Nov 12, 2023

⌛ Testing commit 1a01132 with merge 886d5fb...

@bors
Copy link
Collaborator

bors commented Nov 12, 2023

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: blyxyas
Pushing 886d5fb to master...

@bors bors merged commit 886d5fb into rust-lang:master Nov 12, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants