rjmccall added a comment. Let me try to summarize where I think we are.
1. I think it’s now generally agreed that this is a useful warning — certainly for field assignments, but we also have (at least?) one example with a local variable. 2. It’s also generally agreed that this warning has a problem with unit tests and that we should provide a compiler option to suppress. 3. There isn’t really a middle-point between case-by-case suppression (by rewriting the RHS to avoid the warning) and file-by-file (compiler option) suppression. We don’t know how to distinguish the unit-test false positives from the local-variable true positive. 4. Whatever the file-by-file suppression is, it would be best for build systems to target it narrowly at their unit-test code; but we also have to acknowledge that that’s not always straightforward, and so the suppression should be narrowly-targeted on the compiler side as well, just in case the suppression does have to be more global. 5. Roman and I are suggesting that the file-by-file suppression should not be specific to this warning but instead should be a more generic way of disabling warnings that are known to be problematic in unit tests. We could then recommend that option to project owners as a single mitigation rather than forcing them to maintain a growing list of test-directed warning suppressions. 6. Using a more general mechanism seems advisable because we are already considering extending some other warnings to cover user-defined operators, and all such warnings have the potential of running afoul of unit tests. (This is something that will require careful thought because user-defined operators need not have their conventional meaning. However, any semantics-based suppression will almost certainly have different characteristics from a test-directed suppression. For example, test-directed suppression for self-assign need not suppress warnings about fields, whereas a semantics-based suppression should.) John. Repository: rC Clang https://reviews.llvm.org/D45685 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
