aaron.ballman added a comment. In D146466#4208216 <https://reviews.llvm.org/D146466#4208216>, @dblaikie wrote:
> If the issue is with the actual fallthrough - that's been discussed elsewhere > recently, and I think it'd be reasonable to turn on TrapOnUnreachable > everywhere, basically (with NoTrapAfterNoreturn too, perhaps, to keep the > cost low) so that these trivial fallthroughs hit int3 instead of going on to > the next function. As I understand things, folks are confused about the runtime behavior of falling through and magically calling some other function. If we can warn about that situation from the FE without false positives, then huttah, I think that's sufficient. But I don't think we know of a way to do that from the FE, so I think ensuring a runtime trap is more helpful to folks than the status quo. (Also, in general, I think we want to avoid emitting diagnostics from the backend -- that has usability issues where clean `-fsyntax-only` builds suddenly get warnings when doing full codegen, or in circumstances where the optimization level changes the diagnostic output, etc.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146466/new/ https://reviews.llvm.org/D146466 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
