The following program should fail to compile in C++20 because the type of the predicate in requires-clause is not bool. ``` template <typename T> struct is_small { enum { value = sizeof(T) <= 4 }; }; template <typename T> requires is_small<T>::value void fun(T) {} template <typename T> void fun(T) {} int main() { fun(1); // expected hard compiler error } ```
Started to be accepted with r10-3735-gcb57504a55015891.
Andrew, thoughts?
Isn't this fixable by simply tweaking satisfy_atom to unconditionally issue the error?
To wit: diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc index 697ed6726b8..59b43a31274 100644 --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -2543,8 +2543,7 @@ satisfy_atom (tree t, tree args, subst_info info) return cache.save (error_mark_node); if (!same_type_p (TREE_TYPE (result), boolean_type_node)) { - if (info.noisy ()) - error_at (loc, "constraint does not have type %<bool%>"); + error_at (loc, "constraint does not have type %<bool%>"); return cache.save (error_mark_node); } passes testing. Since currently we don't have an accurate location for the constraint we could also pretty print it with %qE (ie, what we did in 9).
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:fddfd3ce555965864b6116cf541f6355d2057d3d commit r10-7361-gfddfd3ce555965864b6116cf541f6355d2057d3d Author: Jason Merrill <jason@redhat.com> Date: Tue Mar 24 18:25:17 2020 -0400 c++: Improve handling of ill-formed constraints [PR94186]. It would have been trivial to make the error for non-bool constraint in satisfy_atom unconditional, but that didn't give context for the error or printing with the dependent form and template arguments. So I changed a couple of places so that, when a hard error is encountered during quiet substitution/satisfaction, we go through again noisily; this builds up the necessary context. The similar change to tsubst_nested_requirement does not build up the necessary context; rather than try to fix that now I changed get_constraint_error_location to give up and use input_location if there's no CONSTR_CONTEXT. In the case of concepts-pr67697.C, we still have a good source location because the NESTED_REQ has a correct EXPR_LOCATION, but this patch doesn't improve context printing for this case as it does for the above. gcc/cp/ChangeLog 2020-03-24 Jason Merrill <jason@redhat.com> PR c++/94186 * constraint.cc (constraint_satisfaction_value): Repeat noisily on error. (tsubst_nested_requirement): Likewise. (get_constraint_error_location): Allow missing context. (diagnose_atomic_constraint): Diagnose non-bool constraint here. (satisfy_atom): Not here. Only diagnose non-constant when noisy.
(In reply to Paolo Carlini from comment #3) > Isn't this fixable by simply tweaking satisfy_atom to unconditionally issue > the error? Yes, but I thought we could do better. :)