ldionne added a comment. In D120244#3540598 <https://reviews.llvm.org/D120244#3540598>, @aaron.ballman wrote:
> The system header including a header that's explicitly deprecated is dubious > practice, but that does still require some amount of timing coordination. I agree, and I'll be filing bug reports against system headers within my control that use `<stdbool.h>`. That is unfortunately not the majority of headers, though. >> 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. > > Okay, that's a fair problem. However, the flip side is: why should C2x users > not be told about deprecated functionality when they include the header > directly? I agree -- they should be told about the deprecated functionality. The problem is that with the currently available technology, we have to choose between telling them about their use of deprecated `<stdbool.h>` AND spamming them for system headers' use of it, or not telling them at all. Both options have downsides, I think it's a matter of what we value the most. > So I take it > https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/stdnoreturn.h > is also an issue? I think so. I suspect it may be much less widely used, so that might be why it wasn't brought up. > My feeling is: system headers that spam warnings are a bigger concern than > not getting a deprecation warning, but we want that deprecation warning > eventually because we need *some* way to deprecate headers as a whole. Not > issuing deprecation warnings means standards bodies can't reasonably rely on > users having been warned, so not diagnosing means "let's stick the *entire > ecosystem* with this header file forever". So I'm thinking of walking back > the `#warning` for the headers but with some sort of timeline as to when we > can add the diagnostics back to the headers. Do you have an idea of what > would be reasonable for Foundation.h? I fully agree -- we need a way to deprecate headers (just like we do for classes and functions). My intent is really not to impair your efforts at doing that -- I'm just trying to point out the unfortunate tradeoff we are making. Regarding `Foundation.h` -- I am using this as an example, but it's really just the tip of the iceberg. We can probably get this one fixed within a reasonable time frame, however that won't change the fundamental issue. > We could maybe extend `#pragma clang deprecate` to deprecate inclusion of the > current file so that it acts sort of like a `[[deprecated]]` attribute that > triggers on inclusion using typical diagnostics instead of `#warning`. Yes, if that is feasible, I think something like that is exactly what we would need. If we had a tool like this, by the way, I would be very keen on deprecating some libc++ headers that we keep around like `<ciso646>` & friends. So, in summary, my opinion is that we should wait until we have the appropriate technology (something like proposed above) before deprecating these headers. And once we do, then I'll be 100% supportive of efforts in that direction. But I'm mostly relaying user feedback here, I don't own the Clang headers so I must defer to your judgement. 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
