[cfe-dev] -Wunused-private-field distracted by side effects
Stephan Bergmann
sbergman at redhat.com
Wed Oct 15 06:41:58 PDT 2014
BaseAndFieldInfo::addFieldInitializer (lib/Sema/SemaDeclCXX.cpp) contains
> // Check whether this initializer makes the field "used".
> if (Init->getInit()->HasSideEffects(S.Context))
> S.UnusedPrivateFields.remove(Init->getAnyMember());
which filters out of the list of unused private member variables those
with initializers that potentially incur side effects. That is, in
> int f();
> class C {
> int i, j;
> public:
> C(): i(f()), j(1) {}
> };
clang++ -Wall will emit a -Wunused-private-field for j but not for i.
Is that behavior intended? (Member variables of class type, where the
constructor itself may have side effects, are already exempted from the
UnusedPrivateFields list via the InitializationHasSideEffects() check
elsewhere in lib/Sema/SemaDeclCXX.cpp.)
Of course, such a warning cannot in general be addressed by naively
removing the member variable along with any initializers, but that is no
different to e.g. -Wunused-variable, which does get emitted for
> int f();
> void g() {
> int i(f());
> }
One arcane legitimate reason to not emit a -Wunused-private-field could
be a case where f() needs to be called for side effects between
construction of two other members, as in
> int f();
> struct S1 { /*...*/ };
> struct S2 { /*...*/ };
> class C {
> S1 s1;
> int dummy;
> S2 s2;
> public:
> C(): s1(), dummy(f()), s2() {}
> };
but that could arguably be required to use a __attribute__((unused)).
Stephan
More information about the cfe-dev
mailing list