public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] c++: partial spec constraint checking context [PR105220]
@ 2022-05-02 18:50 Patrick Palka
  2022-05-03 20:07 ` Jason Merrill
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Palka @ 2022-05-02 18:50 UTC (permalink / raw)
  To: gcc-patches

Currently when checking the constraints of a class template, we do so in
the context of the template, not the specialized type.  This is the best
we can do for a primary template since the specialized type is valid
only if the primary template's constraints are satisfied.  But for a
partial specialization, we can assume the specialized type is valid (as
a consequence of constraints being checked only when necessary), so we
arguably should check the constraints on a partial specialization more
specifically in the context of the specialized type, not the template.

This patch implements this by substituting and setting the access
context appropriately in satisfy_declaration_constraints.  Note that
setting the access context in this case is somewhat redundant since the
relevant caller most_specialized_partial_spec will already have set the
access context to the specialiation, but this redundancy should be harmless.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 12.2 (after the branch is thawed)?

	PR c++/105220

gcc/cp/ChangeLog:

	* constraint.cc (satisfy_declaration_constraints): When checking
	the constraints of a partial template specialization, do so in
	the context of the specialized type not the template.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
---
 gcc/cp/constraint.cc                          | 17 ++++++++++++++---
 .../g++.dg/cpp2a/concepts-partial-spec12.C    | 19 +++++++++++++++++++
 2 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 94f6222b436..772f8532b47 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3253,11 +3253,22 @@ satisfy_declaration_constraints (tree t, tree args, sat_info info)
     {
       if (!push_tinst_level (t, args))
 	return result;
-      tree pattern = DECL_TEMPLATE_RESULT (t);
+      tree ascope = DECL_TEMPLATE_RESULT (t);
+      if (CLASS_TYPE_P (TREE_TYPE (t))
+	  && CLASSTYPE_TEMPLATE_SPECIALIZATION (TREE_TYPE (t)))
+	{
+	  gcc_checking_assert (t == most_general_template (t));
+	  /* When checking the constraints on a partial specialization,
+	     do so in the context of the specialized type, not the template.
+	     This substitution should always succeed since we shouldn't
+	     be checking constraints thereof unless the specialized type
+	     is valid.  */
+	  ascope = tsubst (ascope, args, tf_none, info.in_decl);
+	}
       push_to_top_level ();
-      push_access_scope (pattern);
+      push_access_scope (ascope);
       result = satisfy_normalized_constraints (norm, args, info);
-      pop_access_scope (pattern);
+      pop_access_scope (ascope);
       pop_from_top_level ();
       pop_tinst_level ();
     }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
new file mode 100644
index 00000000000..641d456722d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
@@ -0,0 +1,19 @@
+// PR c++/105220
+// { dg-do compile { target c++20 } }
+
+template<class T>
+concept fooable = requires(T t) { t.foo(); };
+
+template<class>
+struct A;        // #1, incomplete
+
+template<fooable T>
+struct A<T> { }; // #2
+
+struct B {
+private:
+  friend struct A<B>;
+  void foo();
+};
+
+template struct A<B>; // OK, B::foo() is accessible from #2
-- 
2.36.0.44.g0f828332d5


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] c++: partial spec constraint checking context [PR105220]
  2022-05-02 18:50 [PATCH] c++: partial spec constraint checking context [PR105220] Patrick Palka
@ 2022-05-03 20:07 ` Jason Merrill
  2023-11-03 15:02   ` Patrick Palka
  0 siblings, 1 reply; 4+ messages in thread
From: Jason Merrill @ 2022-05-03 20:07 UTC (permalink / raw)
  To: Patrick Palka, gcc-patches

On 5/2/22 14:50, Patrick Palka wrote:
> Currently when checking the constraints of a class template, we do so in
> the context of the template, not the specialized type.  This is the best
> we can do for a primary template since the specialized type is valid
> only if the primary template's constraints are satisfied.

Hmm, that's unfortunate.  It ought to be possible, if awkward, to form 
the type long enough to check its constraints.

> But for a
> partial specialization, we can assume the specialized type is valid (as
> a consequence of constraints being checked only when necessary), so we
> arguably should check the constraints on a partial specialization more
> specifically in the context of the specialized type, not the template.
> 
> This patch implements this by substituting and setting the access
> context appropriately in satisfy_declaration_constraints.  Note that
> setting the access context in this case is somewhat redundant since the
> relevant caller most_specialized_partial_spec will already have set the
> access context to the specialiation, but this redundancy should be harmless.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk and perhaps 12.2 (after the branch is thawed)?
> 
> 	PR c++/105220
> 
> gcc/cp/ChangeLog:
> 
> 	* constraint.cc (satisfy_declaration_constraints): When checking
> 	the constraints of a partial template specialization, do so in
> 	the context of the specialized type not the template.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
> ---
>   gcc/cp/constraint.cc                          | 17 ++++++++++++++---
>   .../g++.dg/cpp2a/concepts-partial-spec12.C    | 19 +++++++++++++++++++
>   2 files changed, 33 insertions(+), 3 deletions(-)
>   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> 
> diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> index 94f6222b436..772f8532b47 100644
> --- a/gcc/cp/constraint.cc
> +++ b/gcc/cp/constraint.cc
> @@ -3253,11 +3253,22 @@ satisfy_declaration_constraints (tree t, tree args, sat_info info)
>       {
>         if (!push_tinst_level (t, args))
>   	return result;
> -      tree pattern = DECL_TEMPLATE_RESULT (t);
> +      tree ascope = DECL_TEMPLATE_RESULT (t);
> +      if (CLASS_TYPE_P (TREE_TYPE (t))
> +	  && CLASSTYPE_TEMPLATE_SPECIALIZATION (TREE_TYPE (t)))
> +	{
> +	  gcc_checking_assert (t == most_general_template (t));
> +	  /* When checking the constraints on a partial specialization,
> +	     do so in the context of the specialized type, not the template.
> +	     This substitution should always succeed since we shouldn't
> +	     be checking constraints thereof unless the specialized type
> +	     is valid.  */
> +	  ascope = tsubst (ascope, args, tf_none, info.in_decl);
> +	}
>         push_to_top_level ();
> -      push_access_scope (pattern);
> +      push_access_scope (ascope);
>         result = satisfy_normalized_constraints (norm, args, info);
> -      pop_access_scope (pattern);
> +      pop_access_scope (ascope);
>         pop_from_top_level ();
>         pop_tinst_level ();
>       }
> diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> new file mode 100644
> index 00000000000..641d456722d
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> @@ -0,0 +1,19 @@
> +// PR c++/105220
> +// { dg-do compile { target c++20 } }
> +
> +template<class T>
> +concept fooable = requires(T t) { t.foo(); };
> +
> +template<class>
> +struct A;        // #1, incomplete
> +
> +template<fooable T>
> +struct A<T> { }; // #2
> +
> +struct B {
> +private:
> +  friend struct A<B>;
> +  void foo();
> +};
> +
> +template struct A<B>; // OK, B::foo() is accessible from #2


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] c++: partial spec constraint checking context [PR105220]
  2022-05-03 20:07 ` Jason Merrill
