| Issue |
84372
|
| Summary |
[clang] __has_extension changes semantics based on -pedantic-errors
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
ldionne
|
I just found this in `clang/docs/LanguageExtensions.rst:143`:
> If the `-pedantic-errors option is given, __has_extension` is equivalent to `__has_feature`.
And in `clang/lib/Lex/PPMacroExpansion.cpp:1161`:
```
static bool HasExtension(const Preprocessor &PP, StringRef Extension) {
if (HasFeature(PP, Extension))
return true;
// If the use of an extension results in an error diagnostic, extensions are
// effectively unavailable, so just return false here.
if (PP.getDiagnostics().getExtensionHandlingBehavior() >=
diag::Severity::Error)
return false;
const LangOptions &LangOpts = PP.getLangOpts();
...
```
So basically, `__has_extension(...)` always returns `0` when `-pedantic-errors` is used. This means that the semantics of programs can actually depend on whether `-pedantic-errors` is passed, which seems really confusing because few people would expect compiler diagnostics to impact semantics. For example, it is possible to end up in a situation where ODR is violated (via a `#if __has_extension(...)` check) based solely on whether `-pedantic-errors` is passed, which illustrates very well why this is undesirable.
This led to e.g. the issue fixed in #84065, and more discussion is available on that review.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
