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.
(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... ) On Mon, Mar 26, 2018 at 3:08 PM Roman Lebedev via Phabricator < revi...@reviews.llvm.org> wrote: > lebedev.ri added a comment. > > In https://reviews.llvm.org/D44883#1048689, @rjmccall wrote: > > > I tracked Chandler down, and he doesn't remember why user-defined > operators are excluded. > > > Ok then. Unless reviewers think it would be best to have separate diag > groups for "builtin" and "user-provided" binary operators, > 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). > > (That means, stage2 self-hosting testing will be needed...) > > > Repository: > rC Clang > > https://reviews.llvm.org/D44883 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
