Enabling pointer escape notification for the return value invalidation when conservatively evaluating calls that return C++ objects by value was supposed to be pointless. Indeed, we're looking at a freshly conjured value; why would any checker already track it at this point? Yet it does cause a change in results, so i decided to reduce and investigate a reproducer @Charusso sent me.
When i was thinking about it previously (as of D44131), i was imagining a function that constructs a temporary that would later be copied to its target destination. In this case there's indeed no need to notify checkers of pointer escape.
However, once RVO was implemented (D47671), the target region is no longer necessarily a temporary; it may be an arbitrary memory region. In particular, it may be a non-base region, such as FieldRegion if the construction context is a ConstructorInitializerConstructionContext. In this case the invalidation covers not only the target region but its whole base region that may already contain some values that might as well be tracked by the checkers.
The right solution, therefore, is to restrict invalidation so that it didn't propagate to the base region, but only wipe the target region itself. It probably doesn't work perfectly because RegionStore doesn't enjoy this sort of stuff, but it should be something.
In the newly added test case the previous behavior was to immediately forget about b1.p and b2.p, therefore evals on lines 21 and 23 yielded both TRUE and FALSE each (due to eagerly-assume) and the leak was diagnosed on line 22 (even though the pointer is used later).