summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis/diagnostics/dtors.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Specify the C++ standard in more tests.Artem Dergachev2019-10-191-1/+1
| | | | | | Makes life easier for downstream developers with different default standard. llvm-svn: 375308
* [analyzer] ConditionBRVisitor: MemberExpr supportCsaba Dabis2019-05-291-4/+5
| | | | | | | | | | | | | | | | | Summary: - Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: cfe-commits, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D58206 llvm-svn: 362026
* [analyzer] Make sure base-region and its sub-regions are either all alive or ↵Artem Dergachev2019-01-181-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | all dead. SymbolReaper now realizes that our liveness analysis isn't sharp enough to discriminate between liveness of, say, variables and their fields. Surprisingly, this didn't quite work before: having a variable live only through Environment (eg., calling a C++ method on a local variable as the last action ever performed on that variable) would not keep the region value symbol of a field of that variable alive. It would have been broken in the opposite direction as well, but both Environment and RegionStore use the scanReachableSymbols mechanism for finding live symbols regions within their values, and due to that they accidentally end up marking the whole chain of super-regions as live when at least one sub-region is known to be live. It is now a direct responsibility of SymbolReaper to maintain this invariant, and a unit test was added in order to make sure it stays that way. Differential Revision: https://reviews.llvm.org/D56632 rdar://problem/46914108 llvm-svn: 351499
* [analyzer] pr38838, pr39976: Fix crash on diagnosing before implicit destructor.Artem Dergachev2019-01-101-0/+25
We need to be able to emit the diagnostic at PreImplicitCall, and the patch implements this functionality. However, for now the need for emitting such diagnostics is not all that great: it is only necessary to not crash when emitting a false positive due to an unrelated issue of having dead symbol collection not working properly. Coming up with a non-false-positive test seems impossible with the current set of checkers, though it is likely to be needed for good things as well in the future. Differential Revision: https://reviews.llvm.org/D56042 rdar://problem/46911462 llvm-svn: 350907
OpenPOWER on IntegriCloud