================ @@ -11591,6 +11591,10 @@ def err_conflicting_aligned_options : Error < def err_coro_invalid_addr_of_label : Error< "the GNU address of label extension is not allowed in coroutines." >; +def err_coroutine_return_type : Error< ---------------- ilya-biryukov wrote:
This makes sense, but I'm still not sure if it's better than having an on-by-default warning. The use-case I imagine is adding `[[clang::coro_return_type]]` to an existing type. Currently, it requires fixing all (mis)uses of that type to compile the code and does not allow to have a two-step process (or at least makes it more complicated, e.g. one will have to hide the attribute under a macro). If this was a warning, I can imagine some people marking the class with the attribute, rerunning the compiles to collect all places that need to be fixed via a warning without breaking the build and later grinding them as a separate step, while still preventing misuses in newly written code. That being said, thinking more about the `std::function` angle of it, I think an error is a better trade-off, because there is no way to force this particular warning to be enabled in system headers (even `-Werror` won't help because it only applies if the warning wasn't previously filtered out). https://github.com/llvm/llvm-project/pull/71945 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
