Capture of `*this` in explicit object parameter lambda doesn't respect qualifiers

[wreien]

struct S {
  int x;

  auto foo() {
    return [*this](this auto&&) {
      __builtin_printf("%d ", x);
      x = 10;
    };
  }
};

int main() {
  S s{ 5 };
  const auto l = s.foo();
  l();
  s.x = 15;
  l();
  __builtin_printf("%d\n", s.x);
}

https://godbolt.org/z/35qjr473K

Expected: an error that you cannot modify x within a const lambda.

Result: Prints 5 10 15, demonstrating both that l has captured a copy of S, and also that (despite being a const object) it is nevertheless mutating its own state.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nathaniel Shead (wreien)

```cpp struct S { int x;

auto foo() {
return [*this](this auto&&) {
__builtin_printf("%d ", x);
x = 10;
};
}
};

int main() {
S s{ 5 };
const auto l = s.foo();
l();
s.x = 15;
l();
__builtin_printf("%d\n", s.x);
}

https://godbolt.org/z/35qjr473K

Expected: an error that you cannot modify `x` within a `const` lambda.

Result: Prints `5 10 15`, demonstrating both that `l` has captured a copy of `S`, and also that (despite being a `const` object) it is nevertheless mutating its own state.
</details>

[Sirraide]

I think Clang is correct here. [expr.prim.lambda] states (emphasis mine):

If the lambda-declarator contains an explicit object parameter ([dcl.fct]), then no lambda-specifier in the lambda-specifier-seq shall be mutable or static.

The function call operator or operator template [...] is a non-static member function or member function template ([class.mfct.non.static]) that is declared const ([class.mfct.non.static]) if and only if the lambda-expression's parameter-declaration-clause is not followed by mutable and the lambda-declarator does not contain an explicit object parameter.

Note that, if we change this auto&& to e.g. this const auto&, Clang errors as expected. From what I can tell, the idea here is that you’re supposed to make the lambda const or non-const by including or not including const in the type of the explicit object parameter. Since you didn’t do that, the lambda ends up being effectively mutable as a result.

[wreien]

I think this is still an issue: for an xobj parameter the operator() couldn't have been marked const in the first place (struct S { auto operator()(this auto&&) const; }; is erroneous anyway, because you can't mark xobj functions as const at all).

struct S {
  int x;
  void operator()(this auto&& self) { self->x = 10; };
};

int main() {
  const S s;
  s();  // error
  
  const auto f = [x = 10](this auto&& self) { x = 20; };
  f();  // OK?
}

So I don't think the intention here is that the lambda ought to always become "mutable" (whatever that means for an xobj parameter) if you have a forwarding reference self, because in that case self would not be forwarding at all.

(Also while looking at this I found that Clang at least consistently always treats by-value captures as non-const.)

FWIW MSVC complains about the initial code too, with

<source>(6): error C3490: 'x' cannot be modified because it is being accessed through a const object
<source>(6): note: the template instantiation context (the oldest one first) is
<source>(14): note: see reference to function template instantiation 'auto S::foo::<lambda_1>::operator ()<const S::foo::<lambda_1>&>(_T1)' being compiled
        with
        [
            _T1=const S::foo::<lambda_1> &
        ]

[Sirraide]

So I don't think the intention here is that the lambda ought to always become "mutable"

Right, what I meant wasn’t that it’s allways mutable, but rather, it isn’t always const, unless the explicit object parameter is const.

const auto f = [x = 10](this auto&& self) { x = 20; };
f();  // OK?

This seems wrong to me as well; I seem to have missed that the lambda object is declared const. I don’t think this should compile; I’ll look into this.

[Sirraide]

Ok, it seems there are two bugs here:

1. By-reference captures in lambdas with dependent explicit object parameters are being treated as dependent instead of by-value captures (however, that’s an easy fix; I’ve found the cause of that already), and
2. We’re not instantiating DeclRefExprs properly. E.g. this

template <typename> struct S {};

void a() {
  int x;
  const auto l = [&x](this auto&) { S<decltype(x = 42)> q; };
  l();
}

asserts in codegen on !T->isDependentType().

[Sirraide]

Ok, I think I’ve managed to fix it; just going to write a few more tests and then open a pr if everything goes well.