[Bug c++/92593] [10 Regression] ICE with CTAD using undeclared constraint

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
It looks like the deduction isn't failing appropriately. The compiler things
the declaration of r has type "ref_view<>", which is
apparently causing infinite recursion in a call to reshape_init_class.

[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236

--- Comment #6 from Andrew Sutton  ---
I'm going to send a patch for this, hopefully this morning, that ties concept
diagnostics into static asserts. It wasn't as bad as I thought it was going to
be.

I didn't implement this:

  static_assert (!Int);

because I'm not sure what would be good to print. It may be possible to
completely invert all the diagnostics (e.g., failed because f(x) is valid), but
that would likely take some heroic effort.

[Bug c++/89442] [concepts] missing "wrong number of template arguments" error in requires-clause

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89442

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
The error is a little better in trunk, but I think this should be caught when
it's parsed: you can't ever use foo with one argument.

Looking into this, we aren't converting template arguments for dependent
variable templates in finish_id_expr, but we probably should.

I don't think this is strictly concepts-related.

[Bug c++/89913] [8/9/10 Regression] [concepts] ICE with invalid using declaration

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89913

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
This isn't strictly related to concepts.

Resolution posted here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01429.html

The tests target C++20, but this could be extended back to C++11. However, the
diagnostic is different for pre-C++20.

[Bug c++/90287] [concepts] bogus error on overload failure inside requires-expression

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90287

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
This is a duplicate of 92186.

A resolution is available here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

[Bug c++/90734] [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
I think this error is correct (i.e., there is no defect in trunk):

   48 | static_assert(S2::f());// Bogus non-error

The requirements of this declaration:

static constexpr bool f() requires bool_ && true { return true; }

are incomparable with those of the overloads requiring Foo and Bar. The atomic
constraints bool_ and true are not identical to those pulled in by the
normalization of Same_impl.

[Bug c++/92078] error: 'struct std::ptr' redeclared with different access

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92078

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
Patch here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01293.html

[Bug c++/92040] Type requirements don't appear to work when a type doesn't exist.

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92040

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Duplicate of 92186.

A resolution is available here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

[Bug c++/92186] [concepts] requires expression outside of concept definition cannot return false

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92186

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Resolved by the patch here.

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

[Bug c++/92103] constraints not checked on nested class template

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92103

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
This is one of our x-fail tests. When you instantiate a constrained alias with
dependent arguments, you have to propagate its constraints (somehow) into the
resulting type. And of course, those can accumulate through multiple
instantiations of aliases. Unfortunately, I'm not that familiar with how
aliases work.

[Bug c++/92403] [concepts] requires expression in if constexpr

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403

--- Comment #2 from Andrew Sutton  ---
This seems like a duplicate of 92186.

[Bug c++/92214] Unhelpful diagnostic for static_assert( some_concept(some_type) )

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92214

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
That's part of a functional type conversion: the T in T(args...), not a
declaration.

If we don't allow placeholders in that context, we can probably generate a
better diagnostic.

[Bug c++/92403] [concepts] requires expression in if constexpr

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
A resolution is available here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

[Bug c++/92439] [concepts] trunk crashes on constraint satisfaction failure

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Confirmed. The patch here fixes the crash, but there are other issues that
prevent this from compiling.

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html

In particular, the nested value of:

  template  struct has_form_of_list { enum : bool { value = false
}; };

cannot be used as an atomic constraint as it doesn't have type bool. That needs
to be a static constexpr bool variable.

Fixing that, you get this:

x.cpp:37:28: error: use of function ‘constexpr bool
detail::dont_overlap(unsigned int, const T&, const Ts& ...) [with T =
list, bf<0, 3> >; Ts = {}]’ with unsatisfied constraints
   37 | return dont_overlap(all_prev_masks | this_mask, ts...);
  |^~~

... because ...

x.cpp:23:30: error: ‘mask_of_ones’ is not a member of ‘list, bf<0, 3>
>’
   23 | requires(T::mask_of_ones >=0)
  | ~^~~~

[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This is tricky because the condition reduces to true/false before the static
assertion evaluates it. We could introduce a new binary expression that stores
the original expression and it's computed value, and use that to hook into
diagnostics from the static assert.

[Bug c++/92268] Constraint normalization substitutes parameter too early

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
> [02:40]  but it looks like when we normalize the forward_iterator 
> constraint on the compound-requirement we're normalizing 
> forward_iterator, which is wrong -- we should be normalizing 
> forward_iterator, and then checking whether that's satisfied with iterator

> [02:40]  Andrew sent me a patch to improve handling of nested 
> requirements that I haven't looked at yet, it may help with this

This patch doesn't touch that. We're definitely not normalizing that constraint
at the point it appears. It's normalized w.r.t., substituted arguments in
do_auto_deduction.

I suppose the right thing to do is deduction vs. an unconstrained type, then
satisfaction vs. result.

[Bug c++/71125] [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125

--- Comment #3 from Andrew Sutton  ---
The TS did allow overloading function concepts.

Function concepts have some parsing issues related to TS-style terse notation,
overloading and variadic templates. In particular, there are places where
writing C forms a (possibly) syntactically valid placeholder C as part
of a functional cast expression, which leads to the error you're seeing: you're
incompletely instantiating a template-id that resolved to the template with two
parameters.

I think that's the error you're seeing here, but I wouldn't consider the issue
a show stopper. After all, function concepts don't exist in C++20 and they
can't be overloaded.

That said, I'm okay leaving this open.

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
Created attachment 46937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46937=edit
Patch against concepts-cxx2a (git format-patch format)

Adds a test for PR78752, which had been semi-fixed. The attached patch rebuilds
constraints involving abbreviated functions with function argument packs and
updates the corresponding template parameter list. We weren't doing that
before, so we were checking constraints with the wrong arguments.

[Bug c++/67862] [concepts] ICE in tsubst, at cp/pt.c:12625

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67862

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46849=edit
Patch against concepts-cxx2a (git format-patch format)

The original attachment doesn't build any more (compiler version issues) and
the 2nd issue has some compilation errors. After fixing the compilation errors,
this produces an ICE.

The attached patch fixes the associated crash, but this is likely not the same
as the issue originally submitted, which has either already been fixed or is
handled in completely different way.

There are two fixes here. First, normalization needs to find template
parameters in template-ids, including specializations of type alias templates.
Second, the normalization arguments from partial specializations must be formed
from the specialization parameters and not the most general template.

The included test is a fixed version of the 2nd attachment.

[Bug c++/67860] [concepts] bug with overloaded, refined function with explicit and variadic template arguments

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67860

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46834=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to have been resolved concepts-cxx2a. Patch adds a test for the
PR.

[Bug c++/67825] [concepts] expression constraint bug when taking address of a member function

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67825

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46833=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to have been fixed in concepts-cxx2a. Patch adds a test for the
PR.

[Bug c++/67774] [concepts] ICE when mismatching template arguments to concept

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67774

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46825=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This was previously fixed in the concepts-cxx2a branch. Providing a patch that
adds a test for the PR.

[Bug c++/67727] [concepts] parameterized constraint not being checked for unused variables

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67727

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46824=edit
Patch against concepts-cxx2a to add test (git format-patch format)

Apparently, this has been previously fixed in the concepts-cxx2a branch.
Providing a patch that adds a test for the PR.

[Bug c++/67719] [concepts] bug with concepts using logical or

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67719

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46823=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to have been previously fixed in the concepts-cxx2a branch.
Providing a patch that adds a test.

[Bug c++/67704] [concepts] requirements not being applied to aliases

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67704

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Confirmed. 

Constraints on dependent types aren't checked, but alias templates are always
"transparent". In the requirements on f, the type requirement R is simply
replaced by its instantiation, and the associated constraints are discarded.

There's a smaller version of this bug in the test suite in
g++.dg/cpp2a/concepts-alias.C, which is currently marked as xfail.

[Bug c++/67697] [concepts] ICE when using non-constexpr in requires expression

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67697

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46822=edit
Patch against concepts-cxx2a (git format-patch format)

This was fixed in concepts-cxx2a. The attached patch adds a test for the PR and
emits the error at the right location in the source file.

[Bug c++/67692] [concepts] ICE when using requires in non-concept contexts

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67692

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46821=edit
Patch against concepts-cxx2a to add test.

The issue appears to have been previously resolved.

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67685

--- Comment #3 from Andrew Sutton  ---
Fixed in the concepts-cxx2a branch and added a test for the PR.

[Bug c++/67684] [concepts] friend access not working with constrained function

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67684

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch and added a test for the PR.

[Bug c++/67658] [concepts] invalid code with constrained concepts compiles

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46819=edit
Patch against concepts-cxx2a to add test (git format-patch format)

[Bug c++/67654] [concepts] ICE when using concepts in constexpr function

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67654

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Added a test for this PR in the
concepts-cxx2a branch.

[Bug c++/67427] [concepts] Subsumption dependence on template parameter ordering

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427

--- Comment #1 from Andrew Sutton  ---
I believe that the ambiguity is correct under the revised semantics of
concepts.

The targets of the parameter mapping in Sentinel differs for the two
declarations of distance because the order of template parameters changes. For
the first declaration, the parameter mapping of the normal form of the requires
expression maps the 2nd template parameter of the concept to the 2nd template
parameter of the function template. For the second declaration, the normal form
of the requires expression maps the 2nd template parameter of the concept to
the 1st template parameter of the function template. Template parameters with
different indexes are not equivalent.

[Bug c++/67319] Short-hand concepts for variadic member functions broken

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Add a test for this PR in
concepts-cxx2a.

[Bug c++/67225] [concepts] Expression constraint with a constrained result turns off access checking

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67225

--- Comment #7 from Andrew Sutton  ---
It looks like there was an earlier state where access was being turned
off by one construct or another. All of the examples here fail as they're
supposed to. Added tests to concepts-cxx2a.

[Bug c++/67217] [concepts] Constraints are ignored when specializing union templates

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67217

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a. Added a test for this PR.

[Bug c++/67210] [concepts] Error parsing ">>" after a template-id that names a concept

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67210

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been resolved at some point. Added a unit test to the
concepts-cxx2a branch.

[Bug c++/67178] [concepts] ICE on self-referencing concept

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67178

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch. Added a test for this PR.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147

--- Comment #6 from Andrew Sutton  ---
There's a test for this PR in the concepts-cxx2a branch.

[Bug c++/67148] [concepts] Failed concept check when indirecting through a constrained trait

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67148

--- Comment #3 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch, which also has a test for this PR.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147

--- Comment #5 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070

--- Comment #11 from Andrew Sutton  ---
Most of the concerns in this issue have been resolved when concept satisfaction
was defined in terms of normalized constraints in all contexts (requirements or
otherwise). In particular. negation makes the constraint atomic, and we don't
recursively normalize atoms. Negation is not a logical operator for the purpose
of subsumption.

Note that the case of overloading with the constraints !(C && C) vs
(!C || !C) is ambiguous since the atomic constraint !(C && C)
doesn't match either  !C and !C (and vice versa).

The concepts-cxx2a branch implements the new semantics.

[Bug c++/66844] [c++-concepts] Requires-expression parameter with void type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66844

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #4 from Andrew Sutton  ---
The parameter list of a requires clause should have the same restrictions as
that of a function's, unless WG21 decides to relax this later. The
concepts-cxx2a branch disallows void parameters, making both examples
ill-formed.

A (void) parameter-list is still permitted and is equivalent to ().

[Bug c++/81139] New: Non-deduced return type in abbreviated function template

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81139

Bug ID: 81139
   Summary: Non-deduced return type in abbreviated function
template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.n.sutton at gmail dot com
  Target Milestone: ---

When a constrained-type-specifier is the same as that of a parameter type, the
return type is not deduced. 


template concept bool C = true;

C f(C) { return 0; }

void g() {
  auto x = f("x");
  static_assert(std::is_same<decltype(x), int>::value);
}

The static assertion should fail.

[Bug c++/71965] [6/7 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71965

--- Comment #5 from Andrew Sutton  ---
Hmm... I haven't looked at this in a while. It looks like the expansion of
ConstructibleObject is triggering the diagnostic. I'm a
little surprised that this gets diagnosed -- especially with a "sorry". But it
still shouldn't happen.

The implementation (I suspect this comes out of satisfy_check_constraint)
appears to be substituting through too aggressively. It expands the concept
using the instantiated arguments, the pair of int[2][2]s, around
constraint.cc:2056. I'm guessing that that ultimately triggers a substitution
of those arguments into the requirements of the requires-expression. Bang!
error.

One solution would be to make expand_concept() simply return the definition and
then decompose that expression, substituting when needed.

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67685

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Quickly investigating. In tsubst_requires_expr, we add to the local
specialization stack, which means that any local variables or parameters
referenced within the requires-expression will not be visible, which ultimately
causes undefined behavior in tsubst_copy.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070

--- Comment #7 from Andrew Sutton andrew.n.sutton at gmail dot com ---
We haven't evaluated constraints as expressions in a long time (since
post-Rapperswil I think).

I don't think this is a good idea, but mostly because I'm not sure what the
instantiation/satisfaction semantics are. Consider:

templatetypename T
concept bool C() { return T::value; }

templatetypename T void f(T); // #1
templateC T void f(T);// #2

f(0); // ill-formed or #1?

If you evaluate constraints as expressions, then how is CT() instantiated? If
it's instantiated like a regular function, then the program should be
ill-formed since we're in a different instantiation context (in exactly the
same way this would fail for a function with a deduced return type).

We might alternatively evaluate concept checks by always evaluating them in a
SFINAE context, and defining, so that CT() returns true iff its constraint is
satisfied. Here, T::value (for int) yields a substitution failure and is not
satisfied. So #1 is chosen.

But these semantics actually do something a little weird for !. It let's you
write checks for when substitution fails or a constraint is not satisfied.

templatetypename T
  requires !CT()
void g();

g() is selected whenever CT() is not satisfied, or if substitution into
CT() fails. Those semantics were not considered in the original design. A
predicate constraint should evaluate a valid predicate. Substitution failure is
a kind of higher-order property of the system.

I'm also worried that evaluating constraints in this way would force us to
consider extending the logical system to support negation. And it's not always
obvious what the semantics of things like:

  !requires { typename T::type; }

would mean. Is it that T::type must not exist? Is it that T::type is not
required to exist? There are very good reasons to select both.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070

--- Comment #8 from Andrew Sutton andrew.n.sutton at gmail dot com ---
And as an afterthought, adding negation makes the subsumption solver more
complex, since determining implications in the presence of negation would mean
decomposition of both the left and right sides of the implication, and
modifying those term lists whenever negation is encountered.

It's certainly doable, but it's going to add a *lot* of overhead: decomposing
conjunctions on the RHS is the same as disjunctions on the LHS. 

That gets us into ways to heuristically simplify constraints by identifying and
removing tautologies or reducing to contradiction where possible. I don't know
what the overhead of those algorithms are.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
 This is a very subtle point.  It seems to me that it would be better if
 creating the normal form of a constaint stops substituting into concept bodies
 once it's clear that we're inside an atomic constraint.  So f would have a
 single atomic predicate constraint

  !AT

 and then when we consider this later we try to satisfy AB, which fails, so
 f's constraint is satisfied and the testcase succeeds.  Though this does 
 create
 an inconsistency in argument substitution behavior across the ! operator, 
 which
 might be confusing.

 Any thoughts, Andrew?

I had a bug report filed against that behavior earlier this year (note
Bugzilla, just an outside email). If you stop substituting through
atomic constraints, then requirements in e..g, AT would not be
substituted in the immediate context. Basically, it makes any concepts
behind a ! not SFINAE friendly.

If we had a rule that allowed the evaluation of a concept in any
context, then we could avoid doing this. It would also guarantee the
ability to write;

   static_assert(CT);

This is probably a good issue to raise against the TS, and we should
discuss it in Kona.

Andrew

[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962

--- Comment #14 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Created attachment 36054
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36054action=edit
Optimize constraint decomposition by contraction

The problem isn't strictly related to decomposition -- it's normalization prior
to decomposition that's causing the problems. Whenever you have a disjunction
in a low-level concept, that OR can be instantiated into the normalized
constraints many, many times. I think I measured 20 times in the reduced
example. I think there's actually worst case 2^N growth in the space required
to solve the problem.

Currently, we might accumulate a term list during decomposition like so:

P || Q, P || Q, P, R, P || Q

And then recursively decompose each term in that list. Each || turns into a new
branch, here, eventually generating 8 different term lists, none of which are
semantically different than any other. They're just permutations of terms.

The patch helps reduce the space by disallowing duplicate expressions to be
added to a term list during decomposition. So instead of generating the term
list above, we just have:

P || Q, P, R

Only one branch required.

There is still complexity induced by the use of disjunctions. This manages it a
little better. It could be further improved by making the term list into a term
set by way of hashing or ordering.

[Bug c++/66988] [concepts] concept with template template parameter satisfied erroneously

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66988

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
I don't know if that's strictly a concepts issue. My guess is that the template
argument coersion of this argument:

   template typename class

to this parameter:

   template typename... class

is not succeeding.

[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962

--- Comment #13 from Andrew Sutton andrew.n.sutton at gmail dot com ---
There are a couple of other problems in the minimized example (concept int
shows up a couple of times, there's a variable template whose initializer is a
requires expression). I doubt those contribute to the observed problem.

I suspect there's something else at work. There was a performance problem
related earlier this year where (either) normalization or decomposition was
being applied for each subexpression multiple times.

The total number of elements in a decomposition should be linear w.r.t. to the
number of disjunctions. I'll try to look through this tomorrow.

A possible optimization is to store specializations of each concept being
normalized, so we don't expand to the same expressions over and over again --
basically, helping to ensure that we don't have lots of duplicate cases that
we're proving over and over again. It would probably be a good idea to prove
that's logically sound before implementing :/

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #12 from Andrew Sutton andrew.n.sutton at gmail dot com ---
 So it seems that applying the DR 1430 tentative resolution to concepts 
 severely
 limits the usability of variadic concepts, and we should reconsider that, so
 that instead we delay normalization of template-ids with variadic arguments
 until instantiation time.

 The restriction on expansion arguments to non-expansion parameters initially
 applied to all variadic templates until N2555, which Eric was also involved
 with...

I don't think that's a good idea. It means the template-id would be
characterized as an atomic constraint for purposes of partial
ordering. You lose the ability to order on constraints within the
concept, which means you're no better off than using a type trait for
the definition.

I would make the following observations:

1. Variadics require meteaprogramming and pattern matching
2. The constraint are not intended to be turing complete, so we can't
reason about metaprograms
3. There may be useful logical extensions to the constraint language
for working with variadics in principled ways
4. Some variadic constraints might be useful as core language
constraints (intrinsics).

Plus, I have a feeling that I'm going to to have to re-think the
entire concept definition and requires-expression bit when we propose
concepts for C++. There were too many NB comments to ignore.

Andrew

[Bug c++/66841] [concepts] bogus error invalid reference to function concept when function concept is overloaded

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
The program is ill-formed. In this line:

   requires ConstructibleT, Args...() // ERROR HERE

There's no single declaration of Constructible that can be matched to those
template arguments. You would need one with this signature: typename T,
typename... Args.

I think defining Constructible so that it backends into a type trait will give
you the behavior you're looking for.

templatetypename T, typename... Args
concept bool Constructible() {
  return std::is_constructibleT, Args...::value;
}

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #7 from Andrew Sutton andrew.n.sutton at gmail dot com ---
 I would expect a partial ordering to prefer the two-parameter overload in that
 case. But yeah, it's a separate issue.

The problem is that partial ordering doesn't apply to template
parameters whose arguments can only be given explicitly. I got caught
by this last year, and sent an email to core, and then (I think) Ville
submitted a core issue or NB comment (I don't remember the details).

Andrew

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
I think that this is invalid too. There's an expansion from an
uninstantiated template argument pack into a pair of template
parameters.

I think the program must be ill-formed in this case. It's not possible
to substitute a single pack through the two parameters declared for
ExplicitlyConvertible in order to normalize the constraint.

The TS is silent on this, but the resolution should be the same as that of
1430.

Andrew Sutton


On Fri, Jul 10, 2015 at 10:48 PM, jason at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org ---
 This was introduced by my patch for bug 66092, applying the tentative
 resolution of core issue 1430 to concepts as well as alias templates.  This
 makes sense to me since they have the same issue of needing to substitute
 dependent arguments into the template, in this case during normalization.

 So I think your example is invalid, but it could use some discussion in core.

 --
 You are receiving this mail because:
 You are on the CC list for the bug.

[Bug c++/66092] [c++-concepts] Concept can't check variadic template arguments

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66092

Andrew Sutton andrew.n.sutton at gmail dot com changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
I think that this should be ill-formed.

template typename T, typename U, typename... Args
  concept bool Same()
  {
return decltype(checkT, U, Args...())::value;
  }

template typename... Args
requires SameArgs...()
  void foo( Args... args ) {}


Template constraint processing requires that flatten (inline) the check for
SameArgs...(), but I don't see how we can substitute a dependent argument
pack into three distinct template parameters (T, U, and ...Args). 

The wording prohibiting this is missing in the TS.

[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---

Confirmed. Fixed in r223061.

When a function declaration started with a non-function declarator, the
requires-clause wasn't being attached to the right declarator object so it
wasn't being added to the declaration.

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed. Parsing a type requirement that names an alias template was giving
back a declaration, which wasn't being instantiated correctly. 

r222769 unwraps the type from the declaration and will correctly reject the
test case.

[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848

--- Comment #4 from Andrew Sutton andrew.n.sutton at gmail dot com ---

 I think that is actually not so unfortunate.  Statically asserting 
 concept models has helped me find numerous issues in my own code.  
 I'm glad to hear the proposal is being extended to cover this.

Unfortunate in the sense that we missed the features that would allow that
usage. But to be fair, it wasn't exactly a primary use case when we were
considering the design.

[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Here's the result of the latest commit (r222332) on my system. test.cpp is the
program in the bug report.

Command being timed: ~/opt/bin/g++ -std=c++1z -c test.cpp
User time (seconds): 0.04
System time (seconds): 0.01
Percent of CPU this job got: 91%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.07
...
Maximum resident set size (kbytes): 49344
...
Minor (reclaiming a frame) page faults: 4465

[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
This is caused by the use of a concept outside of a requires clause -- it's
still a bug though. The TS doesn't actually include wording that would allow
this program to be valid.

Unfortunately, the first thing people do when they have concepts it to write
tests that statically assert them, so I've been extending the proposal to make
that valid.

The performance regression is related to that. When you call C11S6(), we
normalize that expression as a constraint and check it. Unfortunately, that
same logic applies for *every single concept check* that appears in an
expression formed while normalizing that constraint. Basically, you're invoking
a giant recursive yo-yo in order to evaluate the constraint.

Like I said... still a bug. I hope to have this resolved in the next half hour.

[Bug c++/65681] [c++-concepts] spurious ambiguous template instantiation error; regression from r211824

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
This is a good one. It is a regression, but it didn't have to do with the
resolution of partial specializations.

The substitution into requires-expressions was too eagerly doing full semantic
on analysis on simple and compound requirements, and that was causing a later
constraint check for a member function to fail unexpectedly.

Substituting a concrete type (say, MA2) into the constraint !CA2MA2 is
generating a requirement for the expression t.MA2::mf(). When we go to check
that letter, we perform another substitution with the expectation that, in this
case, the result would be identical to the original since it's already been
resolved. However, the substitution actually rebuilds the call expression and
tries to resolve it as MA2::mf(t), which fails.

Anyways, this is resolved by deferring all semantic analysis to constraint
checking, and not allowing it to happen when we substitute into requirements.

Fixed in r36.

[Bug c++/65636] [c++-concepts] ICE (Segmentation fault) when a type requirement names a typedef or type alias

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed and with a tentative fix in r221856.

Certain type declarations occurring at namespace scope are not given C++
language extensions, so when we try to pass those through tsubst_decl, the
specialization handling bits fail. This prevents those from being used, but
still performs the substitution, performing access checks, copying attributes,
etc.

I'd like a maintainer to look at the solution. There's probably a better way to
address the problem.

[Bug c++/65636] [c++-concepts] ICE (Segmentation fault) when a type requirement names a typedef or type alias

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Created attachment 35225
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35225action=edit
Proposed solution

[Bug c++/65635] [c++-concepts] ICE in cp_tree_equal() during class template partial specialization constraint matching

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed and fixed in r221857.

[Bug c++/65634] [c++-concepts] ICE in check_noexcept_r() for a noexcept constraint on a static member function call requirement

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Created attachment 35222
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35222action=edit
Proposed solution

[Bug c++/65634] [c++-concepts] ICE in check_noexcept_r() for a noexcept constraint on a static member function call requirement

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed and fixed 221854, but I'd like a maintainer to look at the attached
patch. 

The bug was caused by asking for TYPE_NOTHROW_P on the function return type
instead of the function type. Strangely, this is only affecting this one test
case and none of the other noexcept tests.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #3 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Created attachment 35163
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35163action=edit
Patch applied in r221733

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #4 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Apparently I do not understand declarators. The attached patch searches through
the declarator structure to filter out declarator structures to which a
requires-clause cannot be attached.

I updated the pr665575.C test to include more examples (positive and negative),
but that's not reflected in the attached patch. I haven't been able to test as
thoroughly as I'd like because I'm at the airport, but this seems like the
right thing to do.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #6 from Andrew Sutton andrew.n.sutton at gmail dot com ---
The requires-clause comes before the = default (the = xxx) is considered part
of the function definition. So:

  void f() requires true = default;


As a side note, the production following the requires-clause is a
logical-or-expression, so the '=' would not be interpreted as part of the
constraint.

But I don't think there are test cases for that.

If you find a problem, please open a new issue.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed and resolved in r221695. 

Removed the check for trailing requires-clauses on non-function declarators.
This should make the presence of a trailing-requires clause in a context where
it doesn't belong a syntax error (expected 'XXX', but got 'requires', for
example).

[Bug c++/65552] [c++-concepts] Constraint checking regression for concepts with multiple type requirements

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65552

Andrew Sutton andrew.n.sutton at gmail dot com changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Confirmed and resolved in r221669.

[Bug c++/65269] internal compiler error: Segmentation fault

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65269

--- Comment #4 from Andrew Sutton andrew.n.sutton at gmail dot com ---
 Seems to me that return requires() as yet does not do type requirement
   as mentioned in n3701.pdf, pg 6

I needed to push the relevant changes to Origin, which I just did.

[Bug c++/65269] internal compiler error: Segmentation fault

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65269

Andrew Sutton andrew.n.sutton at gmail dot com changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
This was caused by not checking that current_template_parms was valid during
when building constraints for the declaration.

This is was fixed in the last commit (221280).

[Bug c++/59361] cannot expand parenthesized pack expression

[andrew.n.sutton at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361

Andrew Sutton andrew.n.sutton at gmail dot com changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com ---
Created attachment 32522
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32522action=edit
Proposed solution

The problem occurs in cp_parser_cast_expression. A term of having the form
(T())... cannot be parsed as a cast expression since the the expansion is only
applied to a part of the cast expression. If ... follows the closing paren, the
expression must be parsed as unary expression.