Hi all, I noticed that gcc doesn't have an option to warn the user when they're breaking C++'s "Rule of Three" (or Five (or Zero)). For example, this code doesn't trigger anything when built with e.g. -Wall -Wextra -Wpedantic -Weffc++: class Type { ~Type() {} }; int main() { Type t; return 0; } It would be useful to have a way catch these at compile time.
https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) This is the first time I have seen this rule before ...
Your example doesn't even compile, the destructor is private. GCC now has -Wdeprecated-copy which warns for this fixed example: struct Type { ~Type() {} }; int main() { Type t; Type tt = t; t = tt; } r.cc: In function 'int main()': r.cc:10:13: warning: implicitly-declared 'constexpr Type::Type(const Type&)' is deprecated [-Wdeprecated-copy] 10 | Type tt = t; | ^ r.cc:3:5: note: because 'Type' has user-provided 'Type::~Type()' 3 | ~Type() | ^ r.cc:11:7: warning: implicitly-declared 'constexpr Type& Type::operator=(const Type&)' is deprecated [-Wdeprecated-copy] 11 | t = tt; | ^~ r.cc:3:5: note: because 'Type' has user-provided 'Type::~Type()' 3 | ~Type() | ^ These warnings are given unless the copy constructor and copy assignment operator are user-declared, which is pretty close to what you're requesting. The warnings are only issued if the implicitly-declared special member functions are actually used (because if they're never used then it doesn't matter if they're defined or not). I think this bug can be closed.
It is not the same and doesn't cover important cases: for example, the opposite one, there is a nontrivial copy ctor implementation but there is no nontrivial dtor. Or even between the special ctors, or there is move ctor but no move assignment (and viceversa).
Created attachment 52401 [details] Basic patch (no tests) Attached is a simple patch adding a warning checks for violations of the Rule of Three and the Rule of Five (Core Guideline C.21) and enabling it at the -Wextra level. Not included is a check for the rule-of-four-and-a-half variant: a swapping by-value assignment operator overload, paired with the appropriate constructor, is enough to implement copy- or move-assignment. Rule of Zero would be much harder to check for, but it may be possible to diagnose certain violations of it, by looking at the code inside the destructor: if the delete operator, or a single function is invoked more than once in the destructor, it probably means the class manages more than one resource.