<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/153519>153519</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            We should reconsider how `-pedantic-errors` and `__has_extension` checks interact
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          ojhunt
      </td>
    </tr>
</table>

<pre>
    We recently realized that the current semantics of how `-pedantic-errors` and `__has_extension` interact makes it extremely hard to detect language extensions when `-pedantic-errors` is specified.

At an implementation level, the problem is that the `__has_extension` implementation short circuits evaluation if pedantic errors is enabled, with the comment for that short circuit being essentially that given use of extensions will produce a warning, then they will always be errors and so we should simply report `false` for any extension check. This assumption is not actually true though: extensions can be used without triggering diagnostics through either CLI flags to suppress the relevant diagnostics, or through the `__extension__` annotation.

This causes problems when the extensions being queried meaningfully impacts the semantic of a declaration (which can result in ODR violations) or even cause ABI breakage (in the case of pointer authentication).

Because of this behavior `-pedantic-errors` is a development hazard: while it appears to be a diagnostic flag, it is functionally a _semantic_ flag impacting program behavior and codegen which I suspect no actual users would expect. As a side effect of that it makes using the desired semantic difference of `__has_feature` vs `__has_extension` difficult to safely maintain, as for extensions that impact semantics and/or ABI a `__has_extension` test is not universally correct if the code cannot guarantee it is never encountered with `-pedantic-errors` enabled.

This behavior also means there's a significant divergence between `-pedantic-errors` and `-Wpedantic -Werror`
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJycVc2K4zgQfhrlUnTjOD-dHHLIzNAwsLCwLMwxlKWyrRlZ8qokZzJPv5TsTmcOvYe9JGBJpe-vSshsO090UrtPavdlhTn1IZ7C9z77tGqCuZ2-EUTS5JO7QSR09hcZSD0mSD2BzjGST8A0oE9WM4QW-nAFta-eRjLl4xPFGCKrfQXojSxdLj3yhX4m8myDlxXrE0XUCQb8QQw2Af1MkQZyN-gxGkgBDCXSCRz6LmNHcC_AcO3Jf3SpZeCRtG0tmWdVnVV1PidAD3YYHQ3kEyYbPDiayKn6c2E2xtA4GuTwne0HyH-vwn2ICbSNOtvEQBO6PK_YFt7QwYxOqpPHxpGRe6829bOsYZCC0IY43_5bUWjI-g6ImXyy6Nxt3tTZiTxkJjHhURvrnPAxWRMgXDF667uFqJef27wH3RVvDA29wRO7OMCVBEB2BljIShBGwaP2VYuOSVQQqOhv7_eC7kn_eIa_e8uAzHkYZxUYfEiAOuUZeswEqQ-569Xm_IhboxcsmckUaUJOkKLtOorC31jsfOCSutRHKQBkU08RPv_xFVqHHUtqOI9jJOaibCRHE_r0eFqUKELPNe5O36FcLnN2fZg9XkJUmGnMTPwWlyWIUuKByOzXP5miJQMDoejfZmFvhxF1mrG9NZHYh2BIO4xzclR9uPZW90WSSJxdAuvhzy9_wWSDK5tY1UehQRKCggrOn75CEwl_SLOo-mBnZBrniIyhNB1I10uSdKmj6uPC7xPNZUILSag21ONkQ_yPPhPYE7kwlvj2-AujEVevvXUkTY3jSBiLL42E8d2GYphYYZNUarPXAqdkBOHyJs6l7Ft0E1nHGLqIwzs6Ca0OhjryMKv2FTjLBEjgwxI8SVVkuJZU009ZfIazEGBrCKhtZXthjkkgzWMps1wpIhpiG8m8m2Zs21Ikr4tg91HREqYcS4tM_MEEkaNWi6kSV2xl5g1ofULrRRHk0l4PiZpRFQ0eZi96o-rXEIvx-MFliTi9NWH2dqLIRWMdYhTOtl1GkJGkSOahyxjRJ6LFG08TRSCvQ5YALe35USyWAffYNO9eOQ6lIUoHRFL1y-xB521r9dyoE8Wu6NpQutLHc355XJ6-3afs07eyqvbVypw25rg54opO65fdbr3Z7Q-bVX867LZb2ptjuz28rF_w2JpqrZuX_b6tdtuXvV7ZU13Vu-qw3lbr7brePG_0Yb2p981WGzJH2qptRQNa9-zcNDyH2K0sc6bTerfZrY8rhw05Li9sXXu6QllVdS0PbjzJoacmd6y2lbOc-L1MssmRPMDL8I2kg5d4xv_3xJaBzPeXdpWjO_Upjaw2Z1W_qvq1s6nPzbMOg6pfBcfy9zTG8J10UvVrQc-qfl3oTaf63wAAAP__UMzviw">