forked from OSchip/llvm-project
c9176072e6
In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123 |
||
---|---|---|
.. | ||
AnalysisDeclContext.cpp | ||
BodyFarm.cpp | ||
BodyFarm.h | ||
CFG.cpp | ||
CFGReachabilityAnalysis.cpp | ||
CFGStmtMap.cpp | ||
CMakeLists.txt | ||
CallGraph.cpp | ||
CocoaConventions.cpp | ||
Consumed.cpp | ||
Dominators.cpp | ||
FormatString.cpp | ||
FormatStringParsing.h | ||
LiveVariables.cpp | ||
Makefile | ||
ObjCNoReturn.cpp | ||
PostOrderCFGView.cpp | ||
PrintfFormatString.cpp | ||
ProgramPoint.cpp | ||
PseudoConstantAnalysis.cpp | ||
ReachableCode.cpp | ||
ScanfFormatString.cpp | ||
ThreadSafety.cpp | ||
UninitializedValues.cpp |