Sure..<br><br><div class="gmail_quote">On Wed, Feb 1, 2012 at 10:27 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you re-send the patch? that way patchwork can track it.<div><br><div class="gmail_quote"><div><div class="h5">On Thu, Jan 26, 2012 at 6:24 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi,<div><br></div><div>has anyone had a chance to look at this?</div><div><br></div><div>
Kind regards,</div><div>Daniel<div>
<div><br><br><div class="gmail_quote">On Wed, Jan 18, 2012 at 10:28 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div><br></div><div>here is a new version of the proposed change. Changes:</div><div><br></div><div>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.</div>
<div>2) The warning gives up if a class has a template friend (specializations of this friend could use any unused member).</div><div>3) Only instantiations of template classes are analyzed, not the template classes themselves (this was a major source of false positives).</div>
<div>4) Testcase is include in the patch this time.</div><div><br></div><div>Please let me know, what you think!</div><div><br></div><div>Cheers,<br>Daniel</div><div><div><div><br><br><div class="gmail_quote">
On Thu, Jan 12, 2012 at 7:26 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nico,<div><br></div><div>comments inline.<br><br><div class="gmail_quote"><div>On Wed, Jan 11, 2012 at 10:49 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<div><br>
On Wed, Jan 11, 2012 at 1:11 AM, Daniel Jasper <<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>> wrote:<br>
> Hi,<br>
><br>
> the attached change is designed to detect and warn about private unused<br>
> members of C++ classes. It checks whether a class is fully defined in the<br>
> current translation unit, i.e. all methods are either defined or pure<br>
> virtual and all friends are defined. Otherwise, the private member could be<br>
> used by a function defined in another translation unit.<br>
<br>
</div>that's a cool warning! Here are a few cases where it flags false<br>
positives (it finds tons of true positives too, but those are boring<br>
:-) ).<br>
<br>
It flags |stackArray| in ICU's cmemory.h. This is declared for storage<br>
and accessed through pointer aliasing, probably not much that can be<br>
done about this:<br>
<a href="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" target="_blank">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</a></blockquote>
<div><br></div></div><div>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|.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In flags StaticResource::instance_ in v8's utils.h:<br>
<a href="http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/v8/src/utils.h&exact_package=chromium&q=file:v8/src/utils.h&l=300" target="_blank">http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/v8/src/utils.h&exact_package=chromium&q=file:v8/src/utils.h&l=300</a><br>
This is supposed to be accessed through the class below, Access, which<br>
is a friend of utils.h. Do you check if any friends use private<br>
variables?<br></blockquote><div><br></div></div><div>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.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In chromium itself, it flags ShadowingAtExitManager member variables.<br>
This is basically a RAII class which only exists to call a protected<br>
superclass constructor, and which only exists if UNIT_TESTS is<br>
defined: <a href="http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/at_exit.h&l=71" target="_blank">http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/at_exit.h&l=71</a><br>
So maybe the "constructor without arguments" heuristic could be<br>
tweaked to exclude constructors that call superclass constructors with<br>
arguments?<br>
(Here's another RAII class whose constructor takes 0 arguments:<br>
<a href="http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/logging_unittest.cc&exact_package=chromium&q=logstatesaver&l=26" target="_blank">http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/logging_unittest.cc&exact_package=chromium&q=logstatesaver&l=26</a><br>
)<br></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>Cheers,<br>Daniel</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(This is not an exhaustive list, just the things I found after a quick look.)<br>
<span><font color="#888888"><br>
Nico<br>
</font></span></blockquote></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
<br></div></div><div class="im">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br>