<div dir="ltr">Hi Nuno,<div><br></div><div>this looks like a cool warning. I tried it on chromium; it looks like the implementation could use some polishing.</div><div><br></div><div>* We have a DISALLOW_COPY_AND_ASSIGN macro that expands to a constructor name, to be places in a "private:" section to make a class not instantiatable ( <a href="https://code.google.com/p/chromium/codesearch#chromium/src/base/macros.h&l=45">https://code.google.com/p/chromium/codesearch#chromium/src/base/macros.h&l=45</a> ). The warning complains about these constructors. Maybe it shouldn't warn on declared-but-not-defined constructors / destructors / assignment operators?</div>
<div><br></div><div>* It complains about private functions that override pure virtual methods – but removing them leads to "can't instantiate class with pure virtual methods" errors.</div><div><br></div><div>
Nico</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 23, 2014 at 3:14 PM, Nuno Lopes <span dir="ltr"><<a href="mailto:nunoplopes@sapo.pt" target="_blank">nunoplopes@sapo.pt</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I would like to improve -Wunused-member-function to detect unused private methods, similarly to how -Wunused-private-fields works.<br>
I think clang should be able to flag a method if 1) it is unused, 2) all the methods of the class are defined in the TU, and 3) any of the following conditions holds:<br>
- The method is private.<br>
- The method is protected and the class is final.<br>
- The method is public and the class is in an anonymous namespace.<br>
<br>
I have a simple implementation in attach that can handle the first case (private methods) only.<br>
I'm not very happy with it, though. In particular I would like to move the logic somewhere else, so that we can reuse it from Codegen. And right now I'm not caching things properly.  Any suggestions to where this code belongs?  Should it go directly to Decl? (but that would imply adding a few fields for cache purposes).<br>

<br>
The second part of the plan is to mark all methods described previously (well, the used ones) with internal linkage. In my naive view it seems fine, but is this legal per the standard?  I think it can be an important optimization, since then LLVM can more freely inline and remove the symbols altogether.<br>

<br>
Any comments and suggestions are welcomed!<br>
<br>
Thanks,<br>
Nuno<br>
<br>
P.S.: I run the attached patch over the LLVM codebase and I already fixed a bunch of cases it detected (but left many still). So big code bases will certainly benefit from this analysis. Moreover, removing unused decls triggered more -Wunused-private-fields  warnings. <br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">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></blockquote></div><br></div>