[PATCH] D48436: [analyzer][UninitializedObjectChecker] Fixed a false negative by no longer filtering out certain constructor calls
Artem Dergachev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Jul 12 12:43:50 PDT 2018
NoQ added a comment.
> A call to `Derived::Derived()` previously emitted no warnings. However, with these changes, a warning is emitted for `Base::a`.
Yep, a heuristic to skip implicit constructor declarations during analysis and make the first explicit constructor responsible for initializing its bases/fields that have been constructed via autogenerated constructors seems reasonable. With that i guess you'll still have to deep-scan fields and bases, which prevents us from simplifying our code. I'll think about that a bit more; it might be worth it to track such deferred subregions in a state trait and drain it whenever we pop back to an explicit constructor.
================
Comment at: lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp:681-689
+ Optional<nonloc::LazyCompoundVal> OtherObject =
+ getObjectVal(OtherCtor, Context);
+ if (!OtherObject)
+ continue;
+
+ // If the CurrentObject is a field of OtherObject, it will be analyzed
+ // during the analysis of OtherObject.
----------------
It seems safer to look at `CXXConstructExpr::getConstructionKind()`.
Taking a `LazyCompoundVal` and converting it back to a region is definitely a bad idea because the region within `LazyCompoundVal` is completely immaterial and carries no meaning for the value represented by this `SVal`; it's not necessarily the region you're looking for.
https://reviews.llvm.org/D48436
More information about the cfe-commits
mailing list