[cfe-commits] r152940 - in /cfe/trunk: lib/Sema/SemaChecking.cpp test/SemaCXX/conversion.cpp

Chandler Carruth chandlerc at google.com
Fri Mar 16 15:38:23 PDT 2012


David, I don't think is really the right approach...

On Fri, Mar 16, 2012 at 1:30 PM, David Blaikie <dblaikie at gmail.com> wrote:

> Suppress macro expansion of NULL in NULL warnings.
>

This only suppresses it in one warning though, not in all warnings. I don't
see why we don't want to always suppress the NULL macro expansion. I'd be
interested in moving this into the logic for generating macro expansion
notes themselves. We could potentially generalize it to other
standard-defined macros if beneficial.

For "int i = NULL;" we would produce:
>
> null.cpp:5:11: warning: implicit conversion of NULL constant to integer
> [-Wconversion]
>  int i = NULL;
>      ~   ^~~~
> null.cpp:1:14: note: expanded from macro 'NULL'
> \#define NULL __null
>              ^~~~~~
>
> But we really shouldn't trace that macro expansion back into the header,
> yet we
> still want macro back traces for code like this:
>
> \#define FOO NULL
> int i = FOO;
>
> or
>
> \#define FOO int i = NULL;
> FOO
>

What about the case I'm more worried about:

#undef NULL
#define NULL FOO

We need to predicate this on the actual contents of the NULL macro.

Also, doing the checks you're already doing, much less my suggested extra
checking, shouldn't be done if the diagnostic is suppressed for any reason,
which would also argue for sinking it into the macro expansion layer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120316/d0052a61/attachment.html>


More information about the cfe-commits mailing list