[clang][modules] Remove the workaround for the lambda issue.

[hokein]

This code was originally introduced to fix issue #110401. The issue was the same lambda problem, which has since been properly fixed by PR #109167 and its follow-ups.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Haojian Wu (hokein)

Changes

This code was originally introduced to fix issue #110401. The issue was the same lambda problem, which has since been properly fixed by PR #109167 and its follow-ups.

---

Full diff: https://github.com/llvm/llvm-project/pull/142547.diff

1 Files Affected:

• (modified) clang/lib/AST/DeclCXX.cpp (+1-30)

diff --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index f24ea815768a6..f75f1029d55ef 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -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();
 }
 
 FunctionTemplateDecl* CXXRecordDecl::getDependentLambdaCallOperator() const {

[ChuanqiXu9]

Let's add an assert that the call we returned comes from the same module with RD.

[hokein]

hmm, adding assert(Calls.front()->getOwningModule() == RD.getOwningModule() I see two lambda-merging test breakages:

• Modules/lambda-merge.cpp
• Modules/pr102721.cppm

[ChuanqiXu9]

hmmm, then maybe we have to look at these failures before we land this ....

[hokein]

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.