Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
On 3/27/20 12:17 AM, Patrick Palka wrote:
On Mon, 16 Mar 2020, Patrick Palka wrote:
Hi Martin,
On Sun, 15 Mar 2020, Martin Sebor wrote:
On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
...
Hmm, like this? This version introduces a new static member function
diagnosing_failed_constraint::replay_errors_p that checks
current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p
when appropriate.
...
Just one small quoting nit:
@@ -3368,11 +3464,25 @@ diagnose_constraints (location_t loc, tree t, tree
args)
{
inform (loc, "constraints not satisfied");
+ if (concepts_diagnostics_max_depth == 0)
+return;
+
/* Replay satisfaction, but diagnose errors. */
if (!args)
constraint_satisfaction_value (t, tf_warning_or_error);
else
constraint_satisfaction_value (t, args, tf_warning_or_error);
+
+ static bool suggested_p;
+ if (concepts_diagnostics_max_depth_exceeded_p
+ && current_constraint_diagnosis_depth == 0
+ && !suggested_p)
+{
+ inform (UNKNOWN_LOCATION,
+ "set -fconcepts-diagnostics-depth= to at least %d for more
detail",
+ concepts_diagnostics_max_depth + 1);
Can you please quote the option name in the diagnostic (e.g., by using
"set %qs to...", "-fconcepts-diagnostics-depth=" or equivalent) to avoid
-Wformat-diag? It won't cause errors (yet) but will eventually need to
be cleaned up.
Yes sure, consider it done. I've amended the patch locally with this
change.
Here's a rebased version of this patch with the above diagnostic change,
no other changes made (aside from a minor adjustment to diagnostic5.C):
OK.
-- >8 --
gcc/c-family/ChangeLog:
* c.opt: Add -fconcepts-diagnostics-depth.
gcc/cp/ChangeLog:
* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::replay_errors_p): New static member
function.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.
* cp-tree.h (diagnosing_failed_constraint::replay_errors_p): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
---
gcc/c-family/c.opt | 4 +
gcc/cp/constraint.cc| 150 +---
gcc/cp/cp-tree.h| 1 +
gcc/testsuite/g++.dg/concepts/diagnostic2.C | 2 +-
gcc/testsuite/g++.dg/concepts/diagnostic5.C | 46 ++
5 files changed, 182 insertions(+), 21 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic5.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index a1e0f4cdc3a..c49da99d395 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1453,6 +1453,10 @@ fconcepts-ts
C++ ObjC++ Var(flag_concepts_ts) Init(0)
Enable certain features present in the Concepts TS.
+fconcepts-diagnostics-depth=
+C++ ObjC++ Joined RejectNegative UInteger Var(concepts_diagnostics_max_depth)
Init(1)
+Specify maximum error replay depth during recursive diagnosis of a constraint
satisfaction failure.
+
fcond-mismatch
C ObjC C++ ObjC++
Allow the arguments of the '?' operator to have different types.
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index a86bcdf603a..76c520318c3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -162,6 +162,7 @@ finish_constraint_binary_op (location_t loc,
/* When either operand is dependent, the overload set may be non-empty. */
if (expr == error_mark_node)
return error_mark_node;
+ expr.set_location (loc);
expr.set_range (lhs.get_start (), rhs.get_finish ());
return expr;
}
@@ -2395,6 +2396,49 @@ satisfy_conjunction (tree t, tree args, subst_info info)
return satisfy_constraint_r (TREE_OPERAND (t, 1), args, info);
}
+/* The current
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
On Mon, 16 Mar 2020, Patrick Palka wrote:
> Hi Martin,
>
> On Sun, 15 Mar 2020, Martin Sebor wrote:
>
> > On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
> > ...
> > > Hmm, like this? This version introduces a new static member function
> > > diagnosing_failed_constraint::replay_errors_p that checks
> > > current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p
> > > when appropriate.
> > >
> > ...
> >
> > Just one small quoting nit:
> >
> >
> > > @@ -3368,11 +3464,25 @@ diagnose_constraints (location_t loc, tree t, tree
> > > args)
> > > {
> > > inform (loc, "constraints not satisfied");
> > > + if (concepts_diagnostics_max_depth == 0)
> > > +return;
> > > +
> > > /* Replay satisfaction, but diagnose errors. */
> > > if (!args)
> > > constraint_satisfaction_value (t, tf_warning_or_error);
> > > else
> > > constraint_satisfaction_value (t, args, tf_warning_or_error);
> > > +
> > > + static bool suggested_p;
> > > + if (concepts_diagnostics_max_depth_exceeded_p
> > > + && current_constraint_diagnosis_depth == 0
> > > + && !suggested_p)
> > > +{
> > > + inform (UNKNOWN_LOCATION,
> > > + "set -fconcepts-diagnostics-depth= to at least %d for more
> > > detail",
> > > + concepts_diagnostics_max_depth + 1);
> >
> >
> > Can you please quote the option name in the diagnostic (e.g., by using
> > "set %qs to...", "-fconcepts-diagnostics-depth=" or equivalent) to avoid
> > -Wformat-diag? It won't cause errors (yet) but will eventually need to
> > be cleaned up.
>
> Yes sure, consider it done. I've amended the patch locally with this
> change.
Here's a rebased version of this patch with the above diagnostic change,
no other changes made (aside from a minor adjustment to diagnostic5.C):
-- >8 --
gcc/c-family/ChangeLog:
* c.opt: Add -fconcepts-diagnostics-depth.
gcc/cp/ChangeLog:
* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::replay_errors_p): New static member
function.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.
* cp-tree.h (diagnosing_failed_constraint::replay_errors_p): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
---
gcc/c-family/c.opt | 4 +
gcc/cp/constraint.cc| 150 +---
gcc/cp/cp-tree.h| 1 +
gcc/testsuite/g++.dg/concepts/diagnostic2.C | 2 +-
gcc/testsuite/g++.dg/concepts/diagnostic5.C | 46 ++
5 files changed, 182 insertions(+), 21 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic5.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index a1e0f4cdc3a..c49da99d395 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1453,6 +1453,10 @@ fconcepts-ts
C++ ObjC++ Var(flag_concepts_ts) Init(0)
Enable certain features present in the Concepts TS.
+fconcepts-diagnostics-depth=
+C++ ObjC++ Joined RejectNegative UInteger Var(concepts_diagnostics_max_depth)
Init(1)
+Specify maximum error replay depth during recursive diagnosis of a constraint
satisfaction failure.
+
fcond-mismatch
C ObjC C++ ObjC++
Allow the arguments of the '?' operator to have different types.
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index a86bcdf603a..76c520318c3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -162,6 +162,7 @@ finish_constraint_binary_op (location_t loc,
/* When either operand is dependent, the overload set may be non-empty. */
if (expr == error_mark_node)
return error_mark_node;
+ expr.set_location (loc);
expr.set_range (lhs.get_start (), rhs.get_finish ());
return expr;
}
@@ -2395,6 +2396,49 @@
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
Hi Martin,
On Sun, 15 Mar 2020, Martin Sebor wrote:
> On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
> ...
> > Hmm, like this? This version introduces a new static member function
> > diagnosing_failed_constraint::replay_errors_p that checks
> > current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p
> > when appropriate.
> >
> ...
>
> Just one small quoting nit:
>
>
> > @@ -3368,11 +3464,25 @@ diagnose_constraints (location_t loc, tree t, tree
> > args)
> > {
> > inform (loc, "constraints not satisfied");
> > + if (concepts_diagnostics_max_depth == 0)
> > +return;
> > +
> > /* Replay satisfaction, but diagnose errors. */
> > if (!args)
> > constraint_satisfaction_value (t, tf_warning_or_error);
> > else
> > constraint_satisfaction_value (t, args, tf_warning_or_error);
> > +
> > + static bool suggested_p;
> > + if (concepts_diagnostics_max_depth_exceeded_p
> > + && current_constraint_diagnosis_depth == 0
> > + && !suggested_p)
> > +{
> > + inform (UNKNOWN_LOCATION,
> > + "set -fconcepts-diagnostics-depth= to at least %d for more
> > detail",
> > + concepts_diagnostics_max_depth + 1);
>
>
> Can you please quote the option name in the diagnostic (e.g., by using
> "set %qs to...", "-fconcepts-diagnostics-depth=" or equivalent) to avoid
> -Wformat-diag? It won't cause errors (yet) but will eventually need to
> be cleaned up.
Yes sure, consider it done. I've amended the patch locally with this
change.
>
> Thanks
> Martin
>
>
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
...
Hmm, like this? This version introduces a new static member function
diagnosing_failed_constraint::replay_errors_p that checks
current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p
when appropriate.
...
Just one small quoting nit:
@@ -3368,11 +3464,25 @@ diagnose_constraints (location_t loc, tree t, tree args)
{
inform (loc, "constraints not satisfied");
+ if (concepts_diagnostics_max_depth == 0)
+return;
+
/* Replay satisfaction, but diagnose errors. */
if (!args)
constraint_satisfaction_value (t, tf_warning_or_error);
else
constraint_satisfaction_value (t, args, tf_warning_or_error);
+
+ static bool suggested_p;
+ if (concepts_diagnostics_max_depth_exceeded_p
+ && current_constraint_diagnosis_depth == 0
+ && !suggested_p)
+{
+ inform (UNKNOWN_LOCATION,
+ "set -fconcepts-diagnostics-depth= to at least %d for more
detail",
+ concepts_diagnostics_max_depth + 1);
Can you please quote the option name in the diagnostic (e.g., by using
"set %qs to...", "-fconcepts-diagnostics-depth=" or equivalent) to avoid
-Wformat-diag? It won't cause errors (yet) but will eventually need to
be cleaned up.
Thanks
Martin
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
On Wed, 11 Mar 2020, Jason Merrill wrote:
> On 3/9/20 6:23 PM, Patrick Palka wrote:
> > This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
> > which controls how deeply we replay errors when diagnosing a constraint
> > satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
> > diagnoses only the topmost constraint satisfaction failure and is consistent
> > with our behavior before this patch. By increasing this flag's value, the
> > user
> > can control how deeply they want the compiler to explain a constraint
> > satisfaction error.
> >
> > For example, if the unsatisfied constraint is a disjunction, then the
> > default
> > behavior is to just say "no branch in the disjunction is satisfied", but
> > with
> > -fconcepts-diagnostics-depth=2 we will additionally replay and diagnose the
> > error in each branch of the disjunction. And if the unsatisfied constraint
> > is a
> > requires expression, then we will replay the error in the requires
> > expression,
> > etc. This proceeds recursively until there is nothing more to replay or we
> > reached the exceeded the maximum depth specified by the flag.
> >
> > Implementation wise, this patch essentially just uncomments the existing
> > commented-out code that performs the error-replaying, adding logic to keep
> > track
> > of the current replay depth along the way. Besides that, there is a new
> > routine
> > collect_operands_of_disjunction which flattens a disjunction and collects
> > all of
> > its operands into a vector.
> >
> > Here are some examples of diagnostics with the two patches in this series.
> >
> > For the simple test case in which we call ranges::begin() on something
> > that's
> > not a range:
> >
> > #include
> >
> > struct S { } s;
> > auto x = std::ranges::begin(s);
> >
> > we get the following diagnostics with -fconcepts-diagnostics-depth={1,2,3}
> > respectively:
> >
> > https://pppalka.github.io/ranges-begin-depth-1.html
> > https://pppalka.github.io/ranges-begin-depth-2.html
> > https://pppalka.github.io/ranges-begin-depth-3.html
> >
> > And for the new test g++.dg/concepts/diagnostic5.C, we get:
> >
> > https://pppalka.github.io/diagnostic5-depth-1.html
> > https://pppalka.github.io/diagnostic5-depth-2.html
> > https://pppalka.github.io/diagnostic5-depth-3.html
> > https://pppalka.github.io/diagnostic5-depth-4.html
> >
> > The extra diagnostics enabled by this flag are at times longer than they
> > need to
> > be (e.g. "the operand is_array_v<...> is unsatisfied because \n the
> > expression
> > is_array_v<...> [with ...] evaluated to false") and not immediately easy to
> > follow (especially when there are nested disjunctions), but the transparency
> > provided by these optional diagnostics seems to be pretty helpful in
> > practice.
> >
> > Does this seem like a sensible approach? Thoughts and ideas for improvement
> > welcome. Wording and naming suggestions would be much appreciated.
>
> This does seem like a good approach, thanks.
>
> > gcc/c-family/ChangeLog:
> >
> > * c.opt: Add -fconcepts-diagnostics-depth.
> >
> > gcc/cp/ChangeLog:
> >
> > * constraint.cc (finish_constraint_binary_op): Set the location of
> > EXPR
> > as well as its range, because build_x_binary_op doesn't always do so.
> > (current_constraint_diagnosis_depth): New.
> > (concepts_diagnostics_max_depth_exceeded_p): New.
> > (collect_operands_of_disjunction): New.
> > (satisfy_disjunction): When diagnosing a satisfaction failure, maybe
> > replay each branch of the disjunction, subject to the current
> > diagnosis
> > depth.
> > (diagnose_valid_expression): When diagnosing a satisfaction failure,
> > maybe replay the substitution error, subject to the current diagnosis
> > recursion.
> > (diagnose_valid_type): Likewise.
> > (diagnose_nested_requiremnet): Likewise.
> > (diagnosing_failed_constraint::diagnosing_failed_constraint):
> > Increment
> > current_constraint_diagnosis_depth when diagnosing.
> > (diagnosing_failed_constraint::~diagnosing_failed_constraint):
> > Decrement
> > current_constraint_diagnosis_depth when diagnosing.
> > (diagnose_constraints): Don't diagnose if
> > concepts_diagnostics_max_depth
> > is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
> > the limit was exceeded.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
> > "neither operand".
> > * g++.dg/concepts/diagnostic5.C: New test.
> > ---
> > gcc/c-family/c.opt | 4 +
> > gcc/cp/constraint.cc| 146 +---
> > gcc/testsuite/g++.dg/concepts/diagnostic2.C | 2 +-
> > gcc/testsuite/g++.dg/concepts/diagnostic5.C | 46 ++
> > 4 files changed, 177 insertions(+), 21 deletions(-)
> > create mode 100644
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
On 3/9/20 6:23 PM, Patrick Palka wrote:
This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is consistent
with our behavior before this patch. By increasing this flag's value, the user
can control how deeply they want the compiler to explain a constraint
satisfaction error.
For example, if the unsatisfied constraint is a disjunction, then the default
behavior is to just say "no branch in the disjunction is satisfied", but with
-fconcepts-diagnostics-depth=2 we will additionally replay and diagnose the
error in each branch of the disjunction. And if the unsatisfied constraint is a
requires expression, then we will replay the error in the requires expression,
etc. This proceeds recursively until there is nothing more to replay or we
reached the exceeded the maximum depth specified by the flag.
Implementation wise, this patch essentially just uncomments the existing
commented-out code that performs the error-replaying, adding logic to keep track
of the current replay depth along the way. Besides that, there is a new routine
collect_operands_of_disjunction which flattens a disjunction and collects all of
its operands into a vector.
Here are some examples of diagnostics with the two patches in this series.
For the simple test case in which we call ranges::begin() on something that's
not a range:
#include
struct S { } s;
auto x = std::ranges::begin(s);
we get the following diagnostics with -fconcepts-diagnostics-depth={1,2,3}
respectively:
https://pppalka.github.io/ranges-begin-depth-1.html
https://pppalka.github.io/ranges-begin-depth-2.html
https://pppalka.github.io/ranges-begin-depth-3.html
And for the new test g++.dg/concepts/diagnostic5.C, we get:
https://pppalka.github.io/diagnostic5-depth-1.html
https://pppalka.github.io/diagnostic5-depth-2.html
https://pppalka.github.io/diagnostic5-depth-3.html
https://pppalka.github.io/diagnostic5-depth-4.html
The extra diagnostics enabled by this flag are at times longer than they need to
be (e.g. "the operand is_array_v<...> is unsatisfied because \n the expression
is_array_v<...> [with ...] evaluated to false") and not immediately easy to
follow (especially when there are nested disjunctions), but the transparency
provided by these optional diagnostics seems to be pretty helpful in practice.
Does this seem like a sensible approach? Thoughts and ideas for improvement
welcome. Wording and naming suggestions would be much appreciated.
This does seem like a good approach, thanks.
gcc/c-family/ChangeLog:
* c.opt: Add -fconcepts-diagnostics-depth.
gcc/cp/ChangeLog:
* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
---
gcc/c-family/c.opt | 4 +
gcc/cp/constraint.cc| 146 +---
gcc/testsuite/g++.dg/concepts/diagnostic2.C | 2 +-
gcc/testsuite/g++.dg/concepts/diagnostic5.C | 46 ++
4 files changed, 177 insertions(+), 21 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic5.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 1cd585fa71d..97ef488931d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1453,6 +1453,10 @@ fconcepts-ts
C++ ObjC++ Var(flag_concepts_ts) Init(0)
Enable certain features present in the Concepts TS.
+fconcepts-diagnostics-depth=
+C++ ObjC++ Joined RejectNegative UInteger
[PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is consistent
with our behavior before this patch. By increasing this flag's value, the user
can control how deeply they want the compiler to explain a constraint
satisfaction error.
For example, if the unsatisfied constraint is a disjunction, then the default
behavior is to just say "no branch in the disjunction is satisfied", but with
-fconcepts-diagnostics-depth=2 we will additionally replay and diagnose the
error in each branch of the disjunction. And if the unsatisfied constraint is a
requires expression, then we will replay the error in the requires expression,
etc. This proceeds recursively until there is nothing more to replay or we
reached the exceeded the maximum depth specified by the flag.
Implementation wise, this patch essentially just uncomments the existing
commented-out code that performs the error-replaying, adding logic to keep track
of the current replay depth along the way. Besides that, there is a new routine
collect_operands_of_disjunction which flattens a disjunction and collects all of
its operands into a vector.
Here are some examples of diagnostics with the two patches in this series.
For the simple test case in which we call ranges::begin() on something that's
not a range:
#include
struct S { } s;
auto x = std::ranges::begin(s);
we get the following diagnostics with -fconcepts-diagnostics-depth={1,2,3}
respectively:
https://pppalka.github.io/ranges-begin-depth-1.html
https://pppalka.github.io/ranges-begin-depth-2.html
https://pppalka.github.io/ranges-begin-depth-3.html
And for the new test g++.dg/concepts/diagnostic5.C, we get:
https://pppalka.github.io/diagnostic5-depth-1.html
https://pppalka.github.io/diagnostic5-depth-2.html
https://pppalka.github.io/diagnostic5-depth-3.html
https://pppalka.github.io/diagnostic5-depth-4.html
The extra diagnostics enabled by this flag are at times longer than they need to
be (e.g. "the operand is_array_v<...> is unsatisfied because \n the expression
is_array_v<...> [with ...] evaluated to false") and not immediately easy to
follow (especially when there are nested disjunctions), but the transparency
provided by these optional diagnostics seems to be pretty helpful in practice.
Does this seem like a sensible approach? Thoughts and ideas for improvement
welcome. Wording and naming suggestions would be much appreciated.
gcc/c-family/ChangeLog:
* c.opt: Add -fconcepts-diagnostics-depth.
gcc/cp/ChangeLog:
* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
---
gcc/c-family/c.opt | 4 +
gcc/cp/constraint.cc| 146 +---
gcc/testsuite/g++.dg/concepts/diagnostic2.C | 2 +-
gcc/testsuite/g++.dg/concepts/diagnostic5.C | 46 ++
4 files changed, 177 insertions(+), 21 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic5.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 1cd585fa71d..97ef488931d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1453,6 +1453,10 @@ fconcepts-ts
C++ ObjC++ Var(flag_concepts_ts) Init(0)
Enable certain features present in the Concepts TS.
+fconcepts-diagnostics-depth=
+C++ ObjC++ Joined RejectNegative UInteger Var(concepts_diagnostics_max_depth)
Init(1)
+Specify maximum error replay depth during recursive diagnosis of a constraint
