<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 2:10 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  If I understand the issue correctly, and from reading PR17053, the problem is that the main file in the translation unit would have a structure similar to a header guard but it should not be considered a header guard.  This patch does not fix that issue.  Instead, it looks at the edit distance between #define and #ifndef macro names.  This only coincidentally fixes the examples given.  The test case also does not follow the examples as it is still inside a header, not the main file.<br>

<br>
  It would be better to detect if the lexer is at the top most file and skip the diagnostic then.<br>
<div class="im"><br>
<br>
================<br>
Comment at: lib/Lex/PPLexerChange.cpp:280<br>
@@ +279,3 @@<br>
</div><div class="im">+              << ControllingMacro<br>
+              << FixItHint::CreateReplacement(<br>
+                                              CurPPLexer->MIOpt.GetDefinedLocation(),<br>
</div>----------------<br>
<div class="im">Ismail Pazarbasi wrote:<br>
> I haven't tried thoroughly, but I guess it'd be better to print the fix-it on the warning instead of the note, because clang-check will ignore the note (and I need clang-check to apply the fixit).<br>
</div>This seems like a valid point.  There is only one suggestion, so it should be placed in the warning instead of the note, but that change should go in a separate patch.</blockquote><div><br></div><div>Generally we don't put semantic-changing fixits on warnings directly as, if they are promoted to error, the fixit may be automatically applied & change the semantics of the program (the post-fixit'd code will differ in semantics to the compiled code/output).  </div>
</div></div></div>