Skip to content

Conversation

@chenyukang
Copy link
Member

@chenyukang chenyukang commented Nov 19, 2025

Fixes #148960
Fixes #148418

r? @davidtwco

cc @cjgillot

My first try on MIR related code, so it may not be the best fix.

@rustbot
Copy link
Collaborator

rustbot commented Nov 19, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 19, 2025
// If this place was dropped and has non-trivial drop,
// skip reporting field assignments.
if !is_direct && is_maybe_drop_guard {
continue;
Copy link
Member Author

Choose a reason for hiding this comment

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

this is for avoiding report unused_assign for this line of code:
https://github.com/rust-lang/rust/blob/main/library/std/src/io/mod.rs#L393

Copy link
Member

Choose a reason for hiding this comment

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

Why would there be an unused_assign for that line irrespective of whether there is a Drop impl?

Copy link
Member Author

Choose a reason for hiding this comment

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

If there's no subsequent code that explicitly reads g.len, this assignment appears "unused".

I think the liveness checking in MIR only knows that the entire g will be dropped, but doesn't know the drop process will read g.len. The is_direct here is used to distinguish this case and avoid false positives for field assignments that Drop may use.

Copy link
Member

Choose a reason for hiding this comment

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

In the past fields weren't checked, only whole variables, right? Why was that changed?

Copy link
Member Author

Choose a reason for hiding this comment

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

The indirect statement is added here:

https://github.com/chenyukang/rust/blob/4930d3e6129b17538e687f97c3b3f3e0dcaea76f/compiler/rustc_mir_transform/src/liveness.rs#L656-L661

it seems to be trying to record the access for a variable with a field:

let mut waiter_queue = .... ; 
...

waiter_queue.set_state_on_drop_to = ..

@cjgillot correct me if I'm wrong.

Copy link
Member Author

Choose a reason for hiding this comment

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

another issue which related to Drop, but this PR does not fix it:

#148418

maybe we need a more general fix.

Copy link
Member Author

@chenyukang chenyukang Nov 20, 2025

Choose a reason for hiding this comment

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

I added a new commit for this PR to fix #148418

00f3155

I double checked the changes for testcase tests/ui/drop/or-pattern-drop-order.stderr, it's now the same with stable branch.

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

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

I wonder about a more principled fix. Instead of trying guess is this is a drop guard when emitting the diagnostic, should we change the dataflow analysis to make the Drop terminator mark live on interesting types? Maybe as a follow-up...

View changes since this review

IndexEntry::Occupied(mut o) => {
// There were already a sighting. Mark this statement as live if it
// was, to avoid false positives.
o.get_mut().live |= live.contains(index);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we update direct too?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, I fixed it and added a test case.

@chenyukang chenyukang force-pushed the yukang-fix-unused-148960 branch from 57c1dcf to 4930d3e Compare November 19, 2025 05:30
@chenyukang chenyukang force-pushed the yukang-fix-unused-148960 branch from b7c9e8d to 00f3155 Compare November 20, 2025 12:01
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

unused_assignments not shown for vec overwrite - Rust 1.92.0-beta.3 Regression (?) in unused_assignments lint when Drop is implemented

5 participants