[cfe-commits] Clang change to detect and warn about unused private members
djasper at google.com
Thu Jan 26 18:24:52 PST 2012
has anyone had a chance to look at this?
On Wed, Jan 18, 2012 at 10:28 PM, Daniel Jasper <djasper at google.com> wrote:
> here is a new version of the proposed change. Changes:
> 1) The warning is more conservative. Members of a class-type can now only
> count as unused if a trivial default constructor and a trivial destructor
> are used (as these don't have side-effects). A smarter analysis for
> side-effect-free constructors and destructors can follow. This prevents
> false positives on RAII-style classes.
> 2) The warning gives up if a class has a template friend (specializations
> of this friend could use any unused member).
> 3) Only instantiations of template classes are analyzed, not the template
> classes themselves (this was a major source of false positives).
> 4) Testcase is include in the patch this time.
> Please let me know, what you think!
> On Thu, Jan 12, 2012 at 7:26 PM, Daniel Jasper <djasper at google.com> wrote:
>> Hi Nico,
>> comments inline.
>> On Wed, Jan 11, 2012 at 10:49 PM, Nico Weber <thakis at chromium.org> wrote:
>>> Hi Daniel,
>>> On Wed, Jan 11, 2012 at 1:11 AM, Daniel Jasper <djasper at google.com>
>>> > Hi,
>>> > the attached change is designed to detect and warn about private unused
>>> > members of C++ classes. It checks whether a class is fully defined in
>>> > current translation unit, i.e. all methods are either defined or pure
>>> > virtual and all friends are defined. Otherwise, the private member
>>> could be
>>> > used by a function defined in another translation unit.
>>> that's a cool warning! Here are a few cases where it flags false
>>> positives (it finds tons of true positives too, but those are boring
>>> :-) ).
>>> It flags |stackArray| in ICU's cmemory.h. This is declared for storage
>>> and accessed through pointer aliasing, probably not much that can be
>>> done about this:
>> As you said in the other email, it is the wrong code line and I think, it
>> is correct to warn about the other |stackArray|.
>>> In flags StaticResource::instance_ in v8's utils.h:
>>> This is supposed to be accessed through the class below, Access, which
>>> is a friend of utils.h. Do you check if any friends use private
>> Yes, I check friends. This is a bug, I know why it happens (it is because
>> of the dependent templates) and I will fix it.
>>> In chromium itself, it flags ShadowingAtExitManager member variables.
>>> This is basically a RAII class which only exists to call a protected
>>> superclass constructor, and which only exists if UNIT_TESTS is
>>> So maybe the "constructor without arguments" heuristic could be
>>> tweaked to exclude constructors that call superclass constructors with
>>> (Here's another RAII class whose constructor takes 0 arguments:
>> I have changed it to be more conservative (I will send a new patch once I
>> have fixed the bug mentioned above). It now only accepts members without
>> initializer or with an argument-less initializer, if the field's type has a
>> trivial default constructor and a trivial destructor. Unfortunately, we now
>> also miss a lot of true positives, but I guess the false positives are
>> worse, especially because there is no easy way to explicitly suppress the
>> warning for these cases within the standard syntax.
>>> (This is not an exhaustive list, just the things I found after a quick
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits