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

Thu Jul 27 06:30:44 PDT 2023

ilya-biryukov added a comment.

Thanks, disabling the language feature definitely makes more sense.
`-fno-coroutines` is trickier to implement, but this cannot be too hard.

While we are waiting for libc++ folks to come back with feedback, what would be the desired behavior. GCC seems to

1. errors out on `#include <coroutine>`,
2. treats coroutine keywords as identifiers.

While (1) makes total sense, I'm not sure about (2). Should we instead show errors, but still treat `co_await` and friends as keywords?
I think it would be a better choice because it would prevent writing non-standard-compliant code.
On the other hand, given the `co_` prefix, the clashes should be **really** rare anyway and we might want to match GCC behavior.

Thoughts?

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

> In D156247#4534645 <https://reviews.llvm.org/D156247#4534645>, @ilya-biryukov wrote:
>
>> At Google, we would like to postpone adoption of coroutines until the aforementioned bugs are fixed, but we feel that Clang 17 would be a good candidate to enable other C++20 features (sans Modules).
>> We could have landed a local patch with a similar warning in our main toolchain that we control tightly. However, we want to have it for other toolchains (e.g. Apple Clang) that are based on upstream and we do not control.
>> Given that adoption by Apple Clang is one of the motivation to make this change upstream, do we have a reasonable expectation they would pick this change soon? Historically Apple follows a release schedule that is not synchronized
>
> with the LLVM release process.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156247