[LifetimeSafety] False-positive for loan in a loop

[usx95]

struct MyObj {
    int id;
    ~MyObj() {}
};

void foo(bool cond) {
    MyObj b;
    MyObj* p;
    for (; cond;) {
        MyObj a;
        p = &b;
        if (cond) {
            p = &a; //  error: object whose reference is captured may not live long enough. <Bad!>
        }
        (void)*p; // note: later used here.
    } // note: destroyed here.
}

https://godbolt.org/z/Y176hhx9q

[llvmbot]

@llvm/issue-subscribers-clang-temporal-safety

Author: Utkarsh Saxena (usx95)

```cpp struct MyObj { int id; ~MyObj() {} };

void foo(bool cond) {
for (; cond;) {
MyObj a;
MyObj* p;
if (cond) {
p = &a; // error! Bad. False positive
}
(void)*p; // note: later used here.
}
}

https://godbolt.org/z/6nex6jesz
</details>

[usx95]

TL;DR: We had discussed a liveness based formulation of our lifetime policy. This example gives strong evidence in favour of such a policy.

Details:
This is happening because loan to '&a' is found to be expired at (void)*p. This is because loan gets expired at the end of the loop which feeds it back to the start of the loop making the loan expired everywhere in the loop body.

But this also points to a design flaw in ExpiredLoans analysis and Lifetime violation policy.

Let's look at when this example actually becomes unsafe:

Example 2

bool cond();
void foo() {
    MyObj b;
   MyObj* p = &b;
    for (; cond();) {
        MyObj a;
        if (cond()) {
            p = &a; //  error: object whose reference is captured may not live long enough. <Good!>
        }
        (void)*p; // note: later used here.
    } // note: destroyed here.
}

Now this is unsafe because p can point to a from a previous loop iteration (rust also agrees link)

Lifetime Violation Policy

The difference in Example 2, is that the expire fact of loan is visible at point of use (void)(*p) while in our original example in report, it is not.

Right now the policy is:
A use of p at a program point PP is a violation if contains a loan L and L is expired at PP.

And the flaw of this policy is that hinges on the "use" (in a use-after-free).

An alternative policy which has been discussed is to hinge on the "free" (in a use-after-free).
Let's introduce

• IsLive(L, PP): A loan L is considered live at program point PP if there an origin O which contains the Loan L at PP and IsLive(O, PP)`.
• IsLive(O, PP): An origin O is live at program point PP. This is usual liveness definition using Gen and Kill. A use of origin at PP --> Gen(O, PP). A write (e.g. on LHS of an assignment) to an origin --> Kill(O, PP).

Using the liveness model, we can model that in Example 1 there is no Origin carrying an expired loan and the loan is not alive at its expiry: MyObj* p = &b; kills the carried loan.
On the other hand, in example 2 the expired loan is actually visible (live) through the else branch of the if and is only killed in the then branch.

The modified policy required to address this is:
There is a lifetime violation for a loan L if it expires at a program point PP and IsLive(L, PP)

Other hacky solutions (not recommended):

• When we initialise a in MyObj a, remove all loans to a from Expired loans set. This essentially says that we do not have enough confidence that a prior loan to a is valid or not after a has been re-initialised.
• Do not propagate expired loans back in a loop.