@ 2023-11-03 15:02   ` Patrick Palka
  2023-11-30 15:42     ` Patrick Palka
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Palka @ 2023-11-03 15:02 UTC (permalink / raw)
  To: Jason Merrill; +Cc: Patrick Palka, gcc-patches

On Tue, 3 May 2022, Jason Merrill wrote:

> On 5/2/22 14:50, Patrick Palka wrote:
> > Currently when checking the constraints of a class template, we do so in
> > the context of the template, not the specialized type.  This is the best
> > we can do for a primary template since the specialized type is valid
> > only if the primary template's constraints are satisfied.
> 
> Hmm, that's unfortunate.  It ought to be possible, if awkward, to form the
> type long enough to check its constraints.

(Sorry, lost track of this patch...)

Seems doable, but I'm not sure if would make any difference in practice?

If the access context during satisfaction of a primary class template's
constraints is the specialization rather than the primary template,
then that should only make a difference if there's some friend declaration
naming the specialization.  But that'd mean the specialization's
constraints had to have been satisfied at that point, before the friend
declaration went into effect.  So either the constraints don't depend on
the access granted by the friend declaration anyway, or they do and the
program is ill-formed (due to either satifaction failure or instability) IIUC.

For example, I don't think an adapted version of the testcase without a
partial specialization is valid, regardless of whether the access context
during satisfaction of A<B> is A<B> or just A:

    template<class T>
    concept fooable = requires(T t) { t.foo(); };

    template<fooable T>
    struct A { };

    struct B {
    private:
      friend struct A<B>; // satisfaction failure at this point
      void foo();
    };

    template struct A<B>;


