Reenable generator drop tracking tests and fix mutation handling

[eholk]

The previous PR, #94068, was overly zealous in counting mutations as borrows, which effectively nullified drop tracking. We would have caught this except the drop tracking tests were still ignored, despite having the option of using the -Zdrop-tracking flag now.

This PR fixes the issue introduced by #94068 by only counting mutations as borrows the mutated place has a project. This is sufficient to distinguish x.y = 42 (which should count as a borrow of x) from x = 42 (which is not a borrow of x because the whole variable is overwritten).

This PR also re-enables the drop tracking regression tests using the -Zdrop-tracking flag so we will avoid introducing these sorts of issues in the future.

Thanks to @tmiasko for noticing this problem and pointing it out!

r? @tmiasko

[tmiasko]

I though that the assignments introduce borrows because the old value needs to be dropped first. The drop terminators borrows the dropped place and then the state transforms falls back to the conservative analysis based strictly on the storage makers. In that case presence of projections would be mostly insignificant. Is there something more to it? Could you explain it a bit?

To close the gap between typeck and MIR we could do some of the following:

• Check if type needs to be dropped. The ExprKind::Assign is lowered to TerminatorKind::DropAndReplace, but only if type needs to be dropped. Otherwise it is a plain assignment.
• Distinguish between mutation in ExprKind::Let from ExprKind::Assign. In the former case there is no existing value that would need to be dropped.
• Check if place might be initialized before considering it to be borrowed. The drop elaboration removes drops when place is know to be uninitialized (as identified by MaybeInitializedPlaces).

Failing test case where a whole variable is overwritten:

struct A;
impl Drop for A { fn drop(&mut self) {} }

pub async fn f() {
    let mut a = A;
    a = A;
    drop(a);
    async {}.await;
}

[eholk]

Thanks for the feedback, @tmiasko. That makes a lot more sense that the borrow happens because it's basically doing Drop::drop(&mut x); x = new_value. I just pushed a new patch that solves the problem better by:

1. Use Ty::needs_drop in the mutate callback, since that's what actually causes the borrow.
2. Add a bind callback to ExprUseVisitor that by default forwards to mutate to keep the old behavior but allows us to precisely distinguish binding "assignments" from normal assignments.

I left off the third option (ignoring cases where the assignee is known to be uninitialized) for now, although we might be able to figure that case out by looking for assignments to variables that aren't preceded by a bind callback.

[tmiasko]

@bors r+ rollup=always

[bors]

📌 Commit add169d has been approved by tmiasko