[cfe-dev] Preprocessor operators for #error and #warning

[Kyle Sluder]

> On Apr 13, 2014, at 1:29 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
>> On Sun, Apr 13, 2014 at 12:38 PM, Kyle Sluder <kyle at ksluder.com> wrote:
>> On Apr 12, 2014, at 2:34 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> >
>> > For _Error, you can use C11's _Static_assert():
>> >
>> > #define fail(msg) _Static_assert(0, msg)
>> >
>> > There's no standard equivalent for #warning, unfortunately.
>> 
>> That workaround is sufficient for my use case, but the output is noisy and as you note it doesn’t work for those who treat warning differently from errors.
>> 
>> So, can anyone opine on whether such a patch would be accepted?
> 
> I don't think we want _Warning and _Error. You can use #pragma message to emit a warning (as _Pragma("message \"...\"") within your macro).

Such a macro definition is sadly impossible because the C99 spec is too strict: _Pragma only accepts a single string literal. No implicit concatenation of string literals is allowed.

If the clang folks are fine with relaxing that, then _Pragma becomes sufficient for my purposes. But I presume it was so strictly defined in the spec for some reason.

> I'd much prefer to add support for something like '#pragma clang error "blah"' rather than adding something like _Error(...), if _Static_assert is somehow insufficient, but I'd like to understand what's wrong with _Static_assert first.

Well, for starters, it can’t be used to produce a warning. That alone makes it worth contemplating alternatives, in my view.

But even for the error-producing use case, the error output contains a lot of noise about failing nonsensical assertion conditions. The best thing about #error and #warning is that I get to control the output, and that lets me match clang’s much-lauded user-friendliness in my own error messages.

--Kyle Sluder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140413/227ddba7/attachment.html>