Fix #15156: Enhancement: Add support for move-assignment for operatorEqToSelf - #8977

AI review

The main problem: the check now flags a move assignment whenever a deleted member is assigned later, without regard to where the new value comes from. A common move idiom is to take the source pointer into a temporary and null it before the delete, e.g. int* t = std::exchange(o.p, nullptr); delete p; p = t;. That is safe on self-move, and the PR reports it anyway. Copy assignment has the same heuristic and the same false positive with int* t = new int(*o.p); delete p; p = t;. It matters more for move assignment because the temporary pattern is the usual way to write a self-safe move.

The new test is a weak example. On self-move, delete p; p = o.p; o.p = nullptr; leaves p == nullptr. There is no double free and no dangling pointer; the object only loses its value. The test has no negative cases for move assignment either: no this != &o guard, no swap, no take-then-delete.

As before, if (this != std::addressof(o)) is not recognised as a self-check. This already applied to copy assignment, but the guard is common in move assignments, so they will now be flagged too.

Otherwise the one-line change does what it is meant to do. I found no crashes or other regressions.

Testing

I built cppcheck and testrunner in pr/. ./testrunner TestClass ran 202 tests with 0 failures, including the new operatorEqToSelf10.

I ran cppcheck -q --enable=warning on several move-assignment variants:

• Not reported, correctly:
  • a this != &o / &o != this guard
  • if (this == &o) return *this;
  • if (this == &o) {} else {...}
  • std::swap(p, o.p)
• Reported, correctly:
  • delete p; p = std::exchange(o.p, nullptr);, which leaves a dangling p on self-move
  • const F&& with new
  • a class template K<T>
• Reported, but the code is safe on self-move (false positive):

#include <utility>
class E3 { int*p; public:
  E3& operator=(E3&& o) noexcept { int* t = std::exchange(o.p, nullptr); delete p; p = t; return *this; } };
class E2 { int*p; public:
  E2& operator=(E2&& o) noexcept { int* t = o.p; o.p = nullptr; delete p; p = t; return *this; } };

Command: ../pr/cppcheck -q --enable=warning c.cpp

Output:

c.cpp:3:7: warning: 'operator=' should check for assignment to self to avoid problems with dynamic memory. [operatorEqToSelf]

E2 gets the same warning (b.cpp:4:7).

• Not recognised as a self-check: if (this != std::addressof(o)) {...} is still reported. Copy assignment already behaved this way.

I did not build base/. The rvalue-reference parameter was skipped entirely there, because the type walk-back stopped at &&, so base cannot report these move-assignment cases.

Automated review of 431ea32 by Claude. The pull request was built and tested locally.