Check coroutine upvars in dtorck constraint

[compiler-errors]

Fix #144155.

r? @lcnr or reassign 😸

---

Just some thoughts --- a proper fix for this whole situation would be to consider TypingMode in the needs_drop function, and just calling coroutine_ty.needs_drop(tcx, typing_env) in the dtorck constraint check.

During MIR building, we should probably use a typing mode that stalls the local coroutines and considers them to be unconditionally drop, or perhaps just stall all coroutines in analysis mode. Then in borrowck mode, we can re-check needs_drop but descend into witness types properly. #144158 implements this experimentally.

This is a pretty involved fix, and conflicts with some in-flight changes (#144157) that I have around removing coroutine witnesses altogether. I'm happy to add a FIXME to rework this whole approach, but I don't want to block this quick fix since it's obviously more correct than the status-quo.

[lcnr]

I am trying to figure out how this unsoundness slipped through:

I think I/we implicitly assumed that all upvars are also part of the witness 🤔 the fact that the upvars are not part of the witness type is really confusing to me. Looking at the FCP comment in #117134 (comment) this is exactly what I've assumed.

Looking back at this PR, what we are doing here is that if dropping a coroutine may actually execute a Drop impl, everything that can be accessed inside of the coroutine needs to be use-live.

This is the case as the lifetimes used by the drop impl inside of the coroutine are erased, so the thing we actually care about - the things required for the dropped fields to be drop-live - is unknowable and we need to over approximate.

The unsoundness here is that dropping a coroutine may drop upvars without using storing them witness type. Checking the resume_ty should be unnecessary as hopefully any resume type actually stored over an await point should be part of the witness.

Please remove the check for resume type and update this comment.

[compiler-errors]

Yeah, checking the resume type isn't needed since it's redundant. I added a comment about that right next to the let needs_drop = ....

As for the top comment, I reworked it completely, since I think it didn't really capture the point of this hack.

I'm pretty happy with it, but if you have any further comment edits, could you leave them as inline comments and an approval? I'd rather not block this PR on just comment rewording. Thank you :3

[compiler-errors]

Specifically, I'm not totally sure if I captured the nuance you wanted about use-liveness of the upvar types implying drop-liveness of the witness. If you want to tweak it, go ahead.

[compiler-errors]

Yeah, I guess the resume ty doesn't need to be checked since although it can contain lifetimes, it would need to be stored in a witness ty to actually be dropped (since it doesn't have its own storage) and so it's redundant wrt the witness part of this drop check.

[compiler-errors]

Also, this is still kinda imprecise and could be improved. The code really should look something like:

let needs_drop = args.witness().needs_drop(tcx, typing_env);
if needs_drop {
    constraints.outlives.extend(args.upvar_tys().iter().map(ty::GenericArg::from));
    constraints.outlives.push(args.resume_ty().into());
} else {
    // Even if an interior type doesn't need a drop, we still require that the upvars are drop-live.
    for ty in args.upvar_tys() {
        dtorck_constraint_for_ty_inner(
            tcx,
            typing_env,
            span,
            depth + 1,
            ty,
            constraints,
        );
    }
}

That is to say -- we consider all upvars to be use-live if a witness type is drop. But if no witness type is drop, we only require that the upvars are drop-live. This is much closer to how we handle upvars in the closure case above.

I didn't really want to change this here because I don't want to block this PR much longer, but if you prefer we fix it the right way, then pls let me know.