[PATCH] Header guard warning is too agressive

David Blaikie dblaikie at gmail.com
Wed Sep 11 14:15:21 PDT 2013

On Wed, Sep 11, 2013 at 2:10 PM, Richard Trieu <rtrieu at google.com> wrote:

>   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.
>   It would be better to detect if the lexer is at the top most file and
> skip the diagnostic then.
> ================
> Comment at: lib/Lex/PPLexerChange.cpp:280
> @@ +279,3 @@
> +              << ControllingMacro
> +              << FixItHint::CreateReplacement(
> +
>  CurPPLexer->MIOpt.GetDefinedLocation(),
> ----------------
> Ismail Pazarbasi wrote:
> > 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).
> 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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130911/1895677b/attachment.html>

More information about the cfe-commits mailing list