loladiro marked an inline comment as done. loladiro added a comment. > So, you'd like to make this a frontend flag in order not to expose it to > "regular" end users? Or was it because, well, every other flag we have is a > frontend flag?
Little bit of both? We already need to pass a bunch of `Xanalyzer` and `Xclang` features in order to set things up correctly and it seemed like a more prominent flag would cause more debate and delay in getting this in ;). > For a project whose entire foundation is based on an estimation (I mean to > refer to false positives), I fear that this flag would be impractical for > most users. I certainly wouldn't like to receive an error on a false > positive, but I can see that for your specific use, while on specific > checkers are enabled, this would be fine. But again, do we really do this > flag justice by "simply" making it a frontend flag? Yeah, we're a bit of a special case here in that we consider false positives for our analysis a bug (in the analysis), so Werror makes more sense for us (since the analysis is also in the repo being CI'd). > At the end of the day, the idea sounds great, and I'm not opposed to landing > this before resolve this paradox. ================ Comment at: test/Analysis/override-werror.c:10 + return p; // expected-warning{{incompatible pointer types}} \ + werror-warning{{incompatible pointer types}} } ---------------- Szelethus wrote: > Why isn't this `werror-error`? Unlike the other error (which is generated by the analyzer), this is a semantic error (i.e. would get emitted even in the absence of the analyzer). The `-analyzer-werror` flag only touches those warnings generated by the analyzer, so this is the desired behavior. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62885/new/ https://reviews.llvm.org/D62885 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits