[cfe-dev] Determine whether the current clang version has a specific bug

[Chandler Carruth]

On Thu, Jun 21, 2012 at 1:06 AM, Sebastian Redl <
sebastian.redl at getdesigned.at> wrote:

>  On 21.06.2012 08:43, Daniel Jasper wrote:
>
> Currently __has_feature, __has_extension and __has_attribute implement
> something similar, but this change does not really fit any of those
> categories as it should be considered a bug. Not allowing this attribute on
> fields was an oversight that was fixed. Thus I (after discussion with
> chandlerc) suggest introducing __has_bug.
>
>  This should default to 1 (all bugs that are not explicitly fixed in a
> clang version are still bugs) and to provide compatibility with other
> compilers, sources can used:
> #ifndef __has_bug
> # define __has_bug(x) __clang__
> #endif
>
>  Any thoughts?
>
>  I had the same idea (for some app's plugin API, but the principle is the
> same). In this case, however, I think we should give the builtin a
> clang-specific name. __has_feature and __has_extension could be done the
> same way by other compilers with matching feature names, and code would
> profit. However, another compiler is unlikely to have exactly the same bug,
> or realize it and come up with the same name scheme (I would just use
> Bugzilla numbers). What's more, since all unknown bug names are considered
> not fixed, that would mean that each such test would need a compiler
> predicate first.
> That is, if GCC also implemented this, then you can no longer just use the
> custom define you described, because __has_bug would already be defined.
> Then your code would think that GCC has every bug Clang ever had, and vice
> versa.
>

This is a great point.


> So I think we should either call it __has_clang_bug, or else come up with
> a scheme to namespace the bug names and only claim that we have those that
> are in our namespace, i.e. __has_bug(clang, 12323) would default to true on
> Clang unless 12323 has been specifically fixed, whereas __has_bug(gcc,
> 65834) would default to false on Clang. The obvious downside of the second
> approach is that it is harder (maybe even impossible) to emulate using a
> macro.
>

I think __has_clang_bug(...) would work well.

We shouldn't assume too much about the spelling of the '...', I forsee at
least two spelling patterns:

__has_clang_bug(cxx11_feature_we_messed_up)
__has_clang_bug(PR12345)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120621/7a6eabf6/attachment.html>