Bug 88050 - Add a warning for breaking the "Rule of Three"
Summary: Add a warning for breaking the "Rule of Three"
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: new-warning, new_warning
  Show dependency treegraph
Reported: 2018-11-15 19:21 UTC by martingalvan
Modified: 2022-02-11 03:39 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2018-11-16 00:00:00

Basic patch (no tests) (1.45 KB, patch)
2022-02-10 09:14 UTC, felix
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description martingalvan 2018-11-15 19:21:59 UTC
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

int main()
    Type t;

    return 0;

It would be useful to have a way catch these at compile time.
Comment 1 Andrew Pinski 2018-11-15 19:25:02 UTC

This is the first time I have seen this rule before ...
Comment 2 Jonathan Wakely 2018-11-16 11:35:28 UTC
Your example doesn't even compile, the destructor is private.

GCC now has -Wdeprecated-copy which warns for this fixed example:

struct 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.
Comment 3 Daniel Gutson 2018-11-16 12:24:35 UTC
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).
Comment 4 felix 2022-02-10 09:14:26 UTC
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.