fix: guard against self-move-assignment in RE2::Set and FilteredRE2 (fixes #615)

[jdymitarai]

Fixes #615

Problem

The move-assignment operators in RE2::Set and FilteredRE2 employ the destroy-then-placement-new idiom:

RE2::Set& RE2::Set::operator=(Set&& other) {
  this->~Set();
  (void) new (this) Set(std::move(other));
  return *this;
}

If an object is move-assigned to itself (this == &other), this->~Set() (or this->~FilteredRE2()) executes first, destroying internal member vectors and releasing resources. Then, the placement-new move constructor attempts to read from other, which is the destroyed object, resulting in use-after-free/use-after-destroy undefined behavior and potential double-free upon subsequent destruction.

Solution

Add a standard self-assignment guard (if (this != &other)) to both RE2::Set::operator=(Set&&) and FilteredRE2::operator=(FilteredRE2&&).

Verification

• Added self-move-assignment regression tests to TEST(Set, MoveSemantics) in re2/testing/set_test.cc and TEST(FilteredRE2Test, MoveSemantics) in re2/testing/filtered_re2_test.cc.
• Built and ran both unit test suites with MSVC 2022: all tests pass.

[jdymitarai]

Closing this PR to avoid review overhead on the team. The context remains in the thread for future reference if helpful. Thanks for your time.