> 
> > But for a
> > partial specialization, we can assume the specialized type is valid (as
> > a consequence of constraints being checked only when necessary), so we
> > arguably should check the constraints on a partial specialization more
> > specifically in the context of the specialized type, not the template.
> > 
> > This patch implements this by substituting and setting the access
> > context appropriately in satisfy_declaration_constraints.  Note that
> > setting the access context in this case is somewhat redundant since the
> > relevant caller most_specialized_partial_spec will already have set the
> > access context to the specialiation, but this redundancy should be harmless.
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk and perhaps 12.2 (after the branch is thawed)?
> > 
> > 	PR c++/105220
> > 
> > gcc/cp/ChangeLog:
> > 
> > 	* constraint.cc (satisfy_declaration_constraints): When checking
> > 	the constraints of a partial template specialization, do so in
> > 	the context of the specialized type not the template.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 	* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
> > ---
> >   gcc/cp/constraint.cc                          | 17 ++++++++++++++---
> >   .../g++.dg/cpp2a/concepts-partial-spec12.C    | 19 +++++++++++++++++++
> >   2 files changed, 33 insertions(+), 3 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > 
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index 94f6222b436..772f8532b47 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -3253,11 +3253,22 @@ satisfy_declaration_constraints (tree t, tree args,
> > sat_info info)
> >       {
> >         if (!push_tinst_level (t, args))
> >   	return result;
> > -      tree pattern = DECL_TEMPLATE_RESULT (t);
> > +      tree ascope = DECL_TEMPLATE_RESULT (t);
> > +      if (CLASS_TYPE_P (TREE_TYPE (t))
> > +	  && CLASSTYPE_TEMPLATE_SPECIALIZATION (TREE_TYPE (t)))
> > +	{
> > +	  gcc_checking_assert (t == most_general_template (t));
> > +	  /* When checking the constraints on a partial specialization,
> > +	     do so in the context of the specialized type, not the template.
> > +	     This substitution should always succeed since we shouldn't
> > +	     be checking constraints thereof unless the specialized type
> > +	     is valid.  */
> > +	  ascope = tsubst (ascope, args, tf_none, info.in_decl);
> > +	}
> >         push_to_top_level ();
> > -      push_access_scope (pattern);
> > +      push_access_scope (ascope);
> >         result = satisfy_normalized_constraints (norm, args, info);
> > -      pop_access_scope (pattern);
> > +      pop_access_scope (ascope);
> >         pop_from_top_level ();
> >         pop_tinst_level ();
> >       }
> > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > new file mode 100644
> > index 00000000000..641d456722d
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > @@ -0,0 +1,19 @@
> > +// PR c++/105220
> > +// { dg-do compile { target c++20 } }
> > +
> > +template<class T>
> > +concept fooable = requires(T t) { t.foo(); };
> > +
> > +template<class>
> > +struct A;        // #1, incomplete
> > +
> > +template<fooable T>
> > +struct A<T> { }; // #2
> > +
> > +struct B {
> > +private:
> > +  friend struct A<B>;
> > +  void foo();
> > +};
> > +
> > +template struct A<B>; // OK, B::foo() is accessible from #2
> 
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] c++: partial spec constraint checking context [PR105220]
  2023-11-03 15:02   ` Patrick Palka
@ 2023-11-30 15:42     ` Patrick Palka
  0 siblings, 0 replies; 4+ messages in thread
From: Patrick Palka @ 2023-11-30 15:42 UTC (permalink / raw)
  To: Patrick Palka; +Cc: Jason Merrill, gcc-patches

On Fri, 3 Nov 2023, Patrick Palka wrote:

> On Tue, 3 May 2022, Jason Merrill wrote:
> 
> > On 5/2/22 14:50, Patrick Palka wrote:
> > > Currently when checking the constraints of a class template, we do so in
> > > the context of the template, not the specialized type.  This is the best
> > > we can do for a primary template since the specialized type is valid
> > > only if the primary template's constraints are satisfied.
> > 
> > Hmm, that's unfortunate.  It ought to be possible, if awkward, to form the
> > type long enough to check its constraints.
> 
> (Sorry, lost track of this patch...)
> 
> Seems doable, but I'm not sure if would make any difference in practice?
> 
> If the access context during satisfaction of a primary class template's
> constraints is the specialization rather than the primary template,
> then that should only make a difference if there's some friend declaration
> naming the specialization.  But that'd mean the specialization's
> constraints had to have been satisfied at that point, before the friend
> declaration went into effect.  So either the constraints don't depend on
> the access granted by the friend declaration anyway, or they do and the
> program is ill-formed (due to either satifaction failure or instability) IIUC.
> 
> For example, I don't think an adapted version of the testcase without a
> partial specialization is valid, regardless of whether the access context
> during satisfaction of A<B> is A<B> or just A:
> 
>     template<class T>
>     concept fooable = requires(T t) { t.foo(); };
> 
>     template<fooable T>
>     struct A { };
> 
>     struct B {
>     private:
>       friend struct A<B>; // satisfaction failure at this point
>       void foo();
>     };
> 
>     template struct A<B>;

