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

Fix manual_inspect to consider mutability #13609

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

SpriteOvO
Copy link
Contributor

@SpriteOvO SpriteOvO commented Oct 27, 2024

Fixes #13185.

In this PR, we fix the false positives. I left some FIXME cases, it would be nice if they could be supported in the future.

changelog: [manual_inspect]: Fix to consider mutability

@rustbot
Copy link
Collaborator

rustbot commented Oct 27, 2024

r? @xFrednet

rustbot has assigned @xFrednet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Oct 27, 2024
Comment on lines 2853 to 2818
/// Assignment.
Assign(usize),
/// Assignment with an operator.
AssignOp(BinOpKind, usize),
Copy link
Contributor

Choose a reason for hiding this comment

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

No need to capture this. The lint already checks if the binding in the closure is mutable so x = something would fail to compile.

Copy link
Contributor Author

@SpriteOvO SpriteOvO Oct 27, 2024

Choose a reason for hiding this comment

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

The lint already checks if the binding in the closure is mutable so x = something would fail to compile.

Do you mean this line?

&& let PatKind::Binding(BindingMode(ByRef::No, Mutability::Not), arg_id, _, None) = param.pat.kind

This checks the mut pattern, right. So Assign is indeed not needed for this lint, but given that it's a function in clippy_utils, I'd like to make it take all cases into account as much as possible. And AssignOp is still needed for something like x += y.

Copy link
Contributor

Choose a reason for hiding this comment

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

x += y also wouldn't compile. Once you fix use_mutability there will be no uses of these variants left (use_node and expr_use_ctxt shouldn't be used there).

Comment on lines 2814 to 2791
pub fn use_mutability(&self, cx: &LateContext<'tcx>) -> Mutability {
match self.use_node(cx) {
ExprUseNode::FieldAccess(parent, _) => {
let parent = cx.tcx.hir().expect_expr(parent);
expr_use_ctxt(cx, parent).use_mutability(cx)
},
ExprUseNode::AssignOp(_, 0) | ExprUseNode::Assign(0) => Mutability::Mut,
ExprUseNode::AddrOf(_, mutbl) => mutbl,
ExprUseNode::FnArg(_, _) | ExprUseNode::MethodArg(_, _, _) => {
let child_expr = cx.tcx.hir().expect_expr(self.child_id);
let ty = cx.typeck_results().expr_ty_adjusted(child_expr);
ty.ref_mutability().unwrap_or(Mutability::Not)
},
_ => Mutability::Not,
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Using expr_use_ctxt here is wrong since it allows moves to occur. Just use parent_iter.

You'll need to handle mutable borrow or deref adjustments, mutable borrows, mutable derefs, mutable indexing, and assignments. For indexing and derefs you can't tell at the expression so you have to keep walking up the tree. For adjustments, don't go by the resulting type, but walk the adjustments themselves. Mutable auto-deref doesn't always result in a reference after all adjustments take place.

Copy link
Contributor Author

@SpriteOvO SpriteOvO Oct 27, 2024

Choose a reason for hiding this comment

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

Oh, thanks for pointing those out, I'll check it out.

Mutable auto-deref doesn't always result in a reference after all adjustments take place.

Would you mind explaining it further? Under what circumstances would adjustments not work? So that I can write a test case to make sure of that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Field accesses through a pointer don't. e.g. x.y where x is a reference will have have a deref adjustment, but not a borrow adjustment.

Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

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

Tiny NIT, besides the comments from @Jarcho. Otherwise, it looks good to me :D

ExprKind::AddrOf(kind, mutbl, _) => ExprUseNode::AddrOf(kind, mutbl),
ExprKind::Assign(lhs, rhs, _) => {
debug_assert!(lhs.hir_id == self.child_id || rhs.hir_id == self.child_id);
#[allow(clippy::bool_to_int_with_if)]
Copy link
Member

Choose a reason for hiding this comment

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

NIT:

Suggested change
#[allow(clippy::bool_to_int_with_if)]
#[expect(clippy::bool_to_int_with_if)]

Is there a reason why you rather expect this lint over taking the suggestion?

@bors
Copy link
Contributor

bors commented Nov 7, 2024

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

@xFrednet
Copy link
Member

Hey @SpriteOvO , this is a ping from triage, since there hasn't been any activity in some time. Are you still planning to continue this implementation?

If you have any questions, you're always welcome to ask them in this PR or on Zulip.

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Dec 13, 2024
@SpriteOvO
Copy link
Contributor Author

Sorry about that, I'm a bit busy recently, and I will probably continue this PR starting next week.

Copy link
Member

@xFrednet xFrednet 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 for getting back to this, I appreciate it!


Roses are red,
Roses are blue,
They have to be mut,
for this to be true

@xFrednet xFrednet added this pull request to the merge queue Jan 15, 2025
@SpriteOvO
Copy link
Contributor Author

SpriteOvO commented Jan 15, 2025

Oh, waittt.. I'm still working on it now, that force-push was just a rebasing.

@SpriteOvO SpriteOvO marked this pull request as draft January 15, 2025 20:19
@xFrednet xFrednet removed this pull request from the merge queue due to a manual request Jan 15, 2025
@xFrednet
Copy link
Member

xD, sorry, I only checked the changed file and that one looked good, so I got a bit too trigger happy. Thank you for catching this in time!

@SpriteOvO
Copy link
Contributor Author

SpriteOvO commented Jan 15, 2025

@xFrednet It's fine, I also very sorry for the super delay updates (just finished it), I have pushed the latest changes based on the reviews. Could you and @Jarcho review it again?

I have changed to use parent_iter, and I'm not sure I'm handling adjustments correctly. (at least, ui-tests looks good)

@SpriteOvO SpriteOvO marked this pull request as ready for review January 16, 2025 03:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

manual_inspect suggestion breaks mutating code
5 participants