Hello Chandler,<br><br>A bit sideway with regard to your question... I am rather surprised that the fixit hint in the case mentionned would suggest replacing `struct` by `class` in:<br><br>---- x.cc ----<br>
class X;<br>
struct X {<br>
  X() {}<br>
};<br>
X x;<br>
----<br><br>It is more likely that the forward declaration is wrong rather than the definition itself, since the definition affects much more (as you noted, all the actual usages of the object itself).<br><br>I would think therefore that the correct fixit hint would be to suggest to replace the `class X;` by `struct X;`, and there won't be any issue in case the -fixit flag is passed then.<br>
<br>What do you think ?<br><br>Matthieu.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Date: Sun, 10 Apr 2011 01:37:56 -0700<br>
From: Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
Subject: [cfe-dev] Clarifying the roles and requirements on fixit<br>
        hints in        diagnostics<br>
To: clang-dev Developers <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Message-ID: <BANLkTi=5_iB0ZkFYw8jjqNMj=S78=<a href="mailto:e5_PA@mail.gmail.com">e5_PA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I know I have been confused on more than one occasion about the precise<br>
requirements for issuing a fixit hint. After several IRC conversations<br>
(thanks to those that participated) I think I've got a decent understanding,<br>
and I'd like to add some sections to the Clang documentation which spell<br>
this out for future reference. A brief summary of my understanding lest I<br>
have gotten confused again:<br>
<br>
1) Fixit hints attached to an error diagnostic *must* recover the<br>
parse/semantic analysis/etc as if the fix had been applied. This won't ever<br>
miscompile code as the compilation cannot succeed after issuing an error<br>
unless Clang has been asked to automatically apply these fixes, in which<br>
case the compile will succeed, and accurately reflect the (newly updated)<br>
code.<br>
<br>
2) Fixit hints on notes *must not* have any impact on the compilation. The<br>
also are not automatically applied to the code by the -fixit flag.<br>
<br>
3) There can be only one hint attached to a diagnostic, and thus if the hint<br>
is attached to the error or warning diagnostic it must be an extremely<br>
confident fix with no other viable candidates. When there are multiple<br>
viable candidate fixes, they should be presented as multiple fixit hint<br>
bearing notes.<br>
<br>
<br>
The one area this doesn't cover are fixit hints attached to warnings. These<br>
are trickier. Previously, it has been suggested that they should follow the<br>
same rules as those attached to errors, but that has some serious problems.<br>
Suppose this is the approach is used for -Wmismatched-tags:<br>
---- x.cc ----<br>
class X;<br>
struct X {<br>
  X() {}<br>
};<br>
X x;<br>
----<br>
This code is well formed, but the warning will suggest replacing 'struct'<br>
with 'class'. Doing so makes the code ill-formed. If we recover as-if the<br>
fixit hint were applied, we would error on this code when the warning is<br>
turned on, which seems rather surprising. ;] If we don't recover as if the<br>
fixit hint were applied, and run Clang with -fixit, we accept the code, but<br>
then alter the code to a text sequence which if we recompile is rejected.<br>
Again, rather surprising. Currently, Clang's warnings which have fixit hints<br>
attached have a mixture of these policies, but more often follow the latter<br>
policy of no recovery. For some, this is a moot point -- the code parses the<br>
same either way and the hint merely removes redundant text or adds<br>
clarifying text. The question is what *should* the rest of the warnings with<br>
fixit hints do?<br>
<br>
One option would be to require that warnings with direct fixit hints *can*<br>
recover as if the hint were applied, but provide a hook so that the recovery<br>
is only performed when that warning is promoted to an error or when running<br>
with -fixit in effect.<br>
<br>
A second option is to require that recovery not be performed for warning<br>
fixit hints and that -fixit not apply them automatically. Essentially treat<br>
them the same as note fixit hints.<br>
<br>
I prefer the second option as it is simpler, and I think provides a better<br>
user experience. There are several warnings with a note attached to them<br>
purely to provide a fixit hint without recover or automatic application. The<br>
output would be simpler and more clear if these could be directly attached<br>
to the warnings.<br>
<br>
Thoughts? Once this is a bit more clear, I'll start fixing documentation.<br>
</blockquote></div><br>