Change Details

This has just bit me, so i though it would be nice to avoid that next time :) Motivational case: https://godbolt.org/g/cq9UNk Basically, it's likely to happen if you don't like shadowing issues, and use `-Wshadow` and friends. And it won't be diagnosed by clang. The reason is, these self-assign diagnostics only work for builtin assignment operators. Which makes sense, one could have a very special operator=, that does something unusual in case of self-assignment, so it may make sense to not warn on that. But while it may be intentional in some cases, it may be a bug in other cases, so it would be really great to have some [opt-in] diagnostic about it... For now, this diff restructures `SelfAssignment` diag group, splits it into `SelfAssignmentBuiltin` (as what is already in trunk), and the new `SelfAssignmentOverloaded`, which is not enabled by default/`-Wall`. For now i have put it into `-Wextra`, but i don't know if it should be there. Additionally, a question: what should be done for trivial assignment operators? Perhaps this should be split even more, and if the operator is trivial implicit (or even trivial user-defined =default ?), it should even warn in `-Wall`? I'm guessing the self-move, and self-field-assign warnings should also be adjusted to work for overloaded operators, but i did not want to bloat this diff.

This has just bit me, so i though it would be nice to avoid that next time :) Motivational case: https://godbolt.org/g/cq9UNk Basically, it's likely to happen if you don't like shadowing issues, and use `-Wshadow` and friends. And it won't be diagnosed by clang. The reason is, these self-assign diagnostics only work for builtin assignment operators. Which makes sense, one could have a very special operator=, that does something unusual in case of self-assignment, so it may make sense to not warn on that. But while it may be intentional in some cases, it may be a bug in other cases, so it would be really great to have some diagnostic about it...

This has just bit me, so i though it would be nice to avoid that next time :) Motivational case: https://godbolt.org/g/cq9UNk Basically, it's likely to happen if you don't like shadowing issues, and use `-Wshadow` and friends. And it won't be diagnosed by clang. The reason is, these self-assign diagnostics only work for builtin assignment operators. Which makes sense, one could have a very special operator=, that does something unusual in case of self-assignment, so it may make sense to not warn on that. But while it may be intentional in some cases, it may be a bug in other cases, so it would be really great to have some [opt-in] diagnostic about it... For now, this diff restructures `SelfAssignment` diag group, splits it into `SelfAssignmentBuiltin` (as what is already in trunk), and the new `SelfAssignmentOverloaded`, which is not enabled by default/`-Wall`. For now i have put it into `-Wextra`, but i don't know if it should be there. Additionally, a question: what should be done for trivial assignment operators? Perhaps this should be split even more, and if the operator is trivial implicit (or even trivial user-defined =default ?), it should even warn in `-Wall`? I'm guessing the self-move, and self-field-assign warnings should also be adjusteddiagnostic about it... to work for overloaded operators, but i did not want to bloat this diff.