Proper modeling still remains to be done.
Note that BindingDecl#getHoldingVar() is almost always null, and this should probably be handled by dealing with DecompositionDecl beforehand.
rdar://36852163
Differential D44183
[analyzer] Don't crash with assertion failure on structured bindings george.karpenkov on Mar 6 2018, 6:26 PM. Authored by
Details Proper modeling still remains to be done. rdar://36852163
Diff Detail Event TimelineComment Actions It seems that semantically this construct creates a copy of s - let's refer to it as _s (it could be represented as a VarRegion because DecompositionDecl is a sub-class of VarDecl) - and the lvalue of a would be a sub-region within _s based on the BindingDecl which would be represented via a completely new kind of DeclRegion (because BindingDecl is not a sub-class of FieldDecl, which is good, because otherwise we would have jumped into the pointer-to-member handling code, which is not correct). As far as i understand, decompositions may also be user-defined, and in this case they might require different regions to represent the result (and also call expressions in the CFG to inline user-defined implementations).
|
You can add clang_analyzer_eval or clang_analyzer_warnIfReached that demonstrates the current incorrect behavior that should be fixed by addressing the FIXME. Eg., we don't understand that a is equal to 1, so clang_analyzer_eval(a == 1) would be UNKNOWN, and clang_analyzer_warnIfReached() on the else-branch would warn.