Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On 1/22/21 4:45 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 1:58 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Thu, 21 Jan 2021, Jason Merrill wrote:
On 1/21/21 11:22 AM, Patrick Palka wrote:
Here at parse time finish_qualified_id_expr adds an implicit
'this->' to
the expression tmp::integral (because it's type-dependent,
and
also
current_class_ptr is set) within the trailing return type, and
later
during substitution we can't resolve the 'this' since
tsubst_function_type does inject_this_parm only for non-static
member
functions which tmp::func is not.
It seems the root of the problem is that we set
current_class_ptr
when
parsing the signature of a static member function. Since
explicit
uses
of 'this' are already not allowed in this context, we probably
shouldn't
be doing inject_this_parm either.
Hmm, 'this' is defined in a static member function, it's just
ill-formed to
use it:
7.5.2/2: "... [this] shall not appear within the declaration of a
static
member function (although its type and value category are defined
within a
static member function as they are within a non-static member
function).
[Note: This is because declaration matching does not occur until
the
complete
declarator is known. — end note]"
Ah, I see.
Perhaps maybe_dummy_object needs to be smarter about recognizing
static
context. Or perhaps there's no way to tell the difference between
the
specified behavior above and the behavior with your patch, but:
The note suggests that we need to test the case of an out-of-class
definition
of a static member function (template); we must inject_this_parm
when
parsing
such a declaration, since we don't know it's static until we match
it
to the
declaration in the class. I'm guessing that this would lead to
the
same
problem.
Good point, we do get a signature mismatch error in this case, due
to
'this->' appearing in the trailing return type out-of-class
declaration
but not in that of the in-class declaration, so the trailing return
types don't match up. In light of this case, it doesn't seem
possible
for maybe_dummy_object to distinguish between a static and
non-static
context when parsing the trailing return type of the declaration.
So perhaps we should mirror at substitution time what we do at parse
time, and inject 'this' also when substituting into the function
type of
a static member function? That way, we'll resolve the use of
'this->'
and then discard it the RHS of -> is a static member function, or
complain that 'this' is not a constant expression if the RHS is a
non-static member function.
The following patch performs that, and seems to pass light testing.
Full testing in progress. Revised commit message is still a WIP.
How does this approach look?
Sorry for the spam, but I'd also like to propose a more conservative and
targeted approach that basically undoes part of the r9-5972 patch which
caused the regression.
According to the email thread at
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
the hunk from r9-5972
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if (!shared_member_p (expr)
+ if ((type_dependent_expression_p (expr)
+ || !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
current_nonlambda_class_type ()))
was added to avoid calling shared_member_p here when the overload set
contains a dependent USING_DECL. But according to
https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513237.html if
an overload set contains a dependent USING_DECL, then it'll be the first
in the overload set. So we could partially revert the r9-5972 patch and
do:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index c6b4c70dc0f..6b0d68ae4bf 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2214,7 +2214,7 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if ((type_dependent_expression_p (expr)
+ if ((TREE_CODE (get_first_fn (expr)) == USING_DECL
|| !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
The above pases 'make check-c++', and allows us to compile pr97399a.C
successfully, but we'd still ICE on the invalid pr97399b.C.
What if we flipped the sense of the type_dependent_expression_p check, so
we
never add this-> if the function operand is dependent?
Looks like this doesn't survive 'make
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 1:58 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/22/21 12:59 PM, Patrick Palka wrote:
> > > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > > >
> > > > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > > > >
> > > > > > On Thu, 21 Jan 2021, Jason Merrill wrote:
> > > > > >
> > > > > > > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > > > > > > Here at parse time finish_qualified_id_expr adds an implicit
> > > > > > > > 'this->' to
> > > > > > > > the expression tmp::integral (because it's type-dependent,
> > > > > > > > and
> > > > > > > > also
> > > > > > > > current_class_ptr is set) within the trailing return type, and
> > > > > > > > later
> > > > > > > > during substitution we can't resolve the 'this' since
> > > > > > > > tsubst_function_type does inject_this_parm only for non-static
> > > > > > > > member
> > > > > > > > functions which tmp::func is not.
> > > > > > > >
> > > > > > > > It seems the root of the problem is that we set
> > > > > > > > current_class_ptr
> > > > > > > > when
> > > > > > > > parsing the signature of a static member function. Since
> > > > > > > > explicit
> > > > > > > > uses
> > > > > > > > of 'this' are already not allowed in this context, we probably
> > > > > > > > shouldn't
> > > > > > > > be doing inject_this_parm either.
> > > > > > >
> > > > > > > Hmm, 'this' is defined in a static member function, it's just
> > > > > > > ill-formed to
> > > > > > > use it:
> > > > > > >
> > > > > > > 7.5.2/2: "... [this] shall not appear within the declaration of a
> > > > > > > static
> > > > > > > member function (although its type and value category are defined
> > > > > > > within a
> > > > > > > static member function as they are within a non-static member
> > > > > > > function).
> > > > > > > [Note: This is because declaration matching does not occur until
> > > > > > > the
> > > > > > > complete
> > > > > > > declarator is known. — end note]"
> > > > > >
> > > > > > Ah, I see.
> > > > > >
> > > > > > >
> > > > > > > Perhaps maybe_dummy_object needs to be smarter about recognizing
> > > > > > > static
> > > > > > > context. Or perhaps there's no way to tell the difference between
> > > > > > > the
> > > > > > > specified behavior above and the behavior with your patch, but:
> > > > > > >
> > > > > > > The note suggests that we need to test the case of an out-of-class
> > > > > > > definition
> > > > > > > of a static member function (template); we must inject_this_parm
> > > > > > > when
> > > > > > > parsing
> > > > > > > such a declaration, since we don't know it's static until we match
> > > > > > > it
> > > > > > > to the
> > > > > > > declaration in the class. I'm guessing that this would lead to
> > > > > > > the
> > > > > > > same
> > > > > > > problem.
> > > > > >
> > > > > > Good point, we do get a signature mismatch error in this case, due
> > > > > > to
> > > > > > 'this->' appearing in the trailing return type out-of-class
> > > > > > declaration
> > > > > > but not in that of the in-class declaration, so the trailing return
> > > > > > types don't match up. In light of this case, it doesn't seem
> > > > > > possible
> > > > > > for maybe_dummy_object to distinguish between a static and
> > > > > > non-static
> > > > > > context when parsing the trailing return type of the declaration.
> > > > > >
> > > > > > So perhaps we should mirror at substitution time what we do at parse
> > > > > > time, and inject 'this' also when substituting into the function
> > > > > > type of
> > > > > > a static member function? That way, we'll resolve the use of
> > > > > > 'this->'
> > > > > > and then discard it the RHS of -> is a static member function, or
> > > > > > complain that 'this' is not a constant expression if the RHS is a
> > > > > > non-static member function.
> > > > > >
> > > > > > The following patch performs that, and seems to pass light testing.
> > > > > > Full testing in progress. Revised commit message is still a WIP.
> > > > > > How does this approach look?
> > > >
> > > > Sorry for the spam, but I'd also like to propose a more conservative and
> > > > targeted approach that basically undoes part of the r9-5972 patch which
> > > > caused the regression.
> > > >
> > > > According to the email thread at
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
> > > > the hunk from r9-5972
> > > >
> > > > --- a/gcc/cp/semantics.c
> > > > +++ b/gcc/cp/semantics.c
> > > > @@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
> > > >{
> > > > /* See if any of the functions are non-static members. */
> > > > /* If so, the expression may be relative to 'this'. */
> > > > - if (!shared_member_p (expr)
> > > > + if ((type_dependent_expression_p (expr)
> > > > + || !shared_member_p (expr))
> > > > && current_class_ptr
> > > > && DERIVED_FROM_P
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On 1/22/21 1:58 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Thu, 21 Jan 2021, Jason Merrill wrote:
On 1/21/21 11:22 AM, Patrick Palka wrote:
Here at parse time finish_qualified_id_expr adds an implicit
'this->' to
the expression tmp::integral (because it's type-dependent, and
also
current_class_ptr is set) within the trailing return type, and later
during substitution we can't resolve the 'this' since
tsubst_function_type does inject_this_parm only for non-static
member
functions which tmp::func is not.
It seems the root of the problem is that we set current_class_ptr
when
parsing the signature of a static member function. Since explicit
uses
of 'this' are already not allowed in this context, we probably
shouldn't
be doing inject_this_parm either.
Hmm, 'this' is defined in a static member function, it's just
ill-formed to
use it:
7.5.2/2: "... [this] shall not appear within the declaration of a
static
member function (although its type and value category are defined
within a
static member function as they are within a non-static member
function).
[Note: This is because declaration matching does not occur until the
complete
declarator is known. — end note]"
Ah, I see.
Perhaps maybe_dummy_object needs to be smarter about recognizing
static
context. Or perhaps there's no way to tell the difference between the
specified behavior above and the behavior with your patch, but:
The note suggests that we need to test the case of an out-of-class
definition
of a static member function (template); we must inject_this_parm when
parsing
such a declaration, since we don't know it's static until we match it
to the
declaration in the class. I'm guessing that this would lead to the
same
problem.
Good point, we do get a signature mismatch error in this case, due to
'this->' appearing in the trailing return type out-of-class declaration
but not in that of the in-class declaration, so the trailing return
types don't match up. In light of this case, it doesn't seem possible
for maybe_dummy_object to distinguish between a static and non-static
context when parsing the trailing return type of the declaration.
So perhaps we should mirror at substitution time what we do at parse
time, and inject 'this' also when substituting into the function type of
a static member function? That way, we'll resolve the use of 'this->'
and then discard it the RHS of -> is a static member function, or
complain that 'this' is not a constant expression if the RHS is a
non-static member function.
The following patch performs that, and seems to pass light testing.
Full testing in progress. Revised commit message is still a WIP.
How does this approach look?
Sorry for the spam, but I'd also like to propose a more conservative and
targeted approach that basically undoes part of the r9-5972 patch which
caused the regression.
According to the email thread at
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
the hunk from r9-5972
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if (!shared_member_p (expr)
+ if ((type_dependent_expression_p (expr)
+ || !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
current_nonlambda_class_type ()))
was added to avoid calling shared_member_p here when the overload set
contains a dependent USING_DECL. But according to
https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513237.html if
an overload set contains a dependent USING_DECL, then it'll be the first
in the overload set. So we could partially revert the r9-5972 patch and
do:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index c6b4c70dc0f..6b0d68ae4bf 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2214,7 +2214,7 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if ((type_dependent_expression_p (expr)
+ if ((TREE_CODE (get_first_fn (expr)) == USING_DECL
|| !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
The above pases 'make check-c++', and allows us to compile pr97399a.C
successfully, but we'd still ICE on the invalid pr97399b.C.
What if we flipped the sense of the type_dependent_expression_p check, so we
never add this-> if the function operand is dependent?
Looks like this doesn't survive 'make check-c++', we crash on the
testcase g++.dg/cpp1y/lambda-generic-this1a.C:
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 12:59 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Patrick Palka wrote:
> >
> > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > >
> > > > On Thu, 21 Jan 2021, Jason Merrill wrote:
> > > >
> > > > > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > > > > Here at parse time finish_qualified_id_expr adds an implicit
> > > > > > 'this->' to
> > > > > > the expression tmp::integral (because it's type-dependent, and
> > > > > > also
> > > > > > current_class_ptr is set) within the trailing return type, and later
> > > > > > during substitution we can't resolve the 'this' since
> > > > > > tsubst_function_type does inject_this_parm only for non-static
> > > > > > member
> > > > > > functions which tmp::func is not.
> > > > > >
> > > > > > It seems the root of the problem is that we set current_class_ptr
> > > > > > when
> > > > > > parsing the signature of a static member function. Since explicit
> > > > > > uses
> > > > > > of 'this' are already not allowed in this context, we probably
> > > > > > shouldn't
> > > > > > be doing inject_this_parm either.
> > > > >
> > > > > Hmm, 'this' is defined in a static member function, it's just
> > > > > ill-formed to
> > > > > use it:
> > > > >
> > > > > 7.5.2/2: "... [this] shall not appear within the declaration of a
> > > > > static
> > > > > member function (although its type and value category are defined
> > > > > within a
> > > > > static member function as they are within a non-static member
> > > > > function).
> > > > > [Note: This is because declaration matching does not occur until the
> > > > > complete
> > > > > declarator is known. — end note]"
> > > >
> > > > Ah, I see.
> > > >
> > > > >
> > > > > Perhaps maybe_dummy_object needs to be smarter about recognizing
> > > > > static
> > > > > context. Or perhaps there's no way to tell the difference between the
> > > > > specified behavior above and the behavior with your patch, but:
> > > > >
> > > > > The note suggests that we need to test the case of an out-of-class
> > > > > definition
> > > > > of a static member function (template); we must inject_this_parm when
> > > > > parsing
> > > > > such a declaration, since we don't know it's static until we match it
> > > > > to the
> > > > > declaration in the class. I'm guessing that this would lead to the
> > > > > same
> > > > > problem.
> > > >
> > > > Good point, we do get a signature mismatch error in this case, due to
> > > > 'this->' appearing in the trailing return type out-of-class declaration
> > > > but not in that of the in-class declaration, so the trailing return
> > > > types don't match up. In light of this case, it doesn't seem possible
> > > > for maybe_dummy_object to distinguish between a static and non-static
> > > > context when parsing the trailing return type of the declaration.
> > > >
> > > > So perhaps we should mirror at substitution time what we do at parse
> > > > time, and inject 'this' also when substituting into the function type of
> > > > a static member function? That way, we'll resolve the use of 'this->'
> > > > and then discard it the RHS of -> is a static member function, or
> > > > complain that 'this' is not a constant expression if the RHS is a
> > > > non-static member function.
> > > >
> > > > The following patch performs that, and seems to pass light testing.
> > > > Full testing in progress. Revised commit message is still a WIP.
> > > > How does this approach look?
> >
> > Sorry for the spam, but I'd also like to propose a more conservative and
> > targeted approach that basically undoes part of the r9-5972 patch which
> > caused the regression.
> >
> > According to the email thread at
> > https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
> > the hunk from r9-5972
> >
> > --- a/gcc/cp/semantics.c
> > +++ b/gcc/cp/semantics.c
> > @@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
> > {
> > /* See if any of the functions are non-static members. */
> > /* If so, the expression may be relative to 'this'. */
> > - if (!shared_member_p (expr)
> > + if ((type_dependent_expression_p (expr)
> > + || !shared_member_p (expr))
> >&& current_class_ptr
> >&& DERIVED_FROM_P (qualifying_class,
> > current_nonlambda_class_type ()))
> >
> > was added to avoid calling shared_member_p here when the overload set
> > contains a dependent USING_DECL. But according to
> > https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513237.html if
> > an overload set contains a dependent USING_DECL, then it'll be the first
> > in the overload set. So we could partially revert the r9-5972 patch and
> > do:
> >
> > diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> > index c6b4c70dc0f..6b0d68ae4bf 100644
> > --- a/gcc/cp/semantics.c
> > +++ b/gcc/cp/semantics.c
> > @@ -2214,7 +2214,7 @@ finish_qualified_id_expr (tree
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Thu, 21 Jan 2021, Jason Merrill wrote:
On 1/21/21 11:22 AM, Patrick Palka wrote:
Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
the expression tmp::integral (because it's type-dependent, and also
current_class_ptr is set) within the trailing return type, and later
during substitution we can't resolve the 'this' since
tsubst_function_type does inject_this_parm only for non-static member
functions which tmp::func is not.
It seems the root of the problem is that we set current_class_ptr when
parsing the signature of a static member function. Since explicit uses
of 'this' are already not allowed in this context, we probably shouldn't
be doing inject_this_parm either.
Hmm, 'this' is defined in a static member function, it's just ill-formed to
use it:
7.5.2/2: "... [this] shall not appear within the declaration of a static
member function (although its type and value category are defined within a
static member function as they are within a non-static member function).
[Note: This is because declaration matching does not occur until the complete
declarator is known. — end note]"
Ah, I see.
Perhaps maybe_dummy_object needs to be smarter about recognizing static
context. Or perhaps there's no way to tell the difference between the
specified behavior above and the behavior with your patch, but:
The note suggests that we need to test the case of an out-of-class definition
of a static member function (template); we must inject_this_parm when parsing
such a declaration, since we don't know it's static until we match it to the
declaration in the class. I'm guessing that this would lead to the same
problem.
Good point, we do get a signature mismatch error in this case, due to
'this->' appearing in the trailing return type out-of-class declaration
but not in that of the in-class declaration, so the trailing return
types don't match up. In light of this case, it doesn't seem possible
for maybe_dummy_object to distinguish between a static and non-static
context when parsing the trailing return type of the declaration.
So perhaps we should mirror at substitution time what we do at parse
time, and inject 'this' also when substituting into the function type of
a static member function? That way, we'll resolve the use of 'this->'
and then discard it the RHS of -> is a static member function, or
complain that 'this' is not a constant expression if the RHS is a
non-static member function.
The following patch performs that, and seems to pass light testing.
Full testing in progress. Revised commit message is still a WIP.
How does this approach look?
Sorry for the spam, but I'd also like to propose a more conservative and
targeted approach that basically undoes part of the r9-5972 patch which
caused the regression.
According to the email thread at
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
the hunk from r9-5972
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if (!shared_member_p (expr)
+ if ((type_dependent_expression_p (expr)
+ || !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
current_nonlambda_class_type ()))
was added to avoid calling shared_member_p here when the overload set
contains a dependent USING_DECL. But according to
https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513237.html if
an overload set contains a dependent USING_DECL, then it'll be the first
in the overload set. So we could partially revert the r9-5972 patch and
do:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index c6b4c70dc0f..6b0d68ae4bf 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2214,7 +2214,7 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if ((type_dependent_expression_p (expr)
+ if ((TREE_CODE (get_first_fn (expr)) == USING_DECL
|| !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
The above pases 'make check-c++', and allows us to compile pr97399a.C
successfully, but we'd still ICE on the invalid pr97399b.C.
What if we flipped the sense of the type_dependent_expression_p check,
so we never add this-> if the function operand is dependent?
-- >8 --
Subject: [PATCH] c++: 'this' injection and static member functions [PR97399]
gcc/cp/ChangeLog:
PR c++/97399
* parser.c (cp_parser_init_declarator): If the storage class
specifier is sc_static, pass
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Fri, 22 Jan 2021, Patrick Palka wrote:
> On Fri, 22 Jan 2021, Patrick Palka wrote:
>
> > On Thu, 21 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > > > the expression tmp::integral (because it's type-dependent, and also
> > > > current_class_ptr is set) within the trailing return type, and later
> > > > during substitution we can't resolve the 'this' since
> > > > tsubst_function_type does inject_this_parm only for non-static member
> > > > functions which tmp::func is not.
> > > >
> > > > It seems the root of the problem is that we set current_class_ptr when
> > > > parsing the signature of a static member function. Since explicit uses
> > > > of 'this' are already not allowed in this context, we probably shouldn't
> > > > be doing inject_this_parm either.
> > >
> > > Hmm, 'this' is defined in a static member function, it's just ill-formed
> > > to
> > > use it:
> > >
> > > 7.5.2/2: "... [this] shall not appear within the declaration of a static
> > > member function (although its type and value category are defined within a
> > > static member function as they are within a non-static member function).
> > > [Note: This is because declaration matching does not occur until the
> > > complete
> > > declarator is known. — end note]"
> >
> > Ah, I see.
> >
> > >
> > > Perhaps maybe_dummy_object needs to be smarter about recognizing static
> > > context. Or perhaps there's no way to tell the difference between the
> > > specified behavior above and the behavior with your patch, but:
> > >
> > > The note suggests that we need to test the case of an out-of-class
> > > definition
> > > of a static member function (template); we must inject_this_parm when
> > > parsing
> > > such a declaration, since we don't know it's static until we match it to
> > > the
> > > declaration in the class. I'm guessing that this would lead to the same
> > > problem.
> >
> > Good point, we do get a signature mismatch error in this case, due to
> > 'this->' appearing in the trailing return type out-of-class declaration
> > but not in that of the in-class declaration, so the trailing return
> > types don't match up. In light of this case, it doesn't seem possible
> > for maybe_dummy_object to distinguish between a static and non-static
> > context when parsing the trailing return type of the declaration.
> >
> > So perhaps we should mirror at substitution time what we do at parse
> > time, and inject 'this' also when substituting into the function type of
> > a static member function? That way, we'll resolve the use of 'this->'
> > and then discard it the RHS of -> is a static member function, or
> > complain that 'this' is not a constant expression if the RHS is a
> > non-static member function.
> >
> > The following patch performs that, and seems to pass light testing.
> > Full testing in progress. Revised commit message is still a WIP.
> > How does this approach look?
Sorry for the spam, but I'd also like to propose a more conservative and
targeted approach that basically undoes part of the r9-5972 patch which
caused the regression.
According to the email thread at
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516421.html
the hunk from r9-5972
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2096,7 +2096,8 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if (!shared_member_p (expr)
+ if ((type_dependent_expression_p (expr)
+ || !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
current_nonlambda_class_type ()))
was added to avoid calling shared_member_p here when the overload set
contains a dependent USING_DECL. But according to
https://gcc.gnu.org/pipermail/gcc-patches/2018-December/513237.html if
an overload set contains a dependent USING_DECL, then it'll be the first
in the overload set. So we could partially revert the r9-5972 patch and
do:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index c6b4c70dc0f..6b0d68ae4bf 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2214,7 +2214,7 @@ finish_qualified_id_expr (tree qualifying_class,
{
/* See if any of the functions are non-static members. */
/* If so, the expression may be relative to 'this'. */
- if ((type_dependent_expression_p (expr)
+ if ((TREE_CODE (get_first_fn (expr)) == USING_DECL
|| !shared_member_p (expr))
&& current_class_ptr
&& DERIVED_FROM_P (qualifying_class,
The above pases 'make check-c++', and allows us to compile pr97399a.C
successfully, but we'd still ICE on the invalid pr97399b.C.
> >
> > -- >8 --
> >
> > Subject: [PATCH] c++: 'this' injection and static member functions
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Fri, 22 Jan 2021, Patrick Palka wrote: > On Thu, 21 Jan 2021, Jason Merrill wrote: > > > On 1/21/21 11:22 AM, Patrick Palka wrote: > > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to > > > the expression tmp::integral (because it's type-dependent, and also > > > current_class_ptr is set) within the trailing return type, and later > > > during substitution we can't resolve the 'this' since > > > tsubst_function_type does inject_this_parm only for non-static member > > > functions which tmp::func is not. > > > > > > It seems the root of the problem is that we set current_class_ptr when > > > parsing the signature of a static member function. Since explicit uses > > > of 'this' are already not allowed in this context, we probably shouldn't > > > be doing inject_this_parm either. > > > > Hmm, 'this' is defined in a static member function, it's just ill-formed to > > use it: > > > > 7.5.2/2: "... [this] shall not appear within the declaration of a static > > member function (although its type and value category are defined within a > > static member function as they are within a non-static member function). > > [Note: This is because declaration matching does not occur until the > > complete > > declarator is known. — end note]" > > Ah, I see. > > > > > Perhaps maybe_dummy_object needs to be smarter about recognizing static > > context. Or perhaps there's no way to tell the difference between the > > specified behavior above and the behavior with your patch, but: > > > > The note suggests that we need to test the case of an out-of-class > > definition > > of a static member function (template); we must inject_this_parm when > > parsing > > such a declaration, since we don't know it's static until we match it to the > > declaration in the class. I'm guessing that this would lead to the same > > problem. > > Good point, we do get a signature mismatch error in this case, due to > 'this->' appearing in the trailing return type out-of-class declaration > but not in that of the in-class declaration, so the trailing return > types don't match up. In light of this case, it doesn't seem possible > for maybe_dummy_object to distinguish between a static and non-static > context when parsing the trailing return type of the declaration. > > So perhaps we should mirror at substitution time what we do at parse > time, and inject 'this' also when substituting into the function type of > a static member function? That way, we'll resolve the use of 'this->' > and then discard it the RHS of -> is a static member function, or > complain that 'this' is not a constant expression if the RHS is a > non-static member function. > > The following patch performs that, and seems to pass light testing. > Full testing in progress. Revised commit message is still a WIP. > How does this approach look? > > -- >8 -- > > Subject: [PATCH] c++: 'this' injection and static member functions [PR97399] > > gcc/cp/ChangeLog: > > PR c++/97399 > * parser.c (cp_parser_init_declarator): If the storage class > specifier is sc_static, pass true for static_p to > cp_parser_declarator. > (cp_parser_direct_declarator): Don't do inject_this_parm when > the function is specified as a friend. > * pt.c (tsubst_function_type): Also inject 'this' when > substituting into the function type of a static member > function. > > gcc/testsuite/ChangeLog: > > PR c++/88548 > PR c++/97399 > * g++.dg/cpp0x/this2.C: New test. > * g++.dg/gomp/this-1.C: Adjust expected error for use of 'this' > in signature of static member function. > * g++.dg/template/pr97399a.C: New test. > * g++.dg/template/pr97399b.C: New test. > --- > gcc/cp/parser.c | 2 +- > gcc/cp/pt.c | 13 +++-- > gcc/testsuite/g++.dg/template/pr97399a.C | 23 +++ > gcc/testsuite/g++.dg/template/pr97399b.C | 23 +++ > 4 files changed, 58 insertions(+), 3 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C > create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C > > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c > index 48437f23175..a0efa55d21e 100644 > --- a/gcc/cp/parser.c > +++ b/gcc/cp/parser.c > @@ -22122,7 +22122,7 @@ cp_parser_direct_declarator (cp_parser* parser, > > tree save_ccp = current_class_ptr; > tree save_ccr = current_class_ref; > - if (memfn) > + if (memfn && !friend_p) > /* DR 1207: 'this' is in scope after the cv-quals. */ > inject_this_parameter (current_class_type, cv_quals); > > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c > index ad855dbde72..d4763325e25 100644 > --- a/gcc/cp/pt.c > +++ b/gcc/cp/pt.c > @@ -15072,8 +15072,17 @@ tsubst_function_type (tree t, > >tree save_ccp = current_class_ptr; >tree
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Thu, 21 Jan 2021, Jason Merrill wrote: > On 1/21/21 11:22 AM, Patrick Palka wrote: > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to > > the expression tmp::integral (because it's type-dependent, and also > > current_class_ptr is set) within the trailing return type, and later > > during substitution we can't resolve the 'this' since > > tsubst_function_type does inject_this_parm only for non-static member > > functions which tmp::func is not. > > > > It seems the root of the problem is that we set current_class_ptr when > > parsing the signature of a static member function. Since explicit uses > > of 'this' are already not allowed in this context, we probably shouldn't > > be doing inject_this_parm either. > > Hmm, 'this' is defined in a static member function, it's just ill-formed to > use it: > > 7.5.2/2: "... [this] shall not appear within the declaration of a static > member function (although its type and value category are defined within a > static member function as they are within a non-static member function). > [Note: This is because declaration matching does not occur until the complete > declarator is known. — end note]" Ah, I see. > > Perhaps maybe_dummy_object needs to be smarter about recognizing static > context. Or perhaps there's no way to tell the difference between the > specified behavior above and the behavior with your patch, but: > > The note suggests that we need to test the case of an out-of-class definition > of a static member function (template); we must inject_this_parm when parsing > such a declaration, since we don't know it's static until we match it to the > declaration in the class. I'm guessing that this would lead to the same > problem. Good point, we do get a signature mismatch error in this case, due to 'this->' appearing in the trailing return type out-of-class declaration but not in that of the in-class declaration, so the trailing return types don't match up. In light of this case, it doesn't seem possible for maybe_dummy_object to distinguish between a static and non-static context when parsing the trailing return type of the declaration. So perhaps we should mirror at substitution time what we do at parse time, and inject 'this' also when substituting into the function type of a static member function? That way, we'll resolve the use of 'this->' and then discard it the RHS of -> is a static member function, or complain that 'this' is not a constant expression if the RHS is a non-static member function. The following patch performs that, and seems to pass light testing. Full testing in progress. Revised commit message is still a WIP. How does this approach look? -- >8 -- Subject: [PATCH] c++: 'this' injection and static member functions [PR97399] gcc/cp/ChangeLog: PR c++/97399 * parser.c (cp_parser_init_declarator): If the storage class specifier is sc_static, pass true for static_p to cp_parser_declarator. (cp_parser_direct_declarator): Don't do inject_this_parm when the function is specified as a friend. * pt.c (tsubst_function_type): Also inject 'this' when substituting into the function type of a static member function. gcc/testsuite/ChangeLog: PR c++/88548 PR c++/97399 * g++.dg/cpp0x/this2.C: New test. * g++.dg/gomp/this-1.C: Adjust expected error for use of 'this' in signature of static member function. * g++.dg/template/pr97399a.C: New test. * g++.dg/template/pr97399b.C: New test. --- gcc/cp/parser.c | 2 +- gcc/cp/pt.c | 13 +++-- gcc/testsuite/g++.dg/template/pr97399a.C | 23 +++ gcc/testsuite/g++.dg/template/pr97399b.C | 23 +++ 4 files changed, 58 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 48437f23175..a0efa55d21e 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -22122,7 +22122,7 @@ cp_parser_direct_declarator (cp_parser* parser, tree save_ccp = current_class_ptr; tree save_ccr = current_class_ref; - if (memfn) + if (memfn && !friend_p) /* DR 1207: 'this' is in scope after the cv-quals. */ inject_this_parameter (current_class_type, cv_quals); diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index ad855dbde72..d4763325e25 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -15072,8 +15072,17 @@ tsubst_function_type (tree t, tree save_ccp = current_class_ptr; tree save_ccr = current_class_ref; - tree this_type = (TREE_CODE (t) == METHOD_TYPE - ? TREE_TYPE (TREE_VALUE (arg_types)) : NULL_TREE); + tree this_type = NULL_TREE; + if (TREE_CODE (t) == METHOD_TYPE) +
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On 1/21/21 11:22 AM, Patrick Palka wrote:
Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
the expression tmp::integral (because it's type-dependent, and also
current_class_ptr is set) within the trailing return type, and later
during substitution we can't resolve the 'this' since
tsubst_function_type does inject_this_parm only for non-static member
functions which tmp::func is not.
It seems the root of the problem is that we set current_class_ptr when
parsing the signature of a static member function. Since explicit uses
of 'this' are already not allowed in this context, we probably shouldn't
be doing inject_this_parm either.
Hmm, 'this' is defined in a static member function, it's just ill-formed
to use it:
7.5.2/2: "... [this] shall not appear within the declaration of a static
member function (although its type and value category are defined within
a static member function as they are within a non-static member
function). [Note: This is because declaration matching does not occur
until the complete declarator is known. — end note]"
Perhaps maybe_dummy_object needs to be smarter about recognizing static
context. Or perhaps there's no way to tell the difference between the
specified behavior above and the behavior with your patch, but:
The note suggests that we need to test the case of an out-of-class
definition of a static member function (template); we must
inject_this_parm when parsing such a declaration, since we don't know
it's static until we match it to the declaration in the class. I'm
guessing that this would lead to the same problem.
Bootstrapped and regtested on x64_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/97399
* parser.c (cp_parser_init_declarator): If the storage class
specifier is sc_static, pass true for static_p to
cp_parser_declarator.
(cp_parser_direct_declarator): Don't do inject_this_parm when
the member function is static.
gcc/testsuite/ChangeLog:
PR c++/88548
PR c++/97399
* g++.dg/cpp0x/this2.C: New test.
* g++.dg/template/pr97399a.C: New test.
* g++.dg/template/pr97399b.C: New test.
---
gcc/cp/parser.c | 5 +++--
gcc/testsuite/g++.dg/cpp0x/this2.C | 8
gcc/testsuite/g++.dg/template/pr97399a.C | 11 +++
gcc/testsuite/g++.dg/template/pr97399b.C | 11 +++
4 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/this2.C
create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C
create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 48437f23175..18cf9888632 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21413,6 +21413,7 @@ cp_parser_init_declarator (cp_parser* parser,
bool is_non_constant_init;
int ctor_dtor_or_conv_p;
bool friend_p = cp_parser_friend_p (decl_specifiers);
+ bool static_p = decl_specifiers->storage_class == sc_static;
tree pushed_scope = NULL_TREE;
bool range_for_decl_p = false;
bool saved_default_arg_ok_p = parser->default_arg_ok_p;
@@ -21446,7 +21447,7 @@ cp_parser_init_declarator (cp_parser* parser,
= cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
flags, _dtor_or_conv_p,
/*parenthesized_p=*/NULL,
- member_p, friend_p, /*static_p=*/false);
+ member_p, friend_p, static_p);
/* Gather up the deferred checks. */
stop_deferring_access_checks ();
@@ -22122,7 +22123,7 @@ cp_parser_direct_declarator (cp_parser* parser,
tree save_ccp = current_class_ptr;
tree save_ccr = current_class_ref;
- if (memfn)
+ if (memfn && !static_p)
/* DR 1207: 'this' is in scope after the cv-quals. */
inject_this_parameter (current_class_type, cv_quals);
diff --git a/gcc/testsuite/g++.dg/cpp0x/this2.C b/gcc/testsuite/g++.dg/cpp0x/this2.C
new file mode 100644
index 000..3781bc5efec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/this2.C
@@ -0,0 +1,8 @@
+// PR c++/88548
+// { dg-do compile { target c++11 } }
+
+struct S {
+ int a;
+ template static auto m1 ()
+-> decltype(this->a) { return 0; }; // { dg-error "'this'" }
+};
diff --git a/gcc/testsuite/g++.dg/template/pr97399a.C
b/gcc/testsuite/g++.dg/template/pr97399a.C
new file mode 100644
index 000..3713dbde6e0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr97399a.C
@@ -0,0 +1,11 @@
+// PR c++/97399
+// { dg-do compile { target c++11 } }
+
+template struct enable_if_t {};
+struct tmp {
+ template static constexpr bool is_integral();
+ template static auto func()
+-> enable_if_t()>;
+};
+template constexpr bool tmp::is_integral() { return true; }
+int main() { tmp::func(); }
diff --git
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Thu, 21 Jan 2021, Marek Polacek wrote: > On Thu, Jan 21, 2021 at 11:22:24AM -0500, Patrick Palka via Gcc-patches wrote: > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to > > the expression tmp::integral (because it's type-dependent, and also > > current_class_ptr is set) within the trailing return type, and later > > during substitution we can't resolve the 'this' since > > tsubst_function_type does inject_this_parm only for non-static member > > functions which tmp::func is not. > > > > It seems the root of the problem is that we set current_class_ptr when > > parsing the signature of a static member function. Since explicit uses > > of 'this' are already not allowed in this context, we probably shouldn't > > be doing inject_this_parm either. > > > > Bootstrapped and regtested on x64_64-pc-linux-gnu, does this look OK for > > trunk? > > This looks fine to me. Thanks. It occurred to me that we should similarly avoid doing inject_this_parm for friend functions, too. Here's a patch to that end, and which also addresses a minor diagnostic regression in a gomp testcase that I didn't notice earlier: -- >8 -- Subject: [PATCH] c++: Suppress 'this' injection for static member functions [PR97399] In the testcase pr97399a.C below, finish_qualified_id_expr at parse time adds an implicit 'this->' to the expression tmp::integral (because it's type-dependent, and also current_class_ptr is set at this point) within the trailing return type. Later when substituting into the trailing return type we ICE due to the unresolved 'this', since tsubst_function_type does inject_this_parm only for non-static member functions, which tmp::func is not. It seems the root of the problem is that we set current_class_ptr when parsing the signature of a static member function. Since explicit uses of 'this' are already forbidden in this context, we probably shouldn't be doing inject_this_parm either. Likewise for friend functions, with which we can exhibit the same ICE. Testing revealed a diagnostic regression in the gomp testcase this-1.C due to current_class_ptr now being unset when parsing a use of 'this' within the pragma for a static member function. The below changes to cp_parser_omp_var_list_no_open and finish_this_expr try to salvage the quality of the affected error message (or else the error messages in question would degenerate to "expected qualified-id before 'this'"). The change to cp_parser_init_declarator below is needed so that we properly communicate static-ness to cp_parser_direct_declarator when parsing a member function template. Bootstrap and regtest re-running on x86_64-pc-linux-gnu, does this look OK for trunk if successful? gcc/cp/ChangeLog: PR c++/97399 * parser.c (cp_parser_init_declarator): If the storage class specifier is sc_static, pass true for static_p to cp_parser_declarator. (cp_parser_direct_declarator): Don't do inject_this_parm when the function is specified as static or friend. (cp_parser_omp_var_list_no_open): Call finish_this_expr even when current_class_ptr is not set for better diagnostics. * semantics.c (finish_this_expr): Emit a more specific diagnostic when at class scope. gcc/testsuite/ChangeLog: PR c++/88548 PR c++/97399 * g++.dg/cpp0x/this2.C: New test. * g++.dg/gomp/this-1.C: Adjust expected error for use of 'this' in signature of static member function. * g++.dg/template/pr97399a.C: New test. * g++.dg/template/pr97399b.C: New test. --- gcc/cp/parser.c | 6 +++--- gcc/cp/semantics.c | 2 ++ gcc/testsuite/g++.dg/cpp0x/this2.C | 9 + gcc/testsuite/g++.dg/gomp/this-1.C | 4 ++-- gcc/testsuite/g++.dg/template/pr97399a.C | 20 gcc/testsuite/g++.dg/template/pr97399b.C | 20 6 files changed, 56 insertions(+), 5 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/this2.C create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 48437f23175..6d6bd1e60fd 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -21413,6 +21413,7 @@ cp_parser_init_declarator (cp_parser* parser, bool is_non_constant_init; int ctor_dtor_or_conv_p; bool friend_p = cp_parser_friend_p (decl_specifiers); + bool static_p = decl_specifiers->storage_class == sc_static; tree pushed_scope = NULL_TREE; bool range_for_decl_p = false; bool saved_default_arg_ok_p = parser->default_arg_ok_p; @@ -21446,7 +21447,7 @@ cp_parser_init_declarator (cp_parser* parser, = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED, flags, _dtor_or_conv_p, /*parenthesized_p=*/NULL, - member_p, friend_p, /*static_p=*/false); +
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Thu, Jan 21, 2021 at 11:22:24AM -0500, Patrick Palka via Gcc-patches wrote:
> Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> the expression tmp::integral (because it's type-dependent, and also
> current_class_ptr is set) within the trailing return type, and later
> during substitution we can't resolve the 'this' since
> tsubst_function_type does inject_this_parm only for non-static member
> functions which tmp::func is not.
>
> It seems the root of the problem is that we set current_class_ptr when
> parsing the signature of a static member function. Since explicit uses
> of 'this' are already not allowed in this context, we probably shouldn't
> be doing inject_this_parm either.
>
> Bootstrapped and regtested on x64_64-pc-linux-gnu, does this look OK for
> trunk?
This looks fine to me.
> gcc/cp/ChangeLog:
>
> PR c++/97399
> * parser.c (cp_parser_init_declarator): If the storage class
> specifier is sc_static, pass true for static_p to
> cp_parser_declarator.
> (cp_parser_direct_declarator): Don't do inject_this_parm when
> the member function is static.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/88548
> PR c++/97399
> * g++.dg/cpp0x/this2.C: New test.
> * g++.dg/template/pr97399a.C: New test.
> * g++.dg/template/pr97399b.C: New test.
> ---
> gcc/cp/parser.c | 5 +++--
> gcc/testsuite/g++.dg/cpp0x/this2.C | 8
> gcc/testsuite/g++.dg/template/pr97399a.C | 11 +++
> gcc/testsuite/g++.dg/template/pr97399b.C | 11 +++
> 4 files changed, 33 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/this2.C
> create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C
> create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 48437f23175..18cf9888632 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -21413,6 +21413,7 @@ cp_parser_init_declarator (cp_parser* parser,
>bool is_non_constant_init;
>int ctor_dtor_or_conv_p;
>bool friend_p = cp_parser_friend_p (decl_specifiers);
> + bool static_p = decl_specifiers->storage_class == sc_static;
>tree pushed_scope = NULL_TREE;
>bool range_for_decl_p = false;
>bool saved_default_arg_ok_p = parser->default_arg_ok_p;
> @@ -21446,7 +21447,7 @@ cp_parser_init_declarator (cp_parser* parser,
> = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
> flags, _dtor_or_conv_p,
> /*parenthesized_p=*/NULL,
> - member_p, friend_p, /*static_p=*/false);
> + member_p, friend_p, static_p);
>/* Gather up the deferred checks. */
>stop_deferring_access_checks ();
>
> @@ -22122,7 +22123,7 @@ cp_parser_direct_declarator (cp_parser* parser,
>
> tree save_ccp = current_class_ptr;
> tree save_ccr = current_class_ref;
> - if (memfn)
> + if (memfn && !static_p)
> /* DR 1207: 'this' is in scope after the cv-quals. */
> inject_this_parameter (current_class_type, cv_quals);
>
> diff --git a/gcc/testsuite/g++.dg/cpp0x/this2.C
> b/gcc/testsuite/g++.dg/cpp0x/this2.C
> new file mode 100644
> index 000..3781bc5efec
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/this2.C
> @@ -0,0 +1,8 @@
> +// PR c++/88548
> +// { dg-do compile { target c++11 } }
> +
> +struct S {
> + int a;
> + template static auto m1 ()
> +-> decltype(this->a) { return 0; }; // { dg-error "'this'" }
> +};
> diff --git a/gcc/testsuite/g++.dg/template/pr97399a.C
> b/gcc/testsuite/g++.dg/template/pr97399a.C
> new file mode 100644
> index 000..3713dbde6e0
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/pr97399a.C
> @@ -0,0 +1,11 @@
> +// PR c++/97399
> +// { dg-do compile { target c++11 } }
> +
> +template struct enable_if_t {};
> +struct tmp {
> + template static constexpr bool is_integral();
> + template static auto func()
> +-> enable_if_t()>;
> +};
> +template constexpr bool tmp::is_integral() { return true; }
> +int main() { tmp::func(); }
> diff --git a/gcc/testsuite/g++.dg/template/pr97399b.C
> b/gcc/testsuite/g++.dg/template/pr97399b.C
> new file mode 100644
> index 000..9196c985834
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/pr97399b.C
> @@ -0,0 +1,11 @@
> +// PR c++/97399
> +// { dg-do compile { target c++11 } }
> +
> +template struct enable_if_t {};
> +struct tmp {
> + template constexpr bool is_integral(); // non-static
> + template static auto func()
> +-> enable_if_t()>; // { dg-error "without object" }
> +};
> +template constexpr bool tmp::is_integral() { return true; }
> +int main() { tmp::func(); } // { dg-error "no match" }
> --
> 2.30.0.155.g66e871b664
>
Marek
Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]
On Thu, 21 Jan 2021, Patrick Palka wrote:
> Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> the expression tmp::integral (because it's type-dependent, and also
> current_class_ptr is set) within the trailing return type, and later
> during substitution we can't resolve the 'this' since
> tsubst_function_type does inject_this_parm only for non-static member
> functions which tmp::func is not.
>
> It seems the root of the problem is that we set current_class_ptr when
> parsing the signature of a static member function. Since explicit uses
> of 'this' are already not allowed in this context, we probably shouldn't
> be doing inject_this_parm either.
>
> Bootstrapped and regtested on x64_64-pc-linux-gnu, does this look OK for
> trunk?
>
> gcc/cp/ChangeLog:
>
> PR c++/97399
> * parser.c (cp_parser_init_declarator): If the storage class
> specifier is sc_static, pass true for static_p to
> cp_parser_declarator.
> (cp_parser_direct_declarator): Don't do inject_this_parm when
> the member function is static.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/88548
> PR c++/97399
> * g++.dg/cpp0x/this2.C: New test.
> * g++.dg/template/pr97399a.C: New test.
> * g++.dg/template/pr97399b.C: New test.
> ---
> gcc/cp/parser.c | 5 +++--
> gcc/testsuite/g++.dg/cpp0x/this2.C | 8
> gcc/testsuite/g++.dg/template/pr97399a.C | 11 +++
> gcc/testsuite/g++.dg/template/pr97399b.C | 11 +++
> 4 files changed, 33 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/this2.C
> create mode 100644 gcc/testsuite/g++.dg/template/pr97399a.C
> create mode 100644 gcc/testsuite/g++.dg/template/pr97399b.C
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 48437f23175..18cf9888632 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -21413,6 +21413,7 @@ cp_parser_init_declarator (cp_parser* parser,
>bool is_non_constant_init;
>int ctor_dtor_or_conv_p;
>bool friend_p = cp_parser_friend_p (decl_specifiers);
> + bool static_p = decl_specifiers->storage_class == sc_static;
>tree pushed_scope = NULL_TREE;
>bool range_for_decl_p = false;
>bool saved_default_arg_ok_p = parser->default_arg_ok_p;
> @@ -21446,7 +21447,7 @@ cp_parser_init_declarator (cp_parser* parser,
> = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
> flags, _dtor_or_conv_p,
> /*parenthesized_p=*/NULL,
> - member_p, friend_p, /*static_p=*/false);
> + member_p, friend_p, static_p);
>/* Gather up the deferred checks. */
>stop_deferring_access_checks ();
I should note that the above parser change is needed so that we properly
communicate static-ness to cp_parser_direct_declarator when parsing a
member function template.
>
> @@ -22122,7 +22123,7 @@ cp_parser_direct_declarator (cp_parser* parser,
>
> tree save_ccp = current_class_ptr;
> tree save_ccr = current_class_ref;
> - if (memfn)
> + if (memfn && !static_p)
> /* DR 1207: 'this' is in scope after the cv-quals. */
> inject_this_parameter (current_class_type, cv_quals);
>
> diff --git a/gcc/testsuite/g++.dg/cpp0x/this2.C
> b/gcc/testsuite/g++.dg/cpp0x/this2.C
> new file mode 100644
> index 000..3781bc5efec
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/this2.C
> @@ -0,0 +1,8 @@
> +// PR c++/88548
> +// { dg-do compile { target c++11 } }
> +
> +struct S {
> + int a;
> + template static auto m1 ()
> +-> decltype(this->a) { return 0; }; // { dg-error "'this'" }
> +};
> diff --git a/gcc/testsuite/g++.dg/template/pr97399a.C
> b/gcc/testsuite/g++.dg/template/pr97399a.C
> new file mode 100644
> index 000..3713dbde6e0
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/pr97399a.C
> @@ -0,0 +1,11 @@
> +// PR c++/97399
> +// { dg-do compile { target c++11 } }
> +
> +template struct enable_if_t {};
> +struct tmp {
> + template static constexpr bool is_integral();
> + template static auto func()
> +-> enable_if_t()>;
> +};
> +template constexpr bool tmp::is_integral() { return true; }
> +int main() { tmp::func(); }
> diff --git a/gcc/testsuite/g++.dg/template/pr97399b.C
> b/gcc/testsuite/g++.dg/template/pr97399b.C
> new file mode 100644
> index 000..9196c985834
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/pr97399b.C
> @@ -0,0 +1,11 @@
> +// PR c++/97399
> +// { dg-do compile { target c++11 } }
> +
> +template struct enable_if_t {};
> +struct tmp {
> + template constexpr bool is_integral(); // non-static
> + template static auto func()
> +-> enable_if_t()>; // { dg-error "without object" }
> +};
> +template constexpr bool tmp::is_integral() { return true; }
> +int main() { tmp::func(); } // { dg-error "no match" }
> --
>
