[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