This patch introduces a new CXXLifetimeExtendedObjectRegion as a representation
of the memory for the temporary object that is lifetime extended by the reference
to which they are bound.
This separation provides an ability to detect the use of dangling pointers
(either binding or dereference) in a robust manner.
For example, the ref is conditionally dangling in the following example:
template<typename T> T const& select(bool cond, T const& t, T const& u) { return cond ? t : u; } int const& le = Composite{}.x; auto&& ref = select(cond, le, 10);
Before the change, regardless of the value of cond, the select() call would
have returned a temp_object region.
With the proposed change we would produce a (non-dangling) lifetime_extended_object
region with lifetime bound to le or a temp_object region for the dangling case.
We believe that such separation is desired, as such lifetime extended temporaries
are closer to the variables. For example, they may have a static storage duration
(this patch removes a static temporary region, which was an abomination).
We also think that alternative approaches are not viable.
While for some cases it may be possible to determine if the region is lifetime
extended by searching the parents of the initializer expr, this quickly becomes
complex in the presence of the conditions operators like this one:
Composite cc; // Ternary produces prvalue 'int' which is extended, as branches differ in value category auto&& x = cond ? Composite{}.x : cc.x; // Ternary produces xvalue, and extends the Composite object auto&& y = cond ? Composite{}.x : std::move(cc).x;
Finally, the lifetime of the CXXLifetimeExtendedObjectRegion is tied to the lifetime of
the corresponding variables, however, the "liveness" (or reachability) of the extending
variable does not imply the reachability of all symbols in the region.
In conclusion CXXLifetimeExtendedObjectRegion, in contrast to VarRegions, does not
need any special handling in SymReaper.
RFC: https://discourse.llvm.org/t/rfc-detecting-uses-of-dangling-references/70731
Do we actually need this Expr in the memory region?