[clang] [clang][modules] Remove the workaround for the lambda issue. (PR #142547)
Haojian Wu via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 3 03:09:51 PDT 2025
================
@@ -1702,36 +1702,7 @@ static NamedDecl* getLambdaCallOperatorHelper(const CXXRecordDecl &RD) {
assert(allLookupResultsAreTheSame(Calls) &&
"More than one lambda call operator!");
-
- // FIXME: If we have multiple call operators, we might be in a situation
- // where we merged this lambda with one from another module; in that
- // case, return our method (instead of that of the other lambda).
- //
- // This avoids situations where, given two modules A and B, if we
- // try to instantiate A's call operator in a function in B, anything
- // in the call operator that relies on local decls in the surrounding
- // function will crash because it tries to find A's decls, but we only
- // instantiated B's:
- //
- // template <typename>
- // void f() {
- // using T = int; // We only instantiate B's version of this.
- // auto L = [](T) { }; // But A's call operator would want A's here.
- // }
- //
- // Walk the call operator’s redecl chain to find the one that belongs
- // to this module.
- //
- // TODO: We need to fix this properly (see
- // https://github.com/llvm/llvm-project/issues/90154).
- Module *M = RD.getOwningModule();
- for (Decl *D : Calls.front()->redecls()) {
- auto *MD = cast<NamedDecl>(D);
- if (MD->getOwningModule() == M)
- return MD;
- }
-
- llvm_unreachable("Couldn't find our call operator!");
+ return Calls.front();
----------------
hokein wrote:
Agree, I believe there is something wrong, and it needs a further look.
At the first glance, in `Modules/lambda-merge.cpp`, dumping the `RD` and `Calls.front()` here:
```
CXXRecordDecl 0x564c1efa6ff8 <workspace/llvm-project/build/tools/clang/test/Modules/A.map:10:12> col:12 imported in A implicit <undeserialized declarations> class definition
`-DefinitionData lambda pass_in_registers standard_layout trivially_copyable literal can_const_default_init
|-DefaultConstructor
|-CopyConstructor simple trivial has_const_param implicit_has_const_param
|-MoveConstructor exists simple trivial
|-CopyAssignment trivial has_const_param needs_implicit implicit_has_const_param
|-MoveAssignment
`-Destructor simple irrelevant trivial
CXXMethodDecl 0x564c1efdd428 parent 0x564c1efa6ff8 <workspace/llvm-project/build/tools/clang/test/Modules/B.map:10:14, col:28> col:12 imported in B used constexpr operator() 'auto () const -> int' inline
`-CompoundStmt 0x564c1efdd8e0 <col:16, col:28>
`-ReturnStmt 0x564c1efdd8d0 <col:18, col:25>
`-ImplicitCastExpr 0x564c1efdd8b8 <col:25> 'int' <LValueToRValue>
`-DeclRefExpr 0x564c1efdd898 <col:25> 'const int' lvalue Var 0x564c1efa78a0 'n' 'int' refers_to_enclosing_variable_or_capture
```
Here, the CXXMethodDecl's parent is `0x564c1efa6ff8`, but this method is not listed in the corresponding CXXRecordDecl's dump, this looks suspicious.
https://github.com/llvm/llvm-project/pull/142547
More information about the cfe-commits
mailing list