NoQ added a comment. I'd like to clarify that in case of path-sensitive analysis there are actually three warning classes to consider.
1. Warnings that reside completely in system headers and indicate bugs in system headers, most likely falsely. 2. Warnings that originate from the main file and indicate misuse of system header APIs, likely correctly. 3. Warnings that originate from the main file, but still indicate bugs in system headers, because the part of the path that stays in the main file is irrelevant to the warning. This change suppresses 3, and as a side effect we suppress 1, because discriminating between 1 and 3 is hard* . We never needed to suppress 2, because they're never created to begin with: AnalysisConsumer doesn't consider header-only functions for top-level analysis. __ // * I think that actually such discrimination is curious and probably worth investigating. We could try to see which symbols (originating from where) participate in the equation that expresses the invariant violation of which causes the warning. We could potentially improve our suppressions greatly (maybe even make them non-hackish) and probably avoid the common problems with inlining this way. Just brainstorming. Repository: rL LLVM https://reviews.llvm.org/D30798 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
