Clang 17 regression: `variable 'test' cannot be implicitly captured` variable is not referenced in lambda

[MichielDerhaeg]

Clang fatal errors with the following error: error: variable 'test' cannot be implicitly captured in a lambda with no capture-default specified even though the variable is not referenced anywhere in the lambda.

Minimal reproducing input:

void foo() {
  constexpr auto test = 42;
  auto lambda = (test, []() noexcept(true) {});
}

• test needs to be constexpr
• The lambda expression needs to be a parameter to an expression. It doesn't reproduce if the lambda expression is assigned to a variable first.
• test needs to be passed as a parameter to the same expression.
• The noexcept specifier needs any expression. Passing no expression does not reproduce. Just noexcept does not reproduce even though it should be semantically equivalent.
• Issue doesn't reproduce with LLVM 16 or any version of GCC.

Git bisect has shown this commit to be the culprit: 93d7002

[shafik]

Looks like a bug to me CC @cor3ntin

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Clang fatal errors with the following error: `error: variable 'test' cannot be implicitly captured in a lambda with no capture-default specified` even though the variable is not referenced anywhere in the lambda.

Minimal reproducing input:

void foo() {
  constexpr auto test = 42;
  auto lambda = (test, []() noexcept(true) {});
}

• test needs to be constexpr
• The lambda expression needs to be a parameter to an expression. It doesn't reproduce if the lambda expression is assigned to a variable first.
• test needs to be passed as a parameter to the same expression.
• The noexcept specifier needs any expression. Passing no expression does not reproduce. Just noexcept does not reproduce even though it should be semantically equivalent.
• Issue doesn't reproduce with LLVM 16 or any version of GCC.

Git bisect has shown this commit to be the culprit: 93d7002

[cor3ntin]

Fun one.
I think we probably handle explicit and noexcept wrong.

We first call ParseConstantExpression which create and then pop an expression context.
Immediately after, ActOnNoexceptSpec ends up calling ActOnFullExpression. but ActOnFullExpression is then performed in the context of the enclosing expression, ie the comma expression.

But at this point, we already are in the scope of the lambda, so, when we try to collect all the variables that are
in need of cleanup, we find test, and we try to mark it ODR used. which forces a capture.

The noexcept condition is a full expression so at the end of that.

The underlying issue is that we should not pop the evaluation context before we are done with Sema, I think.
We do that for both noexcept and explicit, but I'm not sure the explicit behavior is currently observable.

I'll put a PR together

[MichielDerhaeg]

@cor3ntin Thanks for fixing this so fast.
Any idea if this will end up in a patch release or only as part of major release?

[cor3ntin]

Maybe it makes sense to backport it. what do you think @AaronBallman ?