Clang does not realize inaccessible user-defined operator delete until it is called

[wangbo15]

Consider the following code:

class QCachedT
{
  static void operator delete(void *, int) {}
};

int main() {
     auto a = new QCachedT;
     //QCachedT::operator delete(a, 10);     
}

It appears that clang does not complain about anything about the private operator delete of QcacheT when it is dynamically instantiated. Only when the operator is explicitly called will the compiler reject the code. However, there is no need to do so in GCC, EDG, and MSVC:

https://godbolt.org/z/rvs1bjavh

Considering that clang will also reject the code without explicit calling of operator delete when it defaults, it seems to be more like a bug of clang:

class QCachedT
{
  static void operator delete(void *){} 
};

int main() {
     auto a = new QCachedT;    
}

https://godbolt.org/z/8oso11haf

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Bo Wang (wangbo15)

Consider the following code:

class QCachedT
{
  static void operator delete(void *, int) {}
};

int main() {
     auto a = new QCachedT;
     //QCachedT::operator delete(a, 10);     
}

It appears that clang does not complain about anything about the private operator delete of QcacheT when it is dynamically instantiated. Only when the operator is explicitly called will the compiler reject the code. However, there is no need to do so in GCC, EDG, and MSVC:

https://godbolt.org/z/rvs1bjavh

Considering that clang will also reject the code without explicit calling of operator delete when it defaults, it seems to be more like a bug of clang:

class QCachedT
{
  static void operator delete(void *){} 
};

int main() {
     auto a = new QCachedT;    
}

https://godbolt.org/z/8oso11haf