summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis/temporaries-callback-order.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Re-enable lifetime extension for temporaries without destructors.Artem Dergachev2018-06-281-6/+1
| | | | | | | | | | | | | | | | When an object's class provides no destructor, it's less important to materialize that object properly because we don't have to model the destructor correctly, so previously we skipped the support for these syntax patterns. Additionally, fix support for construction contexts of "static temporaries" (temporaries that are lifetime-extended by static references) because it turned out that we only had tests for them without destructors, which caused us to regress when we re-introduced the construction context for such temporaries. Differential Revision: https://reviews.llvm.org/D47658 llvm-svn: 335796
* [analyzer] When creating a temporary object, properly copy the value into it.Artem Dergachev2017-03-281-0/+36
Adjustments should be considered properly; we should copy the unadjusted object over the whole temporary base region. If the unadjusted object is no longer available in the Environment, invalidate the temporary base region, and then copy the adjusted object into the adjusted sub-region of the temporary region. This fixes a regression introduced by r288263, that caused various false positives, due to copying only adjusted object into the adjusted region; the rest of the base region therefore remained undefined. Before r288263, the adjusted value was copied over the unadjusted region, which is incorrect, but accidentally worked better due to how region store disregards compound value bindings to non-base regions. An additional test machinery is introduced to make sure that despite making two binds, we only notify checkers once for both of them, without exposing the partially copied objects. This fix is a hack over a hack. The proper fix would be to model C++ temporaries in the CFG, and after that dealing with adjustments would no longer be necessary, and the values we need would no longer disappear from the Environment. rdar://problem/30658168 Differential Revision: https://reviews.llvm.org/D30534 llvm-svn: 298924
OpenPOWER on IntegriCloud