ss is error_mark_node; does it work to check that
specifically rather than !TYPE_P?
Indeed, checking for error_mark_node instead works nicely. Does the
following look OK? Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK.
-- >8 --
Subject: [PATCH] c++: cv-qualified dependent nam
ogether.) Testing in progress.
> >
> > For sake of concreteness, here's the full alternative patch for
> > consideration (modulo ChangeLog):
>
> This seems better. I think the only non-type return from
> lookup_template_class is error_mark_node; does it work to
On 6/2/21 4:56 PM, Patrick Palka wrote:
On Wed, 2 Jun 2021, Patrick Palka wrote:
On Wed, 2 Jun 2021, Jason Merrill wrote:
On 6/2/21 2:39 PM, Patrick Palka wrote:
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complai
On Wed, 2 Jun 2021, Patrick Palka wrote:
> On Wed, 2 Jun 2021, Jason Merrill wrote:
>
> > On 6/2/21 2:39 PM, Patrick Palka wrote:
> > > Here, the dependent template name in the return type of f() resolves to
> > > an alias of int& after substitution, and we end up complaining about
> > > qualifyi
On Wed, 2 Jun 2021, Jason Merrill wrote:
> On 6/2/21 2:39 PM, Patrick Palka wrote:
> > Here, the dependent template name in the return type of f() resolves to
> > an alias of int& after substitution, and we end up complaining about
> > qualifying this reference type with 'const' from cp_build_qual
On 6/2/21 2:39 PM, Patrick Palka wrote:
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complaining about
qualifying this reference type with 'const' from cp_build_qualified_type
rather than just silently dropping the qual
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complaining about
qualifying this reference type with 'const' from cp_build_qualified_type
rather than just silently dropping the qualification as per [dcl.ref]/1.
We already