6 Commits

Author SHA1 Message Date
Younan Zhang
e04e140adb
[Clang] Reapply CWG2369 "Ordering between constraints and substitution" (#122423)
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).
2025-06-02 17:10:07 +08:00
Younan Zhang
3972ed5708
Revert "[Clang] Implement CWG2369 "Ordering between constraints and substitution"" (#122130)
Unfortunately that breaks some code on Windows when lambdas come into
play, as reported in
https://github.com/llvm/llvm-project/pull/102857#issuecomment-2577861178

This reverts commit 96eced624e0f120155256033fdcb8342e7e58d6e.
2025-01-08 18:27:25 +01:00
Younan Zhang
96eced624e
[Clang] Implement CWG2369 "Ordering between constraints and substitution" (#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
2025-01-05 10:50:52 +08:00
Haojian Wu
e0cdafe8d4 [AST] Better recovery on an expression refers to an invalid decl.
Prior to the patch, we didn't build a DeclRefExpr if the Decl being
referred to is invalid, because many clang downstream AST consumers
assume it, violating it will cause many diagnostic regressions.

With this patch, we build a DeclRefExpr enven for an invalid decl (when the
AcceptInvalidDecl is true), and wrap it with a dependent-type
RecoveryExpr (to prevent follow-up semantic analysis, and diagnostic
regressions).

This is a revised version of https://reviews.llvm.org/D76831

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D121599
2022-09-22 14:23:47 +02:00
Saar Raz
713562f548 [Concepts] Transform constraints of non-template functions to ConstantEvaluated
We would previously try to evaluate atomic constraints of non-template functions as-is,
and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656).

Substitute into atomic constraints of non-template functions as we would atomic constraints
of template functions, in order to rebuild the expressions in a constant-evaluated context.
2020-01-25 23:00:24 +02:00
Saar Raz
73eaf62463 [Concepts] Make constraint expressions unevaluated until satisfaction checking
As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become constant evaluated during satisfaction checking.

Change the evaluation context during parsing and instantiation of constraints to unevaluated.
2020-01-24 02:24:21 +02:00