[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