aaron.ballman added a comment. In D150226#4461846 <https://reviews.llvm.org/D150226#4461846>, @efriedma wrote:
> The fundamental problem here is the interaction with SFINAE; if we don't > diagnose this as an error, we actually miscompile some cases. Because of > that, a flag wouldn't really be "turning off the warning"; it would be > enabling a non-compliant language mode that has different rules for whether > enum casts are legal. > > If it weren't for that, I don't think anyone would be in a hurry to turn the > warning into a hard error. +1 to this. I'm worried about the miscompiles continuing in the wild. We did the best we could when landing the warning-as-error changes in D131307 <https://reviews.llvm.org/D131307> by telling users explicitly "This diagnostic is expected to turn into an error-only diagnostic in the next Clang release." in the release notes. Obviously, that's not ideal because very few folks read release notes, but we don't have any better mechanism for communicating these kinds of changes. What do folks think is a reasonable path forward here? Given that we're going to branch the Clang 17 release in a few weeks (AIUI), my suggestion is to kick the can down the road by landing these changes just after we branch. That way the changes land such that early adopters can test and see how disruptive we're being without time pressure or hassle of dealing with release branches. Do folks think that's a reasonable approach? (I'm open to other suggestions.) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150226/new/ https://reviews.llvm.org/D150226 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
