The return value of every assign operator should be Type&, not only for copy and move assign operators. This check and its test was implemented.
Details
- Reviewers
hokein alexfh - Commits
- rG4530b52a23c1: [clang-tidy] misc-assign-operator-signature checker checks return value of all…
rCTE264251: [clang-tidy] misc-assign-operator-signature checker checks return value of all…
rL264251: [clang-tidy] misc-assign-operator-signature checker checks return value of…
Diff Detail
- Repository
- rL LLVM
Event Timeline
I don't think this is a safe assumption to make -- for instance, DSLs tend to have operator overload return types that aren't necessarily the same as the class type. Also, it's quite common for older code (pre C++11) to return void and make these functions private (with no definition) as an early form of deleting the operator.
How many additional diagnostics does this modification produce over some large code bases (particularly ones with DSLs if you can narrow the test field a bit)?
This checker will not warn on private methods.
About EDSLs, I think they are not the common case. In case it is important, it might make sense to make this configurable, but I think the minority of the C++ projects have EDSLs so it make more sense to warn on those cases by default. What do you think?
Good deal.
About EDSLs, I think they are not the common case. In case it is important, it might make sense to make this configurable, but I think the minority of the C++ projects have EDSLs so it make more sense to warn on those cases by default. What do you think?
That's why I am wondering about how much this increases the false positive rate. I don't think DSLs are going to be a huge problem, but if it turns out they are, then a configuration option makes sense. If we don't see a large increase, then no need to waste the effort on an option.
Also, this appears to be changing the behavior of the cppcoreguidelines-c-copy-assignment-signature alias. If the core guidelines don't prohibit this behavior under that rule, we should not trigger the diagnostic if the user enabled the check via cppcoreguidelines-c-copy-assignment-signature instead of misc-assign-operator-signature. Check out MoveConstructorInitCheck as an example of how we have handled this before.
clang-tidy/misc/AssignOperatorSignatureCheck.cpp | ||
---|---|---|
39 ↗ | (On Diff #51016) | nit: could you +2 the line to be consistent with the rest of the code |
According to cpp core guidelines any assignment operator should return *this.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-assignment-op
So in case this check is activated by using an alias it should not be a special case.
Oh, I was searching in the C++ Core Guidlines, but at the wrong place because I did not find it. So I will change this option to be enabled by default. DSL users who do not follow this rule for the non copy and non move assign operators can disable it.
I'd go without the option until we find a use case for it in real code.
clang-tidy/misc/AssignOperatorSignatureCheck.cpp | ||
---|---|---|
48 ↗ | (On Diff #51435) | Just do whatever clang-format -style=llvm does. |