<div class="gmail_quote">On Tue, Aug 9, 2011 at 4:58 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1t1">(1) We aim to gradually put all existing warnings under a -W flag.  Multiple (related) warnings can be placed under the same -W flag (as they are often done now), but the main idea is to allow users to control these warnings.<br>

<br>
(2) We require all new warnings to include a -W flag the moment they are added to Clang.  We can enforce this by using diagtool in our tests (e.g., verify that the set of warnings without flags hasn't changed).</div>
</blockquote></div><br><div>I love this. It's been unwritten policy for the warnings we're adding, and I think it'd be good to do it generally.</div><div><br></div><div>I'll particularly like that we can test and ensure that new warnings are always given a flag. =] Hopefully we can help move some of the warnings under flags that aren't yet.</div>
<div><br></div><div><br></div><div>Regarding the unique-ID-per-warning discussion (which was a bit of a tangent), I think more data in the already busy warning messages would be unfortunate. As we already print the flag name in most cases, I'd rather see documentation use the flag name as a searchable bucket, and then a list of example warning text and code triggering it so that people can quickly find the warning they're hitting. Then we might provide facilities to re-generate the documentation by re-running Clang over the examples, thus easing the process of keeping the documentation up to date with the latest spelling of the message.</div>