[patch] [libcxx] #warning

[Reid Kleckner]

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)
+
+#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?

+#   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.


On Mon, Sep 16, 2013 at 8:49 PM, G M <gmisocpp at gmail.com> wrote:

> Hello Everyone
>
> Attached is a patch to libcxx to remove the errors relating to the use of
> #warning when compiling using MS's compiler cl.exe
>
> It introduces a macro to __config _LIBCPP_WARNING for use with the MS
> compiler and updates all references of #warning to use it when compiling
> with the real MS compiler.
>
> The macro is compatible with clang++ and g++ and can be used there too
> if you understand and accept the slight incompatibilities, which I'll
> explain. From my investigations, if I am correct, the limitations of this
> macro and #warning and #pragma message are:
>
> * #warning doesn't work on any version of visual studio. In fact it means
> something different to MS and it's used extensively; so they will likely
> never standardize on the use case here as they can't IMHO.
>
> * #pragma message DOES work for clang++/g++/cl, BUT not completely
> compatibly:
>
> The differences in #pragma message are:
>
> * For g++, it generates a note, which is logical to me on the basis
> that if you want a warning, you have #warning from gcc's perspective.
> * For MSVC, it generates a note like gcc (or appears to) at the command
> line, but the message does show up in the warning lists of Visual Studio
> but as far as I can tell it's not really a true warning. The message
> doesn't include a file or line number on the command line (and that may be
> to too true in the IDE I forgot to check) but on the command line, it's too
> brief and is easy to miss if used in a raw way.
>
> * For clang++, #pragma message generates a warning not a message/note like
> g++/cl. This is a very practical implementation, but a little
> misleading given the name and isn't quite as compatible with gcc as one
> might expect. Given these aspects, it's arguable that clang++ should be
> changed to issue a note instead of warning to match gcc, but I'm not
> advocating that change.
>
> * clang++ is however quite verbose in it's formatting of #pragma message
> and #warning compared to g++. I think too verbose. It's so verbose when
> used as a macro in fact that I think it's undesirable. IMHO, I think in
> this formatting aspect, clang++ should be changed to match g++.
>
> It would be better IMHO if it was tuned to remove the macro info and show
> it only if there is an actual error or problem in the formulation and use
> in the macro. If not, I think the use of the macro should appear in
> indistinguishable in use as it is in g++. And only be expanded in full if
> there is a real error, or another option is applied to force it for
> debugging purposes or something. For my purpose, it's arguable that the
> verbosity makes it somewhat useless. clang++ is just a little too helpful
> here, love it as I do. That is part of the reason I don't use this macro
> for anything other than VS.
>
> I've reported this verbosity as a undesirable feature to Richard Smith to
> see if he agrees but I (and I'm sure he) would be interested in
> seeing other opinions on here on the subject. I hope that "someone" will
> "fix" it and make clang++ match g++ more here.
>
> I've tested the attached patch with clang, Visual Studio and mingw / g++.
> Thanks for your thoughts.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130917/880405ff/attachment.html>