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

Reply via email to