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

[Abramo Bagnara]

Il 21/06/2012 10:12, Chandler Carruth ha scritto:
> On Thu, Jun 21, 2012 at 1:06 AM, Sebastian Redl
> <sebastian.redl at getdesigned.at <mailto:sebastian.redl at getdesigned.at>>
> wrote:
> 
>     On 21.06.2012 08 <tel:21.06.2012%2008>: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)

Isn't more lightweight to define only __clang_revision__ to SVN commit
id and to distribute with clang an header file where this revision is
mapped to fixed bugs in a way similar to this:

#define macrotest_1 ,
#define is_undef(macro) is_undef_(macro)
#define is_undef_(value) is_undef__(macrotest_##value)
#define is_undef__(comma) is_undef___(comma 0, 1)
#define is_undef___(_, v, ...) v

#define __clang_revision__ 123456

#if __clang_revision__ >= 123456
#define __clang_fixed_123 1
#endif

#define __has_clang_bug(id) is_undef(__clang_fixed_ ## id)

__has_clang_bug(123)
__has_clang_bug(124)

$ clang -E -P z.c
0
1

This would avoid to keep the whole clang bug history in compiler
executable and to add yet another extension. At the same time this
approach is extensible to whatever compiler (once someone is willing to
write its bug header file).