| Issue |
153519
|
| Summary |
We should reconsider how `-pedantic-errors` and `__has_extension` checks interact
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
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`
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
