summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorKristof Umann <dkszelethus@gmail.com>2018-08-21 12:16:59 +0000
committerKristof Umann <dkszelethus@gmail.com>2018-08-21 12:16:59 +0000
commitb59b45e7f1bd7486d8d30bd5c08f08c4b71dcca9 (patch)
tree3aa1fb48b00fc8343bd9a55000f434c8d908952b /clang/lib/Frontend/CompilerInvocation.cpp
parent1678ef6eb36709190f5b667b5a0cb4fcec6dd9c6 (diff)
downloadbcm5719-llvm-b59b45e7f1bd7486d8d30bd5c08f08c4b71dcca9.tar.gz
bcm5719-llvm-b59b45e7f1bd7486d8d30bd5c08f08c4b71dcca9.zip
[analyzer][UninitializedObjectChecker] Explicit namespace resolution for inherited data members
For the following example: struct Base { int x; }; // In a different translation unit struct Derived : public Base { Derived() {} }; For a call to Derived::Derived(), we'll receive a note that this->x is uninitialized. Since x is not a direct field of Derived, it could be a little confusing. This patch aims to fix this, as well as the case when the derived object has a field that has the name as an inherited uninitialized data member: struct Base { int x; // note: uninitialized field 'this->Base::x' }; struct Derived : public Base { int x = 5; Derived() {} }; Differential Revision: https://reviews.llvm.org/D50905 llvm-svn: 340272
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud