aaron.ballman added a comment. In D156247#4537351 <https://reviews.llvm.org/D156247#4537351>, @ChuanqiXu wrote:
> While I am not against the approach, do you think we need similar semantics > for `-fno-concepts`, `-fno-modules`, etc... ? I think we need to take it on a case by case basis. In general, we only let users disable language features when the feature has hidden costs that cannot be avoided (e.g., exceptions and RTTI in C++), which isn't the case with coroutines. However, because GCC allows you to disable coroutines and we try to keep our flags reasonably compatible, and because we have users with a concrete need, it is perhaps reasonable in this case. I think the answer is different for something like concepts because those are used by the STL, so disabling them has greater impact on what code is accepted by the compiler. If GCC didn't support `-fno-coroutines`, I'd likely be opposed to adding it to Clang because coroutines impose no hidden costs unless you actually use the feature and the use case is unmotivated (clang-tidy is the tool for enforcing coding style guides). We definitely do not want a complicated testing matrix of "what if this set of features is enabled and that set of features is disabled but the rest follows the given language standard". One thing that worries me in this case is the `<generator>` header in C++23; without coroutines, that can't compile. Personally, I think we should err on the side of being conservative with language dialect flags unless there's a clear need: don't reflexively enable features as extensions in older language modes and don't allow users to disable features in newer language modes. 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
