mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-01-09 17:43:57 +00:00
980fb16f9a
address of an overloaded function (or function template), perform that resolution prior to determining the implicit conversion sequence. This resolution is not part of the implicit conversion sequence itself. Previously, we would always consider this resolution to be a function pointer decay, which was a lie: there might be an explicit & in the expression, in which case decay should not occur. This caused the CodeGen assertion in PR6973 (where we created a pointer to a pointer to a function when we should have had a pointer to a function), but it's likely that there are corner cases of overload resolution where this would have failed. Cleaned up the code involved in determining the type that will produced afer resolving the overloaded function reference, and added an assertion to make sure the result is correct. Fixes PR6973. llvm-svn: 102650
28 lines
503 B
C++
28 lines
503 B
C++
// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
|
|
template <typename T> void f(T) {}
|
|
template <typename T> void f() { }
|
|
|
|
void test() {
|
|
// CHECK: @_Z1fIiEvT_
|
|
void (*p)(int) = &f;
|
|
|
|
// CHECK: @_Z1fIiEvv
|
|
void (*p2)() = f<int>;
|
|
}
|
|
// CHECK: define linkonce_odr void @_Z1fIiEvT_
|
|
// CHECK: define linkonce_odr void @_Z1fIiEvv
|
|
|
|
namespace PR6973 {
|
|
template<typename T>
|
|
struct X {
|
|
void f(const T&);
|
|
};
|
|
|
|
template<typename T>
|
|
int g();
|
|
|
|
void h(X<int (*)()> xf) {
|
|
xf.f(&g<int>);
|
|
}
|
|
}
|