<div dir="ltr">Historically Clang's policy on warnings was, I think, much more conservative than it seems to be today. There was a strong desire not to implement off-by-default warnings, and to have warnings with an exceptionally low false-positive rate - maybe the user-defined operator detection was either assumed to, or demonstrated to, have a sufficiently high false positive rate to not meet that high bar.<br><br>(as for the flag splitting - that was sometimes done if the new variant of a flag had enough bug-finding power that an existing codebase using the existing flag behavior would need significant cleanup - by having the new functionality under another flag name, existing codebases upgrading to a newer compiler wouldn't be forced to either do all that cleanup up-front or disable the flag & risk regressions... )</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 26, 2018 at 3:08 PM Roman Lebedev via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lebedev.ri added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D44883#1048689" rel="noreferrer" target="_blank">https://reviews.llvm.org/D44883#1048689</a>, @rjmccall wrote:<br>
<br>
> I tracked Chandler down, and he doesn't remember why user-defined operators are excluded.<br>
<br>
<br>
Ok then. Unless reviewers think it would be best to have separate diag groups for "builtin" and "user-provided" binary operators,<br>
i'll just extend the `-Wself-assign` / `-Wself-assign-field` / `-Wself-move` (i wonder, does it work both the fields and usual variables, or not).<br>
<br>
(That means, stage2 self-hosting testing will be needed...)<br>
<br>
<br>
Repository:<br>
  rC Clang<br>
<br>
<a href="https://reviews.llvm.org/D44883" rel="noreferrer" target="_blank">https://reviews.llvm.org/D44883</a><br>
<br>
<br>
<br>
</blockquote></div>