Fixes: #60323https://github.com/llvm/llvm-project/issues/60323
The problem is that we are profiling the 'Expr' components directly,
however when they contain an unresolved lookup, those canonicalize
identically. The result was the two versions of calls to 'go' were
canonicalized identically.
This patch fixes this by ensuring we consider the declaration the
constraint is attached to, when possible. When not, we skip the
diagnostic.
The result is that we are relaxing our diagnostic in some cases (Of
which I couldn't come up with a reproducer), such that we might see
overflows when evaluating constraints that depend on themselves in a way
that they are not attached to a declaration directly, such as if
they are nested requirements, though the hope is this won't be a
problem, since the 'parent' named constraint would catch this. I'm
hopeful that the 'worst case' is that we catch recursion 'later' in the
process, instead of immediately.
This reverts commit b8064374b217db061213c561ec8f3376681ff9c8.
Based on the report here:
https://github.com/llvm/llvm-project/issues/59271
this produces a significant increase in memory use of the compiler and a
large compile-time regression. This patch reverts this so that we don't
branch for release with that issue.
Based on discussion on the core reflector, it was made clear that a
concept that depends on itself should be a hard error, not a constraint
failure. This patch implements a stack of constraint-checks-in-progress
to make sure we quit, rather than hitting stack-exhaustion.
Note that we DO need to be careful to make sure we still check
constraints properly that are caused by a previous constraint, but not
derived from (such as when a check causes us to check special member
function generation), so we cannot use the existing logic to see if this
is being instantiated.
This fixes https://github.com/llvm/llvm-project/issues/44304 and
https://github.com/llvm/llvm-project/issues/50891.
Differential Revision: https://reviews.llvm.org/D136975
