On 6/14/24 12:56 PM, Marek Polacek wrote:
On Mon, Jun 10, 2024 at 10:23:37PM -0400, Jason Merrill wrote:
On 6/10/24 11:13, Marek Polacek wrote:
On Mon, Jun 10, 2024 at 10:22:11AM -0400, Patrick Palka wrote:
On Fri, 7 Jun 2024, Marek Polacek wrote:
@@ -3940,9 +3936,6 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees, 
void* data)
         parameter pack (14.6.3), or the type-specifier-seq of a type-id that
         is a pack expansion, the invented template parameter is a template
         parameter pack.  */

This comment should be removed too I think.

Removed in my local tree.
-      if (flag_concepts_ts && ppd->type_pack_expansion_p && is_auto (t)

(BTW this seems to be the only actual user of type_pack_expansion_p so we
can in turn remove that field too.)

Oh neat.  I can do that as a follow-up, unless y'all think it should be
part of this patch.  Thanks,

It probably makes sense for it to be part of this patch.

OK, done.

One exception I'm aware of is template-introductions, as in:

   template<typename T>
   concept C = true;

   C{T} void foo ();

where we warn by default, but accept the code, and my patch does not
remove the support just yet.

I think let's go ahead and remove it as well.

Done as well.  I was able to remove quite a lot of functions.

+// ??? This used to be a link test with Concepts TS, but now we
+// get:
+// undefined reference to `_Z2f5ITk1C1XEvT_Q1DIS1_E'
+// undefined reference to `_Z2f6ITk1C1XEvT_Q1DIS1_E'
+// so it's a compile test only.

That means the test is failing, and we shouldn't in general change tests to
stop testing the thing that fails; better to xfail.

In this case, however, C++20 doesn't establish the equivalence that it's
testing; that's another thing that wasn't adopted from the Concepts TS.

Note that this area is in question currently; see CWG2802.  But I think the
equivalence is unlikely to return.

So let's move main() to the bottom of the test and test for the ambiguity
errors that we get because they aren't equivalent.

Thanks, done.

--- a/gcc/testsuite/g++.dg/concepts/pr67595.C
+++ /dev/null
@@ -1,14 +0,0 @@
-// { dg-do compile { target c++17_only } }
-// { dg-options "-fconcepts-ts" }
-
-template <class X> concept bool allocatable = requires{{new X}->X *; };
-template <class X> concept bool semiregular = allocatable<X>;
-template <class X> concept bool readable = requires{requires semiregular<X>;};
-template <class> int weak_input_iterator = requires{{0}->readable;};
-template <class X> bool input_iterator{weak_input_iterator<X>}; // { dg-prune-output 
"narrowing conversion" }
-template <class X> bool forward_iterator{input_iterator<X>};
-template <class X> bool bidirectional_iterator{forward_iterator<X>};
-template <class X>
-concept bool random_access_iterator{bidirectional_iterator<X>}; // { dg-error 
"constant" }
-void fn1(random_access_iterator);
-int main() { fn1(0); }  // { dg-error "" }

Why remove this test?  The main issue I see is that {new X}->X* needs to
change to {new X}->convertible_to<X*> (or same_as)

Adjusted as suggested.

+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires5.C
@@ -1,7 +1,5 @@
  // { dg-do compile { target c++20 } }
-// { dg-additional-options "-fconcepts-ts -fconcepts-diagnostics-depth=2" }
-
-// Test conversion requirements (not in C++20)

This one could get the same adjustment instead of adding dg-errors.  Or
perhaps the error could suggest that adjustment, and this testcase could
check that?

Adjusted as well.  I don't think I understand what's going on here very
well.  There was:

   concept C = requires(T x) { { x.fn() } -> S1<T>; };

and with my patch:

   concept C = requires(T x) { { x.fn() } -> same_as<S1<T>>; };

so we're checking that the result of x.fn() is the same type as S1<T>.
Why doesn't plain "S1<T>" work?

See the discussion of this change in wg21.link/p1452 .

Anyway, here's v2:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-Some constructs that were allowed by the earlier C++ Extensions for
-Concepts Technical Specification, ISO 19217 (2015), but didn't make it
-into the standard, can additionally be enabled by
-@option{-fconcepts-ts}.  The option @option{-fconcepts-ts} was deprecated
-in GCC 14 and may be removed in GCC 15; users are expected to convert
-their code to C++20 concepts.

I'd probably keep the documentation for now, modified to say that it was removed in GCC 15.

 // Check equivalence of short- and longhand declarations.

Please add a comment that they are not equivalent in C++20.

+++ b/gcc/testsuite/g++.dg/concepts/fn-concept3.C
+static_assert(noexcept(C3<int>), "function concept should be treated as if 
noexcept(true) specified");

Let's update the message as well.

OK with those adjustments, thanks.

Jason

Reply via email to