[Bug c++/113563] New: Rejects capture of `this` in C++23 `this auto` lambda

["arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563

            Bug ID: 113563
           Summary: Rejects capture of `this` in C++23 `this auto` lambda
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/KWv8n6zEG
struct S {
  int x_;
  void f() {
    [this](this auto) {
        return this;
    };
  }
};

GCC trunk complains:

<source>:5:16: error: invalid use of 'this' in non-member function
    5 |         return this;
      |                ^~~~

The error also happens with
- [this](this auto&&) { return this; }
- [this](this auto) { return x; }
- [this](this auto) { f(); }
- [&](this auto) { return this; }
- [&](this auto) { return x; }
- [&](this auto) { f(); }

My understanding is that all of these lambdas should be well-formed, just as
long as the lambda's call operator is eventually instantiated (if it's ever
instantiated at all) with a type that satisfies [expr.prim.lambda.closure]/5,
i.e. is either the closure type itself or a class type derived from the closure
type.


Btw, I do like that GCC eagerly and SFINAE-friendlily rejects `[&](this T) {}`.
I hope fixing this bug doesn't require undoing that feature.
(By "SFINAE-friendly" I mean https://godbolt.org/z/fK4f13343 )
See also
https://quuxplusone.github.io/blog/2024/01/23/capturing-lambda-deducing-this/