<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Thu, Jun 21, 2012 at 1:06 AM, Sebastian Redl <span dir="ltr"><<a href="mailto:sebastian.redl@getdesigned.at" target="_blank">sebastian.redl@getdesigned.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On <a href="tel:21.06.2012%2008" value="+12106201208" target="_blank">21.06.2012 08</a>:43, Daniel Jasper
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div style="font-family:arial,helvetica,sans-serif">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. <font size="2">
          <div><br>
          </div>
          <div>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:</div>
          <div>#ifndef __has_bug</div>
          <div># define __has_bug(x) __clang__</div>
          <div>#endif</div>
          <div><br>
          </div>
          <div>Any thoughts?</div>
        </font><br>
      </div>
    </blockquote></div>
    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.<br>
    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.<br></div></blockquote><div><br></div><div>This is a great point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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.</div></blockquote><div><br></div><div>I think __has_clang_bug(...) would work well.</div><div><br></div><div>We shouldn't assume too much about the spelling of the '...', I forsee at least two spelling patterns:</div>
<div><br></div><div>__has_clang_bug(cxx11_feature_we_messed_up)</div><div>__has_clang_bug(PR12345)</div></div></font></div>