<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 20, 2012, at 11:53 AM, Chandler Carruth wrote:</div><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="HOEnZb"><div class="h5">> Thanks John. That's sums it up well. Right now the workflow people know is to pass -Wno- to silence a warning, and seeing the warning flag in the diagnostic. This flag is completely different from that simple workflow.<br>
><br>
> My understanding was that ever clang warning should be controllable under a -W flag. That's not the case with all -pedantic warnings.<br>
<br>
</div></div>I'd also like it if we never produced [-pedantic] in a diagnostic as the warning flag. [-Wpedantic] would be much more consistent.</blockquote><div><br></div><div>I completely agree with presenting the user *only* with '-Wpedantic' and variants.</div>
<div><br></div><div>That said, for compatibility, I think we should support '-pedantic' and '-no-pedantic' as aliases for '-Wpedantic' and '-Wno-pedantic' respectively. I don't really like the flags either, but I'm not thrilled about explaining that the solution to negate '-pedantic' is to pass '-Wno-pedantic'. =/</div>
</div></font></div></blockquote><br></div><div>Yes, makes sense to me.</div><div><br></div><div>-Chris</div><br></body></html>