On 7/31/26 12:38 PM, Marek Polacek wrote:
On Thu, Jul 30, 2026 at 09:35:26AM -0400, Jason Merrill wrote:
On 7/28/26 1:34 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/16?
-- >8 --
Given
struct C { template <class T> void f(T); };
we handle "&template [:^^C::f:]" correctly because the spliced
expression is
BASELINK<OVERLOAD<TEMPLATE_DECL f>>, binfo C>
which is fine: we have an OVERLOAD around the TEMPLATE_DECL and
lookup_member wrapped the whole thing in a BASELINK. But when
we're splicing members_of(^^C, ac)[0], we ended up with
OVERLOAD<TEMPLATE_DECL f>>
and then go down the wrong path in cp_parser_splice_expression.
splice already correctly adds the missing OVERLOAD but it also
needs to (maybe) add a BASELINK.
Yes, though I'm nervous about the use of currently_open_derived_class in
baselink_for_fns. Does that cause trouble with a splice after ->?
We test a splice after -> in e.g. member1.C and member3.C and they still pass.
And given
struct C {
void g (int);
};
C *pc = ...;
this
auto a = &pc->[: ^^C::g :];
is invalid (clang++ also rejects).
...but we don't have a test for a valid &p->[: x :] so this
version adds it.
+void
+g (C *pc)
+{
+ const int *p = &pc->[: ^^C::val :];
+}
That tests the case where currently_open_derived_class is null, so it
doesn't matter. How about a case where we're in a member function of a
class derived from C and the object argument is a different derived class?
Jason