... so in light of the above, I wonder if the original patch can go in
as-is?

> 
> 
> > 
> > > But for a
> > > partial specialization, we can assume the specialized type is valid (as
> > > a consequence of constraints being checked only when necessary), so we
> > > arguably should check the constraints on a partial specialization more
> > > specifically in the context of the specialized type, not the template.
> > > 
> > > This patch implements this by substituting and setting the access
> > > context appropriately in satisfy_declaration_constraints.  Note that
> > > setting the access context in this case is somewhat redundant since the
> > > relevant caller most_specialized_partial_spec will already have set the
> > > access context to the specialiation, but this redundancy should be harmless.
> > > 
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk and perhaps 12.2 (after the branch is thawed)?
> > > 
> > > 	PR c++/105220
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > > 	* constraint.cc (satisfy_declaration_constraints): When checking
> > > 	the constraints of a partial template specialization, do so in
> > > 	the context of the specialized type not the template.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > > 	* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
> > > ---
> > >   gcc/cp/constraint.cc                          | 17 ++++++++++++++---
> > >   .../g++.dg/cpp2a/concepts-partial-spec12.C    | 19 +++++++++++++++++++
> > >   2 files changed, 33 insertions(+), 3 deletions(-)
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > > 
> > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > > index 94f6222b436..772f8532b47 100644
> > > --- a/gcc/cp/constraint.cc
> > > +++ b/gcc/cp/constraint.cc
> > > @@ -3253,11 +3253,22 @@ satisfy_declaration_constraints (tree t, tree args,
> > > sat_info info)
> > >       {
> > >         if (!push_tinst_level (t, args))
> > >   	return result;
> > > -      tree pattern = DECL_TEMPLATE_RESULT (t);
> > > +      tree ascope = DECL_TEMPLATE_RESULT (t);
> > > +      if (CLASS_TYPE_P (TREE_TYPE (t))
> > > +	  && CLASSTYPE_TEMPLATE_SPECIALIZATION (TREE_TYPE (t)))
> > > +	{
> > > +	  gcc_checking_assert (t == most_general_template (t));
> > > +	  /* When checking the constraints on a partial specialization,
> > > +	     do so in the context of the specialized type, not the template.
> > > +	     This substitution should always succeed since we shouldn't
> > > +	     be checking constraints thereof unless the specialized type
> > > +	     is valid.  */
> > > +	  ascope = tsubst (ascope, args, tf_none, info.in_decl);
> > > +	}
> > >         push_to_top_level ();
> > > -      push_access_scope (pattern);
> > > +      push_access_scope (ascope);
> > >         result = satisfy_normalized_constraints (norm, args, info);
> > > -      pop_access_scope (pattern);
> > > +      pop_access_scope (ascope);
> > >         pop_from_top_level ();
> > >         pop_tinst_level ();
> > >       }
> > > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > > b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > > new file mode 100644
> > > index 00000000000..641d456722d
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C
> > > @@ -0,0 +1,19 @@
> > > +// PR c++/105220
> > > +// { dg-do compile { target c++20 } }
> > > +
> > > +template<class T>
> > > +concept fooable = requires(T t) { t.foo(); };
> > > +
> > > +template<class>
> > > +struct A;        // #1, incomplete
> > > +
> > > +template<fooable T>
> > > +struct A<T> { }; // #2
> > > +
> > > +struct B {
> > > +private:
> > > +  friend struct A<B>;
> > > +  void foo();
> > > +};
> > > +
> > > +template struct A<B>; // OK, B::foo() is accessible from #2
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-11-30 15:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-02 18:50 [PATCH] c++: partial spec constraint checking context [PR105220] Patrick Palka
2022-05-03 20:07 ` Jason Merrill
2023-11-03 15:02   ` Patrick Palka
2023-11-30 15:42     ` Patrick Palka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).