[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

Thu May 26 11:20:13 PDT 2022

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