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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
