[cfe-dev] Compile errors when building kde-runtime

[David Blaikie]

On Fri, Jun 1, 2012 at 3:49 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote:

> On Tue, May 22, 2012 at 11:36 PM, David Blaikie <dblaikie at gmail.com>
>  wrote:
>
>
>> For what it's worth, -fixit mode only applies fixits on the warning
>> itself. Fixits on notes are never automatically applied (as far as I
>> know/understand) so that's where semantic-changing fixits can be
>> found, in any order.
>>
>> Very few warnings have fixits on them directly for this reason.
>
>
> Sorry for not replying sooner. This warning is definitely missing some
> notes, but if I understand you correctly fixits are also fine?


I'm not sure you've understood the concepts correctly - fixits and notes
aren't alternatives, as such:
Clang emits diagnostics
There are 3 main kinds of diagnostics: warnings, errors, and notes
Notes usually follow warnings or errors and provide extra information
FixIts are associated with a diagnostic (a warning, error, or note).

So if you compile a simple parentheses violation:
int main() { int i; if (i = 3) ; }

You'll see the following output:

/tmp/webcompile/_1316_0.cc:1:27: warning: using the result of an
assignment as a condition without parentheses [-Wparentheses]
int main() { int i; if (i = 3) ; }
~~^~~/tmp/webcompile/_1316_0.cc:1:27: note: place parentheses around
the assignment to silence this warning
int main() { int i; if (i = 3) ; }                          ^
              (    )/tmp/webcompile/_1316_0.cc:1:27: note: use '==' to
turn this assignment into an equality comparison
int main() { int i; if (i = 3) ; }                          ^
                ==

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.

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).

They won't be applied


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.


> but they still offer some useful information about the exact code
> transformations that are needed to make the warning go away.
>
> One more thing, the text "replace parentheses with an initializer to
> declare a variable" is copied from 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?
>

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))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120601/6003e20c/attachment.html>