[clang] [clang-tools-extra] [llvm] [clang] WIP: Improved Context Declaration tracking (PR #107942)

Younan Zhang via cfe-commits cfe-commits at lists.llvm.org
Mon Sep 9 22:39:57 PDT 2024


================
@@ -14873,41 +14854,6 @@ TreeTransform<Derived>::TransformLambdaExpr(LambdaExpr *E) {
                                     /*IsInstantiation*/ true);
   SavedContext.pop();
 
-  // Recompute the dependency of the lambda so that we can defer the lambda call
-  // construction until after we have all the necessary template arguments. For
-  // example, given
-  //
-  // template <class> struct S {
-  //   template <class U>
-  //   using Type = decltype([](U){}(42.0));
-  // };
-  // void foo() {
-  //   using T = S<int>::Type<float>;
-  //             ^~~~~~
-  // }
-  //
-  // We would end up here from instantiating S<int> when ensuring its
-  // completeness. That would transform the lambda call expression regardless of
-  // the absence of the corresponding argument for U.
-  //
-  // Going ahead with unsubstituted type U makes things worse: we would soon
-  // compare the argument type (which is float) against the parameter U
-  // somewhere in Sema::BuildCallExpr. Then we would quickly run into a bogus
-  // error suggesting unmatched types 'U' and 'float'!
-  //
-  // That said, everything will be fine if we defer that semantic checking.
-  // Fortunately, we have such a mechanism that bypasses it if the CallExpr is
-  // dependent. Since the CallExpr's dependency boils down to the lambda's
-  // dependency in this case, we can harness that by recomputing the dependency
-  // from the instantiation arguments.
-  //
-  // FIXME: Creating the type of a lambda requires us to have a dependency
-  // value, which happens before its substitution. We update its dependency
-  // *after* the substitution in case we can't decide the dependency
-  // so early, e.g. because we want to see if any of the *substituted*
-  // parameters are dependent.
-  DependencyKind = getDerived().ComputeLambdaDependency(&LSICopy);
-  Class->setLambdaDependencyKind(DependencyKind);
----------------
zyn0217 wrote:

So after the removal of such, lines 14911 - 14914 would also be useless.

https://github.com/llvm/llvm-project/pull/107942


More information about the cfe-commits mailing list