The previous approach broke code generation for the MS ABI due to an
unintended code path during constraint substitution. This time we
address the issue by inspecting the evaluation contexts and thereby
avoiding that code path.
This reapplies 96eced624 (#102857).
This patch partially implements CWG2369 for non-lambda-constrained
functions.
Lambdas are left intact at this point because we need extra work to
correctly instantiate captures before the function instantiation.
As a premise of CWG2369, this patch also implements CWG2770 to ensure
the function parameters are instantiated on demand.
Closes https://github.com/llvm/llvm-project/issues/54440
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
