CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.
Differential Revision: https://reviews.llvm.org/D44763
llvm-svn: 328255
In C++17 copy elision is mandatory for variable and return value constructors
(as long as it doesn't involve type conversion) which results in AST that does
not contain elidable constructors in their usual places. In order to provide
construction contexts in this scenario we need to cover more AST patterns.
This patch makes the CFG prepared for these scenarios by:
- Fork VariableConstructionContext and ReturnedValueConstructionContext into
two different sub-classes (each) one of which indicates the C++17 case and
contains a reference to an extra CXXBindTemporaryExpr.
- Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and
ReturnedValueConstructionContext as its context.
Differential Revision: https://reviews.llvm.org/D44597
llvm-svn: 328248
This patch adds a new CFGStmt sub-class, CFGCXXRecordTypedCall, which replaces
the regular CFGStmt for the respective CallExpr whenever the CFG has additional
information to provide regarding the lifetime of the returned value.
This additional call site information is represented by a ConstructionContext
(which was previously used for CFGConstructor elements) that provides references
to CXXBindTemporaryExpr and MaterializeTemporaryExpr that surround the call.
This corresponds to the common C++ calling convention solution of providing
the target address for constructing the return value as an auxiliary implicit
argument during function call.
One of the use cases for such extra context at the call site would be to perform
any sort of inter-procedural analysis over the CFG that involves functions
returning objects by value. In this case the elidable constructor at the return
site would construct the object explained by the context at the call site, and
its lifetime would also be managed by the caller, not the callee.
The extra context would also be useful for properly handling the return-value
temporary at the call site, even if the callee is not being analyzed
inter-procedurally.
Differential Revision: https://reviews.llvm.org/D44120
llvm-svn: 327343
Implicit constructor conversions such as A a = B() are represented by
surrounding the constructor for B() with an ImplicitCastExpr of
CK_ConstructorConversion kind, similarly to how explicit constructor conversions
are surrounded by a CXXFunctionalCastExpr. Support this syntax pattern when
extracting the construction context for the implicit constructor that
performs the conversion.
Differential Revision: https://reviews.llvm.org/D44051
llvm-svn: 327096
For now. We should also add support for ConstructorConversion casts as presented
in the attached test case, but this requires more changes because AST around
them seems different.
The check was originally present but was accidentally lost during r326021.
Differential Revision: https://reviews.llvm.org/D43840
llvm-svn: 326402
When a lifetime-extended temporary is on a branch of a conditional operator,
materialization of such temporary occurs after the condition is resolved.
This change allows us to understand, by including the MaterializeTemporaryExpr
in the construction context, the target for temporary materialization in such
cases.
Differential Revision: https://reviews.llvm.org/D43483
llvm-svn: 326019
In order to bind a temporary to a const lvalue reference, a no-op cast is added
to make the temporary itself const, and only then the reference is taken
(materialized). Skip the no-op cast when looking for the construction context.
Differential Revision: https://reviews.llvm.org/D43481
llvm-svn: 326016
When a constructor of a temporary with a single argument is treated
as a functional cast expression, skip the functional cast expression
and provide the correct construction context for the temporary.
Differential Revision: https://reviews.llvm.org/D43480
llvm-svn: 326015
When constructing a temporary that is going to be lifetime-extended through a
MaterializeTemporaryExpr later, CFG elements for the respective constructor
can now be queried to obtain the reference to that MaterializeTemporaryExpr
and therefore gain information about lifetime extension.
This may produce multi-layered construction contexts when information about
both temporary destruction and lifetime extension is available.
Differential Revision: https://reviews.llvm.org/D43477
llvm-svn: 326014
Constructors of C++ temporary objects that have destructors now can be queried
to discover that they're indeed constructing temporary objects.
The respective CXXBindTemporaryExpr, which is also repsonsible for destroying
the temporary at the end of full-expression, is now available at the
construction site in the CFG. This is all the context we need to provide for
temporary objects that are not lifetime extended. For lifetime-extended
temporaries, more context is necessary.
Differential Revision: https://reviews.llvm.org/D43056
llvm-svn: 325210
When the current function returns a C++ object by value, CFG elements for
constructors that construct the return values can now be queried to discover
that they're indeed participating in construction of the respective return value
at the respective return statement.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 324952
Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.
This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in
iterator i = vector.begin();
Differential Revision: https://reviews.llvm.org/D42719
llvm-svn: 324798
CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.
CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.
Differential Revision: https://reviews.llvm.org/D42700
llvm-svn: 324796
Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.
Differential Revision: https://reviews.llvm.org/D42699
llvm-svn: 324794
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
Artem Dergachev