Spurious -Wunused-lambda-capture in presence of "if constexpr"

[llvmbot]

Bugzilla Link	35450
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@AaronBallman,@zmodem,@JVApen,@Meinersbur

Extended Description

The warning -Wunused-lambda-capture may indicate that a capture is unused if the body of the lambda contains an if constexpr construct and the capture is only used in the branch which was not instantiated.

Although Clang is technically correct that the capture is not used, the warning is unhelpful, since the capture cannot simply be removed without breaking cases that instantiate the the other branch.

If this is hard to fix "correctly", then Clang should suppress this warning for lambdas that contain an if-constexpr block.

Example:

template <bool b>
int foo(int a) {
  auto f = [&a]() {
    if constexpr(b) {
      return a;
    } else {
      return 0;
    }
  };
  return f();
}

void bar() {
  foo<false>(123);  // generates unused-capture warning in instantiation
  foo<true>(123);   // no warning
}

[zmodem]

Sorry, this does not seem to be getting fixed for clang 10, and I don't think we can block on it.

[JVApen]

Is there any update on when this can get fixed?

[Meinersbur]

Also causes problems when compiling flang: https://reviews.llvm.org/rGd4a1db4f3fd7

[AaronBallman]

I can confirm that this behavior still appears on trunk.

When instantiating the template for foo(), we only transform the non-discarded branch when the if statement condition has a known value.

llvm-project/clang/lib/Sema/TreeTransform.h

Line 7392 in ac7c880

if (!ConstexprConditionValue || *ConstexprConditionValue) {

llvm-project/clang/lib/Sema/TreeTransform.h

Line 7402 in ac7c880

if (!ConstexprConditionValue || !*ConstexprConditionValue) {

Because we only transform one branch per instantiation, we don't ever mark the capture as being used. However, this is done according to the standard: https://eel.is/c++draft/stmt.if#2.sentence-3

Because we can't instantiate the branch-not-taken when it's no longer dependent, I think we have to decide whether we'd rather have false positives or false negatives. Given that a false positive is trivial to workaround (add (void)a; to the lambda body outside of the branch), it seems reasonable to me that we prefer false positives to false negatives (it'd be a bummer for the "show me explicit captures I don't need" diagnostic couldn't tell you about a capture you don't need because of a possibly unrelated if constexpr in the lambda body).

[chrchr-github]

With trunk:
https://godbolt.org/z/vsPq3s8eG

[kdkavanagh]

Confirmed still an issue in v18.1