[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Mar 10 16:14:29 PST 2023


rsmith added a comment.

In D124351#4185007 <https://reviews.llvm.org/D124351#4185007>, @aaron.ballman wrote:

> In the reproducer from Sam, there are three lambdas: 
> `create::Create<R>([] {});` in `main.cpp`, but this does not participate in AST merging because it's within the main source file
> `BuildWidget<T>([dummy](Widget<T>*) {});` in `create.h`

There should be three of these in total: one from `wrap_create.h`'s textual inclusion of `create.h`, one from `instantiate_create.h`'s textual inclusion of `create.h`, and one from `instantiate_create.h`'s instantiation of `Create<float>`. The first two should get merged together if they're both loaded. This runs into some issues, because the local `dummy` variable in the two different bodies of the `Create` template don't get merged. In rG4a1ccfe8a3cfd4569bc962a38b6117a9a2b8ad21 <https://reviews.llvm.org/rG4a1ccfe8a3cfd4569bc962a38b6117a9a2b8ad21> I attempted to fix that by tracking all the lists of captures from different merged copies of the lambdas, so we can find the right way to name (eg) `dummy` in the enclosing context. Possibly some more work is needed here, to make template instantiation look through that list when instantiating a reference to a declaration, in the case where we pick a lambda body from one module but pick the enclosing function's body from a different module.

> The first lambda it reads is the one in `InstantiateCreate()`. The next three all have captures of `dummy`; the first two come from the `instantiate_create` module and the last one comes from the `wrap_create` module.

That sounds right to me. One of the ones from `instantiate_create` (the one taking `Widget<T>*`, not the one taking `Widget<float>*`) should be merged with the one from `wrap_create.h`.



================
Comment at: clang/lib/Sema/SemaCXXScopeSpec.cpp:295-298
+  if (getCurLambda()) {
+    Diag(SuperLoc, diag::err_super_in_lambda_unsupported);
+    return true;
+  }
----------------
Will this also reject `__super` in a local class inside a lambda? That seems like something we should still permit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124351/new/

https://reviews.llvm.org/D124351



More information about the cfe-commits mailing list