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

Fri Jul 28 12:50:02 PDT 2023

aaron.ballman added a comment.

In D156247#4542769 <https://reviews.llvm.org/D156247#4542769>, @ilya-biryukov wrote:

> In D156247#4542155 <https://reviews.llvm.org/D156247#4542155>, @aaron.ballman wrote:
>
>> Given the views expressed on this thread, I think this requires a wider community discussion to determine whether we want to support this idea or not, regardless of -cc1 or driver-level option. We should not be adding a novel language dialect as we're getting ready to cut a release unless the need and benefits are *very* compelling, and I don't think that's the case here. We need the time to think about the long-term effects of such a mode, so I don't think Clang 17 is an appropriate ship vehicle for this change, especially because Google can carry this patch in your downstream easily enough.
>
> Google cannot do this with a downstream patch as we need this for toolchains that we do not build from the LLVM sources we integrate.
> If we could do with a local patch, we would have definitely done it.

Good to know! How certain are you that the other toolchains will have been cut such that they support this feature given how late in our cycle it is? @Mordante had some evidence that Apple Clang is from June, for example.

>> My recommendation is to start an RFC on Discourse. If the community quickly and decisively agrees this should land in Clang 17 in the next few days, it might still be reasonable to make the rc2 cutoff, but I'd leave that decision to the release managers and it would be contingent on strong libc++ maintainer agreement to whatever direction we go (because they'll be the most impacted by this decision).
>
> https://discourse.llvm.org/t/rfc-add-a-flag-to-clang-17-to-disable-coroutines-in-c-20
>
> @aaron.ballman could you comment on having a `-cc1` flag without guarantees from libc++ folks that this works (so it imposes no support costs on them)?

Personally (not a code owner decision statement)...
I think it's a bad precedent to add a -cc1 flag knowing we won't support it and that only exists to help enforce a coding style decision. I think it's especially bad precedent to add features to a release branch without having any bake time in the main tree. I don't think we should add any `-fno-` flags for standardized language features unless the feature imposes extra cost even when not in use. e.g., exceptions and RTTI are very reasonable to disable, but allowing arbitrary mixing and matching of language features to create your own mutant C++ version seems like a support nightmare in general. I know that clang-tidy isn't a great solution for you, but that's where I think this functionality belongs just the same even if it isn't ideal.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156247