ldionne added a comment. In D120244#3538660 <https://reviews.llvm.org/D120244#3538660>, @aaron.ballman wrote:
> In D120244#3538380 <https://reviews.llvm.org/D120244#3538380>, @ldionne wrote: > >> We've started having several internal user complaints because their system >> headers are suddenly triggering a warning for using `<stdbool.h>`. This >> seems to be caused by the fact that `#warning` is surfaced to users even >> when the `#warning` is present in a system header (which makes sense, >> because otherwise there would be no way to issue a `#warning` from a system >> header). This ends up causing problems because users have no way to suppress >> the warning in the system headers they use without also disabling >> deprecation warnings in their own code. Is this intended? Instead, it seems >> to me like what we'd want is some way to mark the header as deprecated such >> that Clang will not flag uses of `<stdbool.h>` from within system headers, >> but will flag them from user code. This would be consistent with how the >> deprecated attributes work for classes and functions. >> >> Thoughts? > > This is what `_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS` is for. We documented > it here: > https://clang.llvm.org/docs/UsersManual.html#controlling-deprecation-diagnostics-in-clang-provided-c-runtime-headers > but the basic idea is, if that's defined before including the header, we > don't issue those warnings. Does that suffice? Well, the problem is that a user that is using some system header like `Foundation.h` (which includes `<stdbool.h>`) will be forced to define `_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS`, which has two drawbacks: 1. It's annoying to them because they never used `<stdbool.h>` in their own code 2. It turns off deprecation warnings in their own code as well In other words, the fact that this `#warning` gets out of system headers means that it's going to "spam" users who have no control over what their system headers are doing. So while the long-long term fix is for all system headers (like `Foundation.h`) to be C2x friendly and not include `<stdbool.h>` in newer standard modes, the current migration path involves a lot of spammy warnings for end users in the meantime. Since such a migration may or may not happen completely everywhere, it also means that this is probably not a "bite the bullet for 3 months" situation. FWIW, although libc++ is fairly aggressive on marking functions and classes as deprecated, we do not try to warn for *headers* that are deprecated, because there is no satisfying way of doing so right now. Personally, my opinion is that unless we have a way to mark headers as deprecated in a way that the compiler can understand the semantics and have it behave roughly like a "deprecated attribute but on a header" (which means that this warning would behave just like all other compiler warnings w.r.t. system headers), it is not a great idea to do this. I'm very keen on deprecating stuff, however I think this `#warning` is not the right tool for it, because of the downsides I mentioned. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120244/new/ https://reviews.llvm.org/D120244 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
