[Clang] Handle sema of noexcept condition in their evaluation context.

[cor3ntin]

The conditions of a noexcept and explicit specifier are full expressions. Before this patch, we would call ActOnFinishFullExpr on these in the context of the enclosing expression, which would cause the collect of odr-used variables (and subsequently capture attempts) in the wrong (enclosing) context.

This was observable when parsing the noexcept specifier condition of a lambda appearing in a wider full expression odr-using variables.

Fixes #67492

[llvmbot]

@llvm/pr-subscribers-clang

Changes

The conditions of a noexcept and explicit specifier are full expressions. Before this patch, we would call ActOnFinishFullExpr on these in the context of the enclosing expression, which would cause the collect of odr-used variables (and subsequently capture attempts) in the wrong (enclosing) context.

This was observable when parsing the noexcept specifier condition of a lambda appearing in a wider full expression odr-using variables.

Fixes #67492

---

Full diff: https://github.com/llvm/llvm-project/pull/67538.diff

4 Files Affected:

• (modified) clang/docs/ReleaseNotes.rst (+4)
• (modified) clang/lib/Parse/ParseDecl.cpp (+5-1)
• (modified) clang/lib/Parse/ParseDeclCXX.cpp (+5-1)
• (modified) clang/test/SemaCXX/lambda-expressions.cpp (+5)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index a17efab57bcdfa3..d74cd46c3bfccc6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -363,6 +363,10 @@ Bug Fixes to C++ Support
   reference. Fixes:
   (`#64162 <https://github.com/llvm/llvm-project/issues/64162>`_)
 
+- Clang no longer tries to capture non-odr-used variables that appear
+  in the enclosing expression of a lambda expression with a noexcept specifier.
+  (`#67492 <https://github.com/llvm/llvm-project/issues/67492>`_)
+
 Bug Fixes to AST Handling
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index f5b4107cc32c1f0..735d7a861c7bead 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -4162,7 +4162,11 @@ void Parser::ParseDeclarationSpecifiers(
           ExprResult ExplicitExpr(static_cast<Expr *>(nullptr));
           BalancedDelimiterTracker Tracker(*this, tok::l_paren);
           Tracker.consumeOpen();
-          ExplicitExpr = ParseConstantExpression();
+
+          EnterExpressionEvaluationContext ConstantEvaluated(
+              Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated);
+
+          ExplicitExpr = ParseConstantExpressionInExprEvalContext();
           ConsumedEnd = Tok.getLocation();
           if (ExplicitExpr.isUsable()) {
             CloseParenLoc = Tok.getLocation();
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index e5a278c598cfb63..6cae537ed21e215 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -3988,7 +3988,11 @@ ExceptionSpecificationType Parser::tryParseExceptionSpecification(
     // There is an argument.
     BalancedDelimiterTracker T(*this, tok::l_paren);
     T.consumeOpen();
-    NoexceptExpr = ParseConstantExpression();
+
+    EnterExpressionEvaluationContext ConstantEvaluated(
+        Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated);
+    NoexceptExpr = ParseConstantExpressionInExprEvalContext();
+
     T.consumeClose();
     if (!NoexceptExpr.isInvalid()) {
       NoexceptExpr =
diff --git a/clang/test/SemaCXX/lambda-expressions.cpp b/clang/test/SemaCXX/lambda-expressions.cpp
index 0c9e8584e653473..9cf81a0a195a573 100644
--- a/clang/test/SemaCXX/lambda-expressions.cpp
+++ b/clang/test/SemaCXX/lambda-expressions.cpp
@@ -718,3 +718,8 @@ void foo() {
 void GH48527() {
   auto a = []()__attribute__((b(({ return 0; })))){}; // expected-warning {{unknown attribute 'b' ignored}}
 }
+
+void GH67492() {
+  constexpr auto test = 42;
+  auto lambda = (test, []() noexcept(true) {});
+}

[shafik]

I wonder does this also fix this: #67058

[cor3ntin]

I wonder does this also fix this: #67058

Nope, this is unrelated, sadly.