On 5/25/26 11:58 AM, Eczbek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu.
This accidentally allows `&(A::operator int);` to compile.
As Patrick mentioned on the other version of the patch, this is an
existing bug with &(A::f<int>). Patrick, is there a PR for that?
`auto f = &(A::operator int);` correctly errors, but emits a funny message: "note: (a pointer
to member can only be formed with '&A::operator int<int>')"
-- >8 --
Taking the address of a conversion function template instantiation
incorrectly errors.
PR c++/122383
gcc/cp/ChangeLog:
* pt.cc (resolve_overloaded_unification): If expr represents a
conversion function template instantiation, call
lookup_template_function with baselink, then fall through to
TEMPLATE_ID_EXPR check.
Let's describe implementation strategy in the main commit message and/or
code comments rather than in the ChangeLog entry.
@@ -25212,7 +25213,18 @@ resolve_overloaded_unification (tree tparms,
/* Strip baselink information. */
if (BASELINK_P (arg))
- arg = BASELINK_FUNCTIONS (arg);
+ {
+ baselink = arg;
+ arg = BASELINK_FUNCTIONS (arg);
+ }
+
+ if (TREE_CODE (arg) == OVERLOAD
+ && IDENTIFIER_CONV_OP_P (OVL_NAME (arg)))
+ {
+ tree targs = make_tree_vec (1);
+ TREE_VEC_ELT (targs, 0) = BASELINK_OPTYPE (baselink);
This assumes a template with a single template parameter; it doesn't
work for e.g.
struct A {
template<typename T, typename U>
operator T U::*() {
return 0;
}
};
int main() {
(void) &A::operator int A::*;
}
to handle the general case you need to deduce the template arguments.
Jason
