<br><br><div class="gmail_quote">On Fri, Jun 1, 2012 at 3:49 AM, Nikola Smiljanic <span dir="ltr"><<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, May 22, 2012 at 11:36 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br></div>For what it's worth, -fixit mode only applies fixits on the warning<br>itself. Fixits on notes are never automatically applied (as far as I<br>know/understand) so that's where semantic-changing fixits can be<br>
found, in any order.<br><br>Very few warnings have fixits on them directly for this reason.</blockquote></div></div><div><br></div>Sorry for not replying sooner. This warning is definitely missing some notes, but if I understand you correctly fixits are also fine?</blockquote>
<div><br></div><div>I'm not sure you've understood the concepts correctly - fixits and notes aren't alternatives, as such:<br>Clang emits diagnostics<br>There are 3 main kinds of diagnostics: warnings, errors, and notes<br>
Notes usually follow warnings or errors and provide extra information<br>FixIts are associated with a diagnostic (a warning, error, or note).<br><br>So if you compile a simple parentheses violation:<br>int main() { int i; if (i = 3) ; }<br>
<br>You'll see the following output:<br><pre><span class="terminalStyle1" style="font-weight:bold">/tmp/webcompile/_1316_0.cc:1:27: </span><span class="terminalStyle0"></span><span class="terminalStyle135" style="color:rgb(255,0,255);font-weight:bold">warning: </span><span class="terminalStyle0"></span><span class="terminalStyle1" style="font-weight:bold">using the result of an assignment as a condition without parentheses [-Wparentheses]</span><span class="terminalStyle0">
int main() { int i; if (i = 3) ; }
</span><span class="terminalStyle132" style="color:green;font-weight:bold"> ~~^~~
</span><span class="terminalStyle0"></span><span class="terminalStyle1" style="font-weight:bold">/tmp/webcompile/_1316_0.cc:1:27: </span><span class="terminalStyle0"></span><span class="terminalStyle130" style="color:gray;font-weight:bold">note: </span><span class="terminalStyle0">place parentheses around the assignment to silence this warning</span><span class="terminalStyle0">
int main() { int i; if (i = 3) ; }
</span><span class="terminalStyle132" style="color:green;font-weight:bold"> ^
</span><span class="terminalStyle0"></span><span class="terminalStyle032" style="color:green"> ( )
</span><span class="terminalStyle0"></span><span class="terminalStyle1" style="font-weight:bold">/tmp/webcompile/_1316_0.cc:1:27: </span><span class="terminalStyle0"></span><span class="terminalStyle130" style="color:gray;font-weight:bold">note: </span><span class="terminalStyle0">use '==' to turn this assignment into an equality comparison</span><span class="terminalStyle0">
int main() { int i; if (i = 3) ; }
</span><span class="terminalStyle132" style="color:green;font-weight:bold"> ^
</span><span class="terminalStyle0"></span><span class="terminalStyle032" style="color:green"> ==</span></pre></div><div>Notice that the fixit hints are attached to the two proceeding notes, not the warning itself. Technically it would be valid to attach the suppression fix to the original warning (since it doesn't change the program semantics) but that would give the false impression that that's the more likely fix, so we prefer to put them both on equal footing by attaching them to their own notes.<br>
<br>I know of one warning (the NULL conversion warning (eg: void func(int); func(NULL); -> suggest replacing NULL with 0)) that issues a fixit on a warning directly, but that's because it can match the semantics exactly & there's no real alternative there (if the user got it wrong, chances are they need an entirely different function call, or some other arguments - nothing we can really guess at).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> They won't be applied</blockquote><div><br></div><div>They won't be applied automatically if they're attached to a note. If they're attached to a warning (at least if that warning is elevated to an error via -Werror) they can be applied automatically, which can be probematic if the fixit changes semantics.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but they still offer some useful information about the exact code transformations that are needed to make the warning go away.<div>
<br></div><div>One more thing, the text <span style="white-space:pre-wrap">"replace parentheses with an initializer to declare a variable" is copied from </span><span style="white-space:pre-wrap">DiagnosticSemaKinds.td verbatim. It's needed in the ParseTentative.cpp which knows nothing about definitions in Sema, so I'm guessing that there's no better way to solve this than to have the same wording in two places?</span><br>
</div>
</blockquote></div><br>Not sure about the answer to this off-hand. & I've lost most of my mental context for this thread - but I have wanted to improve/see improvements for our vexing parse warning for a while now (it'd be great if it were higher confidence for the more common vexing parses so we could use it at global scope and so we could suggest fixits of {} or extra (), or some way to mutate the declaration to make it an unambiguous declaration (such as naming a parameter))