On Fri, 3 Jun 2022, Marek Polacek wrote:
> On Fri, Jun 03, 2022 at 11:16:26AM -0400, Jason Merrill via Gcc-patches wrote:
> > On 6/3/22 11:04, Patrick Palka wrote:
> > > > > @@ -4319,15 +4319,32 @@ maybe_dummy_object (tree type, tree* binfop)
> > > > > if (binfop)
> > > > >*binfop =
On Fri, Jun 03, 2022 at 11:16:26AM -0400, Jason Merrill via Gcc-patches wrote:
> On 6/3/22 11:04, Patrick Palka wrote:
> > > > @@ -4319,15 +4319,32 @@ maybe_dummy_object (tree type, tree* binfop)
> > > > if (binfop)
> > > >*binfop = binfo;
> > > >- if (current_class_ref
> > > > -
n progress.
-- >8 --
Subject: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call
[PR105637]
In non-dependent23.C below we expect the BaseClass::baseDevice calls
to
resolve to the second, third and fourth overloads respectively in
light
of the cv-qualifiers of 'this' in each case. But e
are
> > > > > > > > > > going to reject it later in
> > > > > > > > > > build_new_method_call.) */
> > > > > > > > > > - object = build_dummy_object (BINFO_TYPE
> > > >
. And we might as well handle this in
maybe_dummy_object for benefit of all callers. How does the following
look? Smoke tested with RUNTESTFLAGS="dg.exp=*.C", full bootstrap and
regtesting in progress.
-- >8 --
Subject: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call
[PR10
> > > > > (fn)),
> > > > > > > > - NULL);
> > > > > > > > + {
> > > > > > > > + if (current_class_ref)
> > > > > > > > + {
> &g
the following
look? Smoke tested with RUNTESTFLAGS="dg.exp=*.C", full bootstrap and
regtesting in progress.
-- >8 --
Subject: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call
[PR105637]
In non-dependent23.C below we expect the BaseClass::baseDevice calls to
resolve to the
gt; > > > > > quals);
> > > > > > + }
> > > > > > + object = maybe_dummy_object (object_type, NULL);
> > > > > > + }
> > > > > >result = build_new_method_call (object, fn, args,
> >
n progress.
-- >8 --
Subject: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]
In non-dependent23.C below we expect the BaseClass::baseDevice calls to
resolve to the second, third and fourth overloads respectively in light
of the cv-qualifiers of 'this' in each case. But e
LL_TREE,
> > > > > (disallow_virtual
> > > >
> > > > Drat, this fix doesn't interact well with 'this'-capturing lambdas:
> > > >
> > > > struct BaseClass {
> > > > void ba
t; > >void baseDevice() const = delete; // #2
> > > };
> > >
> > > template
> > > struct TopClass : T {
> > >void failsToCompile() {
> > > [this] { BaseClass::baseDevice(); }();
> > >
On Thu, 26 May 2022, Jason Merrill wrote:
> On 5/26/22 14:57, Patrick Palka wrote:
> > On Thu, 26 May 2022, Patrick Palka wrote:
> >
> > > Here we expect the calls to BaseClass::baseDevice resolve to the second,
> > > third and fourth overloads respectively in light of the cv-qualifiers
> > > of
On 5/26/22 14:57, Patrick Palka wrote:
On Thu, 26 May 2022, Patrick Palka wrote:
Here we expect the calls to BaseClass::baseDevice resolve to the second,
third and fourth overloads respectively in light of the cv-qualifiers
of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the
On Thu, 26 May 2022, Patrick Palka wrote:
> Here we expect the calls to BaseClass::baseDevice resolve to the second,
> third and fourth overloads respectively in light of the cv-qualifiers
> of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the
> calls incorrectly resolve to the
Here we expect the calls to BaseClass::baseDevice resolve to the second,
third and fourth overloads respectively in light of the cv-qualifiers
of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the
calls incorrectly resolve to the first overload at instantiation time.
This happens
15 matches
Mail list logo
