ilya-biryukov added a comment. The list of bugs I shared was meant to illustrate the problem, it's not meant to be exhaustive. I am not sure there is a need to rush and fix them before the release, it is just a signal that makes us worried about the feature. The bugs are niche, and likely not a problem for most people who want to use coroutines today. As I mentioned before, we tend to be overly cautious when it comes to supporting features for a large population of our users.
> So the only warning that would make sense to me is "Support for coroutines is > still experimental." I think that's what you want to express here. > Which again begs the question of why we claim conformance for something we > think is too unstable to use in production. I am not sure if there is a process for ensuring conformance in Clang in general. We should have one, but how do we know if the feature is buggy until users try it? Not enabling coroutines in Clang or not defining the feature macros would likely lead to people not using coroutines and, consequently not discovering those bugs. "Support for coroutines is experimental" is temporary, we might need to remove it in the future (this seems fine, I suspect there were precedents before). Having something like `-Wcoroutines-used` saying "you use coroutines and requested to flag it by a compiler warning" is likely to be hold up for the years to come. I agree that doing it for all features is an overkill, I also think this warning is very niche. As mentioned before, we want it for purely pragmatic reasons, I acknowledge this does not align well with Clang's warnings nor generalizes well to all features. > This looks like a coding guide to me. So I feel it may be better to follow > what other coding guides does. As far as I know, it is rare to insert > warnings to the compilers for a specific coding guide. It is ultimately a style guide enforcement, yes. Using a compiler means we can reliably capture all violations. In a typical situation, not following a style guide results in "worse" code (in terms of the style guide itself), so enforcing via linters works well. Here, it can lead to miscompiles, so enforcing at compiler level and catching all violations is preferable. Again, we are overly cautious about miscompiles when shipping to a large number of users. > I am not sure if Google has used it in production We do have it in production, but for a very limited experiment and not widely deployed. 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
