Sure.. On Wed, Feb 1, 2012 at 10:27 AM, Chandler Carruth <[email protected]>wrote:
> Can you re-send the patch? that way patchwork can track it. > > On Thu, Jan 26, 2012 at 6:24 PM, Daniel Jasper <[email protected]> wrote: > >> Hi, >> >> has anyone had a chance to look at this? >> >> Kind regards, >> Daniel >> >> >> On Wed, Jan 18, 2012 at 10:28 PM, Daniel Jasper <[email protected]>wrote: >> >>> Hi, >>> >>> 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! >>> >>> Cheers, >>> Daniel >>> >>> >>> On Thu, Jan 12, 2012 at 7:26 PM, Daniel Jasper <[email protected]>wrote: >>> >>>> Hi Nico, >>>> >>>> comments inline. >>>> >>>> On Wed, Jan 11, 2012 at 10:49 PM, Nico Weber <[email protected]>wrote: >>>> >>>>> Hi Daniel, >>>>> >>>>> On Wed, Jan 11, 2012 at 1:11 AM, Daniel Jasper <[email protected]> >>>>> wrote: >>>>> > 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 the >>>>> > 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: >>>>> >>>>> http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/icu/source/common/cmemory.h&exact_package=chromium&q=file:cmemory.h&l=285 >>>> >>>> >>>> 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: >>>>> >>>>> http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/v8/src/utils.h&exact_package=chromium&q=file:v8/src/utils.h&l=300 >>>>> 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 >>>>> variables? >>>>> >>>> >>>> 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 >>>>> defined: >>>>> http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/at_exit.h&l=71 >>>>> So maybe the "constructor without arguments" heuristic could be >>>>> tweaked to exclude constructors that call superclass constructors with >>>>> arguments? >>>>> (Here's another RAII class whose constructor takes 0 arguments: >>>>> >>>>> http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/logging_unittest.cc&exact_package=chromium&q=logstatesaver&l=26 >>>>> ) >>>>> >>>> >>>> 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. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>>> >>>>> (This is not an exhaustive list, just the things I found after a quick >>>>> look.) >>>>> >>>>> Nico >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >
clangpatch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
