[patch] [libcxx] #warning

[G M]

On Wed, Sep 18, 2013 at 6:20 AM, Reid Kleckner <rnk at google.com> wrote:

> Seems fine.  Howard can decide on the fine points of how to format this or
> macro-ify this.
>


> +#define _LIBCPP_TOSTRING2(x) #x
> +#define _LIBCPP_TOSTRING(x) _LIBCPP_TOSTRING2(x)
>
I tried to use _LIBCPP_CONCAT but it didn't work with __LINE__, at least on
VS.
I'd like to have a stringify macro that does work with __LINE__ for a
possible future patch too.


> +
> +#ifndef _LIBCPP_MSVC
> +#   define _LIBCPP_DO_PRAGMA(x) _Pragma(#x)
> +// Not supported by GCC 4.2.1. Issues a note with gcc and a warning with
> clang++.
>
> Does libc++ support gcc 4.2.1?
>
> Not according to the docs page, here:
http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-tools
.
The comment was to remind myself while I was researching. I think I should
remove it.

> +#   define _LIBCPP_WARNING(x) _LIBCPP_DO_PRAGMA(message(x))
> +#else
> +#   define _LIBCPP_DO_PRAGMA(x) __pragma(#x)
> +// Issue a note not a warning in the command line compiler diagnostic.
> Appears as a warning in VS.
> +#   define _LIBCPP_WARNING(x) __pragma(message(__FILE__ "("
> _LIBCPP_TOSTRING(__LINE__) ") : warning note: " x))
> +#endif
>
>
> -    #warning uncaught_exception not yet implemented
> +#   ifndef _LIBCPP_MSVC
> +#       warning uncaught_exception not yet implemented
> +#   else
> +        _LIBCPP_WARNING("uncaught_exception not yet implemented")
> +#   endif
>
> Presumably you don't wish to use _LIBCPP_WARNING because it will print
> macro backtraces with clang, and that is undesirable?  I'd like to
> eliminate the #ifdef clutter if possible.
>

Correct. Yes I wasn't happy about the #ifdef clutter either. I asked Howard
about this originally and his preference was (if I recall correctly) that
he was open to a macro if it would warn everywhere, certainly, gcc and
clang, but I couldn't achieve that goal. I was also concerned myself about
other systems I can't test with, I felt they would more likely support
#warning than some kind of fancy _Pramga, so I started feeling the safe
ugly option might be better, and then when I saw the macro verbosity clang
spewed, that sealed the choice to go #ifdef ugly. My notes explain that in
detail in my prior message.

If anyone can fix that verbosity and if people decide they are ok that we
just note rather than warn, I'm happy to revert the #ifdef to use the
macro. But that still leaves us open to systems that don't support _pragma
message but do support #warning. I don't know that such systems exist
that we support. This is a time for anyone to speak out.I'm assuming that
club is none.

I'm reading things currently like this: 1) my patch is ugly as necessary
but otherwise good to go subject to removing the gcc 4.2 comment to avoid
distraction. 2) If someone can solve the clang++ macro verbosity problem
and people agree that a gcc note rather than a warning is acceptable to us,
we can use the macro. But 3)  If clang is also changed to be totally
compatible with gcc and is changed to note too, then people have to agree a
note is acceptable on clang too, but if that happens we can use the macro
everywhere and remove the #ifdef ugliness completely.

The only caveat then left would be if libcxx uses a #warning somewhere and
<__config> isn't included implicitly or explicitly. I'm not aware of
anywhere that happens and I assume it would be a bug, so hopefully that
isn't an issue.


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130918/7502bc03/attachment.html>