summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core/Store.cpp
diff options
context:
space:
mode:
authorJordan Rose <jordan_rose@apple.com>2012-07-26 20:04:05 +0000
committerJordan Rose <jordan_rose@apple.com>2012-07-26 20:04:05 +0000
commita4c0d21f4285c69bbe4a5ab53af49350d40446d5 (patch)
tree0c38b9621ce1c1a1f56fbcd92b265851b0b22ec6 /clang/lib/StaticAnalyzer/Core/Store.cpp
parentc5d852447b7cfbdc4ca189dbb42972e43dfaade4 (diff)
downloadbcm5719-llvm-a4c0d21f4285c69bbe4a5ab53af49350d40446d5.tar.gz
bcm5719-llvm-a4c0d21f4285c69bbe4a5ab53af49350d40446d5.zip
[analyzer] Show paths for destructor calls.
This modifies BugReporter and friends to handle CallEnter and CallExitEnd program points that came from implicit call CFG nodes (read: destructors). This required some extra handling for nested implicit calls. For example, the added multiple-inheritance test case has a call graph that looks like this: testMultipleInheritance3 ~MultipleInheritance ~SmartPointer ~Subclass ~SmartPointer ***bug here*** In this case we correctly notice that we started in an inlined function when we reach the CallEnter program point for the second ~SmartPointer. However, when we reach the next CallEnter (for ~Subclass), we were accidentally re-using the inner ~SmartPointer call in the diagnostics. Rather than guess if we saw the corresponding CallExitEnd based on the contents of the active path, we now just ask the PathDiagnostic if there's any known stack before popping off the top path. (A similar issue could have occured without multiple inheritance, but there wasn't a test case for it.) llvm-svn: 160804
Diffstat (limited to 'clang/lib/StaticAnalyzer/Core/Store.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud