Just wanted to play safer in a couple of places.
In D44597 i said:
If the object has trivial destructor then CXXBindTemporaryExpr is not there, and the AST is pretty much indistinguishable from the simple case so we re-use SimpleVariableConstructionContext and SimpleReturnedValueConstructionContext. I'm not entirely sure that this is indeed the same case, but for the purposes of the analyzer, which is the primary user of construction contexts, this seems fine because when the object has trivial destructor it is not scary to inline the constructor.
Well, this is actually an easy question. There certainly are cases where the AST is quite distinguishable, eg. ternary conditional operator. However, because construction contexts are implemented as a whitelist of possible ASTs that we support, it's easy to see that the ternary operator is in fact the only case. The patch suppresses construction contexts in this case for now, because the example from http://lists.llvm.org/pipermail/cfe-dev/2018-March/057357.html made me nervous (even though this particular example works well when there are no destructors involved, so this is a speculative play-safe thingy without an actual analyzer-based test).
Also raise the improperly-constructed flag for the return value construction context into a non-temporary. This also has no effect on the analyzer because we'd inline the constructor anyway. Additionally i added a test case to demonstrate how this is broken.
Is this field false by default? Also, double negation is harder to read (e.g. not modelled properly = false vs. modelled property = true), but I guess that should have been said earlier.