thrust::find doesn't handle asymmetric equality operator

[dkolsen-pgi]

thrust::find fails to compile when the input iterator's value type is different from the type of the value being searched for and neither type is convertible to the other, even when there is an overloaded operator== that takes objects of those two different types.

Given the following CUDA program:

#include <thrust/host_vector.h>
#include <thrust/device_vector.h>
#include <thrust/find.h>
#include <cassert>

class Weird {
  int value;
 public:
  friend __host__ __device__ bool operator==(int x, Weird y) {
    return x == y.value;
  }
  __host__ __device__ Weird(int val, int) : value(val) { }
};

int main() {
  thrust::host_vector<int> v;
  for (int i = 0; i < 10000; ++i) {
    v.push_back(i);
  }
  thrust::device_vector<int> dv(v);
  auto result = thrust::find(dv.begin(), dv.end(), Weird(333, 0));
  assert(*result == 333);
}

When compiled with NVCC 11.0 and the latest Thrust source from the main branch, this fails with:

/proj/cuda/thrust/master/thrust/detail/functional/operators/operator_adaptors.h(108): error: function "thrust::equal_to<T>::operator() [with T=int]" cannot be ca
lled with the given argument list
            argument types are: (int, Weird)
            object type is: thrust::equal_to<int>

(followed by a typical template instantiation novel).

This is a recent regression. It broke somewhere between July 3 and July 6. I have not looked to see which commit might have caused the regression. When compiled with the Thrust in CUDA 11.0, this test case compiles successfully.

[alliepiper]

It is likely related to 0b48df1.

It looks like adding a equal_to<void> specialization (like in thrust/functional.h in b528451) should fix this.

[dkolsen-pgi]

I just realized that the regression is in the 1.9.10-1 branch, not just in main. This is a regression in our soon-to-be-code-frozen release. Please get the fix into 1.9.10-1 ASAP.

[alliepiper]

If it's what I think it is, we can revert the change in the staging branch ASAP. We should be able to just revert the commit that was likely to introduce this.

If you get a chance to test this out tonight let me know, but otherwise I'll test it out and integrate it tomorrow.

In your thrust git repo, checkout the staging branch and revert f483906.

git checkout staging/1.9.10-1
git revert f483906

[alliepiper]

Confirmed that reverting f483906 fixes the regression. Fixed in perforce CL 28805582 and staging/1.9.10-1 commit c3c368a.

Let's leave this issue open until we properly address this in main.