BaseSetOperators<T> is the parent class for both APIPermissionSet and ManifestPermissionSet, and provides set-like functionality.  It has deliberate copy constructor [1] and assignment operator [2] methods, which are designed to allow safely copying the permission sets.  However, in practice, these methods are not used.

These are declared in the file as

  explicit BaseSetOperators(const T& set) { this->operator=(set); }

  ~BaseSetOperators() {}

  T& operator=(const T& rhs) {
    return Assign(rhs);
  }

An example call site would be trying to copy an APIPermissionSet, which inherits BaseSetOperators<APIPermissionSet>().  However, the way the compiler looks for a suitable constructor is:

(A) Look for APIPermissionSet::APIPermissionSet(const APIPermissionSet&) (and variants)
(B) Look for BaseSetOperators<APIPermissionSet>::BaseSetOperators<APIPermissionSet>(const BaseSetOperators<APIPermissionSet>& other) (and variants)

The BaseSetOperator code effectively declares `BaseSetOperators<APIPermissionSet>::BaseSetOperators<APIPermissionSet>(const APIPermissionSet& other)`.

Since BaseSetOperators are designed to be copyable and assignable, we don't use DISALLOW_COPY_AND_ASSIGN().  The only member in BaseSetOperators in the map, which is of type `std::map<ElementIDType, linked_ptr<ElementType>>`, which is copyable/assignable.  This results in the compiler "helpfully" generating the missing constructor functions from (A).  This means that all the bespoke copying code we had in [1], [2], and [3] are completely ignored, and the map is directly copied.

What's more, it looks like at least two tests are exercising this (improper) behavior.