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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
