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 = b
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
> > > > -
ject 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
[PR105637]
In non-dependent23.C below we expect the Base
> > > invalid and
> > > > > > > > > > we are
> > > > > > > > > > going to reject it later in
> > > > > > > > > > build_new_method_call.) */
> > > > > > > &
ss it would work at
instantiation time though.
Ah, what seems to work well is directly using lambda_expr_this_capture
instead of maybe_resolve_dummy. 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=&qu
E
> > > > > > > > (BASELINK_ACCESS_BINFO
> > > > > > > > (fn)),
> > > > > > > > - NULL);
> > > > > > > > + {
> > > > > > > > + if (
da_expr_this_capture
instead of maybe_resolve_dummy. 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++
t; > > > > > + object_type = cp_build_qualified_type (object_type,
> > > > > > quals);
> > > > > > + }
> > > > > > + object = maybe_dummy_object (object_type, NULL);
> > > > > > + }
> > > &
ject 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 [PR105637]
In non-dependent23.C below we expect the Base
+ }
> > > > > result = build_new_method_call (object, fn, args, NULL_TREE,
> > > > > (disallow_virtual
> > > >
> > > > Drat, this fix doesn't interact well with 'this'-capturin
gt; > > struct BaseClass {
> > >void baseDevice();// #1
> > >void baseDevice() const = delete; // #2
> > > };
> > >
> > > template
> > > struct TopClass : T {
> > >voi
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
c
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 fi
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 b
15 matches
Mail list logo
