[PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

[David Majnemer via cfe-commits]

On Thu, Mar 24, 2016 at 9:09 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Thu, Mar 24, 2016 at 11:49 AM, Reid Kleckner <rnk at google.com> wrote:
> > On Thu, Mar 3, 2016 at 10:40 AM, Aaron Ballman <aaron at aaronballman.com>
> > wrote:
> >>
> >> That was what I meant by "justification". I would say it has to be
> >> reasonably compelling code (win32 headers, boost, some other major
> >> library) as that's our usual bar for these sort of bug-for-bug
> >> compatible things, as I understand it.
> >
> >
> > I'd rather apply this patch now than wait for ffmpeg or someone to try to
> > use static_assert and then have to hustle to get this into clang. Many
> many
> > C projects have COMPILE_ASSERT macros that are just a small change away
> from
> > relying on (_S|s)tatic_assert.
>
> I don't find "someone might rely on this bug" to be compelling. Put
> another way, why do we lower the bar for this bug but not others given
> that no large projects appear to need this behavior?
>

Very few people are using clang-cl with C code.  I'm sure it would come up
a lot more often if it were better tested.


>
> >>
> >> Agreed, we have a way forward if we need it. I mostly just want to
> >> avoid the burden of supporting that because this is sufficiently weird
> >> (being a non-conforming keyword).
> >
> >
> > It's not conforming, but it's not that weird to define our own keywords.
> The
> > C++ committee chose the keyword "static_assert" because it was unlikely
> to
> > conflict with existing code. MSVC has made this a keyword in C mode and
> the
> > world hasn't burned.
>
> Correct, we have a way around it, I am just not convinced that we
> should put forth the effort of supporting another compiler's bug
> without a compelling use-case.
>

A compelling use case is that users who wish to use static_assert in a
conforming C program can do so.
Today, it is impossible to do this with clang-cl & MSVC's CRT.


>
> ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160324/4a5d61a5/attachment-0001.html>