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

[Sebastian Redl]

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.

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.

Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120621/f54a7309/attachment.html>