On Mon, 1 Jun 2026, Jason Merrill wrote: > 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?
Just created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125559 > > > `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. Makes sense, I guess you can argue the overload set uniquely identifies a single specialization and deduction is the way to determine that.
