We should reconsider how `-pedantic-errors` and `__has_extension` checks interact

[ojhunt]

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

[ojhunt]

cc'ing @pcc @AaronBallman @cor3ntin and @efriedma-quic as I think we should consider how to deal with this in llvm22.

I am concerned about the potential for source breakage though through code like this:

// code compiled with -pedantic-errors
...
#if __has_extension(some_cool_extension)
use_the_cool_extension(...);
#else
use_the_boring_fallback(...);
#endif
...

Now currently the above code would compile - because even if the developer does think they're using the extension, the nature of -pedantic-errors means that they are not, and that branch is not encountered.

If we change the semantics to allow the __has_extension test to succeed, their use of the extension inside that check may now generate a warning which under -pedantic-errors will be promoted to an error.

While this might call attention to them that the code was not being used previously it may also just frustrate them due to the compile break.

[efriedma-quic]

If we change the semantics to allow the __has_extension test to succeed, their use of the extension inside that check may now generate a warning which under -pedantic-errors will be promoted to an error.

I'm not really concerned about this... yes, it's technically breakage, but it specifically only bites people who are only compiling their code in -pedantic-errors mode, and it only impacts features which are not part of __has_feature, and we're "breaking" it by making the feature work the way the user probably wanted it to work in the first place.

[AaronBallman]

If we change the semantics to allow the __has_extension test to succeed, their use of the extension inside that check may now generate a warning which under -pedantic-errors will be promoted to an error.

I'm not really concerned about this... yes, it's technically breakage, but it specifically only bites people who are only compiling their code in -pedantic-errors mode, and it only impacts features which are not part of __has_feature, and we're "breaking" it by making the feature work the way the user probably wanted it to work in the first place.

Strongly disagreed. Consider this not-uncommon pattern where the feature test is used specifically to ensure the extension is used when available and a fallback is used otherwise:

#if __has_extension(thing)
#define THING __thing
#else
#define THING __attribute__((fallback_thing))
#endif

THING int i = 12;

Under -pedantic-errors, this code just works. With the changes proposed here, the user gets __thing and then gets an error. That's explainable if we were designing from scratch, but it's a bait-and-switch on users who trusted our documentation for the past forever. And when I searched for the pattern on sourcegraph, there were thousands+ of examples of uses like that.

[ojhunt]

Under -pedantic-errors, this code just works.

It doesn't if the extension is part of the platform ABI. It just compiles it crashes at runtime.

Under the current model -pedantic-errors (which is an argument that sounds like a diagnostic flag, not a semantic or codegen flag) changes the meaning of code, such that it can break platform ABI, disable security features, and introduce ODR violations. This is because fundamentally the semantics mean that it's a codegen flag. I would argue that it's poorly named, but that ship sailed a loooong time ago.

I find the gcc compatibility story more compelling than the "my code breaks" because I would rather code fails to compile than breaks at runtime.

Anyway, given that we can't change the core behavior we need to provide a mechanism to permit an extension to be marked such that __has_extension(some_ident) can be accepted in spite of -pedantic-errors (the __has_extension test in this case could have a warning), or __has_extension(some_ident) should itself become an error for critical extensions.

I don't particularly like the latter option as it essentially means -pedantic-errors is disabled on our platform. OTOH I suspect that the overwhelming majority of users of this flag would be surprised that it causes codegen changes, so maybe having them move to -Wpedantic -Werror would be preferable.

Taking your above example

#if __has_extension(thing)
#define THING __thing
#else
#define THING __attribute__((fallback_thing))
#endif

THING int i = 12;

I would assume that a developer who has written this, and then used -pedantic-errors, likely wrote the code expecting that it would be used, so the error on __thing rather that simply not using it.

You have similar issues with __has_extension in system headers as they are defining platform abi, but -pedantic-errors also impacts the behavior in system headers, so breaks those as well.