[PATCH] D156247: [Clang] Add a warning on uses of coroutine keywords

Fri Jul 28 04:47:47 PDT 2023

ilya-biryukov added a comment.

In D156247#4541826 <https://reviews.llvm.org/D156247#4541826>, @cor3ntin wrote:

> How does a -cc1 flag alleviate the burden concerns for libc++? It would still be something they would have to support, unless we plan to remove the flag before c++26 and you are happy with the inclusion of `<coroutine>` and `<generator>` producing subpar errors.
> However, in the C++26 cycle, `<execution>` (P2300 <https://reviews.llvm.org/P2300>) is going to have a dependency on `<coroutine>`, and it does not seem reasonable for that to lead to errors.

We would be okay with `<coroutine>` and `<generator>` producing subpar errors. Because it's on users of those flags (i.e. us) to handle those errors, the users (i.e. **us**) will have to stop using it in C++26 or whenever libc++ starts to depend on coroutine in other headers.
If we are the only ones who need this configuration (and this is my impression right now), it makes sense that we are the ones who need to figure out who to deal with issues like this.

In D156247#4541880 <https://reviews.llvm.org/D156247#4541880>, @Endill wrote:

> In D156247#4541756 <https://reviews.llvm.org/D156247#4541756>, @ilya-biryukov wrote:
>
>> @aaron.ballman the internal -cc1 flag
>>
>> - internal `clang -cc1 -fno-coroutines`.
>
> I'm sorry, but I find this wording misleading. `-cc1 -fno-coroutines` is not internal in the same sense as e.g. `-verify` is. Both are hidden from user-facing drivers, but unlike `-verify`, potential `-cc1 -fno-coroutines` is not just intended, but focused on users outside of monorepo. So I'd say it's going to be hidden but user-facing feature, rather than internal one. And the one that we should document and test if not for users, then for ourselves to make sure we maintain its semantics and don't break users. At this point I'd say if we go for it, we should go for proper driver option, rather than frontend one.

The `-cc1` flags can change between compiler releases and do not need to provide the same level of guarantees as user-facing features.
I do not see why we would want to put a high bar on documenting, testing `-cc1 -fno-coroutines` and making sure that it works.
E.g. Clang has `-cc1 -fcoroutines`, but it does not enable <https://gcc.godbolt.org/z/q394K4YMz> coroutines in `-std=c++17` like GCC does. We don't test it, we intend to ship Clang 17 with this behavior and I don't see why that's a problem.

> I also wonder how much complexity this language dialect would introduce while interacting with other language dialect flags. Is it really worth it?

The complexity on the compiler side seems very low (this patch or something not much harder). If we do not require libc++ to support this configuration and allow it to break going forward (that is my proposal).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156247/new/

https://reviews.llvm.org/D156247