On Sep 16, 2013, at 11:49 PM, G M <[email protected]> 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.
>
>
> <warning.diff>
The current verbosity on clang, combined with the technique for disabling the
warning on clang makes this undesirable for me (-W#warnings vs
-W#pragma-messages). I'm guessing there are already projects out there that
are disabling the libc++ #warnings with (for example):
#pragma clang diagnostic ignored "-W#warnings"
And I've insufficient motivation to rock their boat. However I've no objection
to something along the lines of:
#if defined(_MSC_VER) && ! __clang__
_LIBCPP_WARNING("cl user triggered warning");
#else
# warning user triggered warning;
#endif
Howard
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
