ly I noticed that unlike the inherited guide tiebreaker, the
inherited ctor tiebreaker doesn't mention ellipses, which seems
surprising: https://eel.is/c++draft/over.match.best#general-2.7
Here's v2 which is just a tidied up version of v1 along with an extra
test (no additional functional ch
uide_p (cand1->fn);
> > > > > + bool inherited2 = inherited_guide_p (cand2->fn);
> > > > > + if (int diff = inherited2 - inherited1)
> > > > > + {
> > > > > + for (i = 0; i < len; ++i)
> > > > > +
#x27;t mention ellipses, which seems
surprising: https://eel.is/c++draft/over.match.best#general-2.7
Here's v2 which is just a tidied up version of v1 along with an extra
test (no additional functional change):
-- >8 --
Subject: [PATCH] c++: inherited CTAD fixes [PR116276]
This implement
> > > + if (!same_type_p (t1->type, t2->type))
> >
> > I'm not sure this comparison distinguishes between ellipse and non-ellipse?
> > There doesn't seem to be a testcase for that.
>
> Unfortunately I haven't been able to come up with a
On Fri, 9 Aug 2024, Jason Merrill wrote:
> On 8/8/24 1:00 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk/14?
> >
> > -- >8 --
> >
> > This implements the inherited vs non-inherited guide tiebreaker
> > specified by P2582R1. In ord
On 8/8/24 1:00 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk/14?
-- >8 --
This implements the inherited vs non-inherited guide tiebreaker
specified by P2582R1. In order to track inherited-ness of a guide
it seems natural to reuse the la
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk/14?
-- >8 --
This implements the inherited vs non-inherited guide tiebreaker
specified by P2582R1. In order to track inherited-ness of a guide
it seems natural to reuse the lang_decl_fn::context field that already
tra
