[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter #84473

Sirraide · 2024-03-08T12:55:05Z

In short, dependence of captures in lambdas with an explicit object parameter is all kinds of broken at the moment. [temp.dep.expr] states that

An id-expression is type-dependent if [...] its terminal name is

associated by name lookup with an entity captured by copy ([expr.prim.lambda.capture]) in a lambda-expression that has an explicit object parameter whose type is dependent ([dcl.fct])

In issue #84163, it was observed that, if the lambda object is const but the explicit object parameter is not const but is type-dependent, any by-value captures are not treated as const, even though they should be:

const auto l1 = [x](this auto&) { x = 42; };
l1(); // Should error because `x` ends up being `const`, but we don’t.

This seems to be due to several compounding issues:

we’re treating by-reference captures as dependent rather than by-value captures;
tree transform doesn’t seem to check whether referring to such a by-value capture makes a DRE dependent;
when checking whether a DRE refers to an such a by-value capture, we only check the immediately enclosing lambda, and not any parent lambdas;
we also don’t check for implicit by-value captures;
attempting to determine whether a lambda has an explicit object parameter by checking the LambdaScopeInfo’s ExplicitObjectParameter doesn’t seem to work properly; I presume this is because this member refers to a ParmVarDecl that isn’t populated (yet) when we perform template instantiaion, which causes issues with nested lambdas that each have an explicit object parameter.

This pr should (eventually) fix all of these:

This is just due to a misplaced !, so that’s an easy fix.
This entails checking if the DRE is captured by value by a lambda with an explicit object parameter in TreeTransform<Derived>::TransformDeclRefExpr. That’s also an easy fix.
Currently, I’m simply iterating over all enclosing lambdas and checking if any of them capture the var decl that the DRE refers to by-value (explicitly or implicitly) rather than just looking at the parent lambda.
Check for implicit captures as well in 3.
Check for isExplicitObjectMemberFunction() on the lambda’s CXXMethodDecl instead.

This seems to have fixed all issues with captured variables; however, capturing this by value (and then accessing NSDMs) suffers from the same problem. My current approach for a fix is adding a CapturedByCopyInLambdaWithExplicitObjectParameter to CXXThisExpr and making this type-dependent, which is how this is tracked for DREs; this seems to have fixed the problem for this as well. If anyone has a better idea, feel free to let me know.

Issue #84425 also seems to involve capturing lambdas with explicit object parameters; this pr also seems to fix that issue.

This fixes #84163.

…ameter

llvmbot · 2024-03-08T12:55:43Z

@llvm/pr-subscribers-clang-modules

@llvm/pr-subscribers-clang

Author: None (Sirraide)

Changes

This is still WIP, but I figured I’d open a pr anyway to share what I’ve discovered so far. In short, dependence of captures in lambdas with an explicit object parameter is all kinds of broken at the moment. [temp.dep.expr] states that
> An id-expression is type-dependent if [...] its terminal name is
> - associated by name lookup with an entity captured by copy ([expr.prim.lambda.capture]) in a lambda-expression that has an explicit object parameter whose type is dependent ([dcl.fct])

In issue #84163, it was observed that, if the lambda object is const but the explicit object parameter is not const but is type-dependent, any by-value captures are not treated as const, even though they should be:

const auto l1 = [x](this auto&amp;) { x = 42; };
l1(); // Should error because `x` ends up being `const`, but we don’t.

This seems to be due to several compounding issues:

we’re treating by-reference captures as dependent rather than by-value captures;
tree transform doesn’t seem to check whether referring to such a by-value capture makes a DRE dependent;
when checking whether a DRE refers to an such a by-value capture, we only check the immediately enclosing lambda, and not any parent lambdas;
we also don’t check for implicit by-value captures;
attempting to determine whether a lambda has an explicit object parameter by checking the LambdaScopeInfo’s ExplicitObjectParameter doesn’t seem to work properly; I presume this is because this member refers to a ParmVarDecl that isn’t populated (yet) when we perform template instantiaion, which causes issues with nested lambdas that each have an explicit object parameter.

This pr should (eventually) fix all of these:

This is just due to a misplaced !, so that’s an easy fix.
This entails checking if the DRE is captured by value by a lambda with an explicit object parameter in TreeTransform<Derived>::TransformDeclRefExpr. That’s also an easy fix.
Currently, I’m simply iterating over all enclosing lambdas and checking if any of them capture the var decl that the DRE refers to by-value (explicitly or implicitly) rather than just looking at the parent lambda.
Check for implicit captures as well in 3.
Check for isExplicitObjectMemberFunction() on the lambda’s CXXMethodDecl instead.

This seems to have fixed all issues with captured variables; however, capturing this by value (and then accessing NSDMs) suffers from the same problem. My current approach for a fix is adding a CapturedByCopyInLambdaWithExplicitObjectParameter to CXXThisExpr and making this type-dependent, which is how this is tracked for DREs, but that’s still WIP. If anyone has a better idea, feel free to let me know.

Lastly, there’s also another issue (#84425) that seems to involve capturing lambdas with explicit object parameters; I have yet to determine if that one is related to this as well.

This fixes #84163.

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

3 Files Affected:

(modified) clang/lib/Sema/SemaExpr.cpp (+33-11)
(modified) clang/lib/Sema/TreeTransform.h (+2-2)
(modified) clang/test/SemaCXX/cxx2b-deducing-this.cpp (+81)

diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 47bb263f56aade..700769860aa806 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -20687,20 +20687,42 @@ void Sema::MarkVariableReferenced(SourceLocation Loc, VarDecl *Var) {
 static void FixDependencyOfIdExpressionsInLambdaWithDependentObjectParameter(
     Sema &SemaRef, ValueDecl *D, Expr *E) {
   auto *ID = dyn_cast<DeclRefExpr>(E);
-  if (!ID || ID->isTypeDependent())
+  if (!ID || ID->isTypeDependent() || !ID->refersToEnclosingVariableOrCapture())
     return;
 
+  // If any enclosing lambda with a dependent explicit object parameter either
+  // explicitly captures the variable by value, or has a capture default of '='
+  // and does not capture the variable by reference, then the type of the DRE
+  // is dependent on the type of that lambda's explicit object parameter.
   auto IsDependent = [&]() {
-    const LambdaScopeInfo *LSI = SemaRef.getCurLambda();
-    if (!LSI)
-      return false;
-    if (!LSI->ExplicitObjectParameter ||
-        !LSI->ExplicitObjectParameter->getType()->isDependentType())
-      return false;
-    if (!LSI->CaptureMap.count(D))
-      return false;
-    const Capture &Cap = LSI->getCapture(D);
-    return !Cap.isCopyCapture();
+    for (auto *Scope : llvm::reverse(SemaRef.FunctionScopes)) {
+      auto *LSI = dyn_cast<sema::LambdaScopeInfo>(Scope);
+      if (!LSI)
+        continue;
+
+      if (LSI->Lambda && !LSI->Lambda->Encloses(SemaRef.CurContext) &&
+          LSI->AfterParameterList)
+        return false;
+
+      const auto *MD = LSI->CallOperator;
+      if (MD->getType().isNull())
+        continue;
+
+      const auto *Ty = cast<FunctionProtoType>(MD->getType());
+      if (!Ty || !MD->isExplicitObjectMemberFunction() ||
+          !Ty->getParamType(0)->isDependentType())
+        continue;
+
+      if (auto *C = LSI->CaptureMap.count(D) ? &LSI->getCapture(D) : nullptr) {
+        if (C->isCopyCapture())
+          return true;
+        continue;
+      }
+
+      if (LSI->ImpCaptureStyle == LambdaScopeInfo::ImpCap_LambdaByval)
+        return true;
+    }
+    return false;
   }();
 
   ID->setCapturedByCopyInLambdaWithExplicitObjectParameter(
diff --git a/clang/lib/Sema/TreeTransform.h b/clang/lib/Sema/TreeTransform.h
index 7389a48fe56fcc..e537dfef767df8 100644
--- a/clang/lib/Sema/TreeTransform.h
+++ b/clang/lib/Sema/TreeTransform.h
@@ -11099,8 +11099,8 @@ TreeTransform<Derived>::TransformDeclRefExpr(DeclRefExpr *E) {
   }
 
   if (!getDerived().AlwaysRebuild() &&
-      QualifierLoc == E->getQualifierLoc() &&
-      ND == E->getDecl() &&
+      !E->isCapturedByCopyInLambdaWithExplicitObjectParameter() &&
+      QualifierLoc == E->getQualifierLoc() && ND == E->getDecl() &&
       Found == E->getFoundDecl() &&
       NameInfo.getName() == E->getDecl()->getDeclName() &&
       !E->hasExplicitTemplateArgs()) {
diff --git a/clang/test/SemaCXX/cxx2b-deducing-this.cpp b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
index b8ddb9ad300034..6c21954554d281 100644
--- a/clang/test/SemaCXX/cxx2b-deducing-this.cpp
+++ b/clang/test/SemaCXX/cxx2b-deducing-this.cpp
@@ -200,6 +200,87 @@ void TestMutationInLambda() {
     [i = 0](this auto){ i++; }();
     [i = 0](this const auto&){ i++; }();
     // expected-error@-1 {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+    // expected-note@-2 {{in instantiation of}}
+
+    int x;
+    const auto l1 = [x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+    const auto l2 = [=](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+
+    const auto l3 = [&x](this auto&) {
+        const auto l3a = [x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l3a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l4 = [&x](this auto&) {
+        const auto l4a = [=](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l4a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l5 = [x](this auto&) {
+        const auto l5a = [x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l5a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l6 = [=](this auto&) {
+        const auto l6a = [=](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l6a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l7 = [x](this auto&) {
+        const auto l7a = [=](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l7a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l8 = [=](this auto&) {
+        const auto l8a = [x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l8a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l9 = [&](this auto&) {
+        const auto l9a = [x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l9a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l10 = [&](this auto&) {
+        const auto l10a = [=](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}}
+        l10a(); // expected-note {{in instantiation of}}
+    };
+
+    const auto l11 = [x](this auto&) {
+        const auto l11a = [&x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}} expected-note {{while substituting}}
+        l11a();
+    };
+
+    const auto l12 = [x](this auto&) {
+        const auto l12a = [&](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}} expected-note {{while substituting}}
+        l12a();
+    };
+
+    const auto l13 = [=](this auto&) {
+        const auto l13a = [&x](this auto&) { x = 42; }; // expected-error {{cannot assign to a variable captured by copy in a non-mutable lambda}} expected-note {{while substituting}}
+        l13a();
+    };
+
+    l1(); // expected-note {{in instantiation of}}
+    l2(); // expected-note {{in instantiation of}}
+    l3(); // expected-note {{in instantiation of}}
+    l4(); // expected-note {{in instantiation of}}
+    l5(); // expected-note {{in instantiation of}}
+    l6(); // expected-note {{in instantiation of}}
+    l7(); // expected-note {{in instantiation of}}
+    l8(); // expected-note {{in instantiation of}}
+    l9(); // expected-note {{in instantiation of}}
+    l10(); // expected-note {{in instantiation of}}
+    l11(); // expected-note {{in instantiation of}}
+    l12(); // expected-note {{in instantiation of}}
+    l13(); // expected-note {{in instantiation of}}
+
+    {
+      const auto l1 = [&x](this auto&) { x = 42; };
+      const auto l2 = [&](this auto&) { x = 42; };
+      l1();
+      l2();
+    }
 }
 
 struct Over_Call_Func_Example {

Sirraide · 2024-03-08T14:36:04Z

Ok, looks like this is fixed now as well.

Sirraide · 2024-03-08T14:42:50Z

Also, just checked, #84425 apparently was a symptom of this as well, because that one’s also fixed now.

Link1J · 2024-03-23T15:23:53Z

Does this fix #86054, or is it a different bug?
It seems related to the other issues mentioned here.

Sirraide · 2024-03-23T15:25:09Z

Does this fix #86054, or is it a different bug? It seems related to the other issues mentioned here.

I’ll check.

Sirraide · 2024-03-23T15:48:10Z

@Link1J The issue you linked does seem to be another symptom of the underlying problem here, yeah. It’s also not technically a duplicate, so I’ve left it open and marked it as fixed by this pr.

Sirraide · 2024-03-26T13:59:15Z

@AaronBallman ping

erichkeane

This seems sensible to me. Please give @cor3ntin a few days to review, after which, feel free to commit.

Sirraide · 2024-04-09T12:37:49Z

It’s been about a week, so I’m going to merge this now.

jsji · 2024-04-11T19:20:55Z

https://godbolt.org/z/WTTKfG1ha Looks like this is causing some assert failures. @Sirraide
Thanks @jyu2-git for helping identifying the commit.

Sirraide · 2024-04-11T19:23:40Z

https://godbolt.org/z/WTTKfG1ha Looks like this is causing some assert failures. @Sirraide Thanks @jyu2-git for helping identifying the commit.

I think I might know what’s going on here: We probably have an AttributedType or some other form of sugar here; I’ll see if I can fix it and if it takes too long I’ll revert this and reapply it later.

Sirraide · 2024-04-11T19:37:51Z

Looks like that was the problem; I’ll open a pr to fix this.

Sirraide · 2024-04-11T19:46:31Z

#88428

jsji · 2024-04-11T20:17:08Z

Thank you @Sirraide for the quick fix.

) This fixes a bug introduced by #84473: if a lambda’s type is type sugar (e.g. an `AttributedType`), we need to use `getAs()` instead of `cast()` to retrieve the `FunctionProtoType`.

…ect parameter (llvm#84473) This fixes some problems wrt dependence of captures in lambdas with an explicit object parameter. [temp.dep.expr] states that > An id-expression is type-dependent if [...] its terminal name is > - associated by name lookup with an entity captured by copy > ([expr.prim.lambda.capture]) in a lambda-expression that has > an explicit object parameter whose type is dependent [dcl.fct]. There were several issues with our implementation of this: 1. we were treating by-reference captures as dependent rather than by-value captures; 2. tree transform wasn't checking whether referring to such a by-value capture should make a DRE dependent; 3. when checking whether a DRE refers to such a by-value capture, we were only looking at the immediately enclosing lambda, and not at any parent lambdas; 4. we also forgot to check for implicit by-value captures; 5. lastly, we were attempting to determine whether a lambda has an explicit object parameter by checking the `LambdaScopeInfo`'s `ExplicitObjectParameter`, but it seems that that simply wasn't set (yet) by the time we got to the check. All of these should be fixed now. This fixes llvm#70604, llvm#79754, llvm#84163, llvm#84425, llvm#86054, llvm#86398, and llvm#86399.

…m#88428) This fixes a bug introduced by llvm#84473: if a lambda’s type is type sugar (e.g. an `AttributedType`), we need to use `getAs()` instead of `cast()` to retrieve the `FunctionProtoType`.

…ect parameter (llvm#84473) This fixes some problems wrt dependence of captures in lambdas with an explicit object parameter. [temp.dep.expr] states that > An id-expression is type-dependent if [...] its terminal name is > - associated by name lookup with an entity captured by copy > ([expr.prim.lambda.capture]) in a lambda-expression that has > an explicit object parameter whose type is dependent [dcl.fct]. There were several issues with our implementation of this: 1. we were treating by-reference captures as dependent rather than by-value captures; 2. tree transform wasn't checking whether referring to such a by-value capture should make a DRE dependent; 3. when checking whether a DRE refers to such a by-value capture, we were only looking at the immediately enclosing lambda, and not at any parent lambdas; 4. we also forgot to check for implicit by-value captures; 5. lastly, we were attempting to determine whether a lambda has an explicit object parameter by checking the `LambdaScopeInfo`'s `ExplicitObjectParameter`, but it seems that that simply wasn't set (yet) by the time we got to the check. All of these should be fixed now. This fixes llvm#70604, llvm#79754, llvm#84163, llvm#84425, llvm#86054, llvm#86398, and llvm#86399.

…m#88428) This fixes a bug introduced by llvm#84473: if a lambda’s type is type sugar (e.g. an `AttributedType`), we need to use `getAs()` instead of `cast()` to retrieve the `FunctionProtoType`.

…ect parameter (llvm#84473) This fixes some problems wrt dependence of captures in lambdas with an explicit object parameter. [temp.dep.expr] states that > An id-expression is type-dependent if [...] its terminal name is > - associated by name lookup with an entity captured by copy > ([expr.prim.lambda.capture]) in a lambda-expression that has > an explicit object parameter whose type is dependent [dcl.fct]. There were several issues with our implementation of this: 1. we were treating by-reference captures as dependent rather than by-value captures; 2. tree transform wasn't checking whether referring to such a by-value capture should make a DRE dependent; 3. when checking whether a DRE refers to such a by-value capture, we were only looking at the immediately enclosing lambda, and not at any parent lambdas; 4. we also forgot to check for implicit by-value captures; 5. lastly, we were attempting to determine whether a lambda has an explicit object parameter by checking the `LambdaScopeInfo`'s `ExplicitObjectParameter`, but it seems that that simply wasn't set (yet) by the time we got to the check. All of these should be fixed now. This fixes llvm#70604, llvm#79754, llvm#84163, llvm#84425, llvm#86054, llvm#86398, and llvm#86399.

…m#88428) This fixes a bug introduced by llvm#84473: if a lambda’s type is type sugar (e.g. an `AttributedType`), we need to use `getAs()` instead of `cast()` to retrieve the `FunctionProtoType`.

Sirraide added 2 commits March 8, 2024 11:56

[Clang] Fix dependence of DREs in lambdas with an explicit object par…

870e6a6

…ameter

[Clang] Better dependence check for DREs in TreeTransform

bf4c193

Sirraide added clang:frontend Language frontend issues, e.g. anything involving "Sema" c++23 labels Mar 8, 2024

Sirraide requested review from cor3ntin, AaronBallman and erichkeane March 8, 2024 12:55

llvmbot added the clang Clang issues not falling into any other category label Mar 8, 2024

Sirraide marked this pull request as draft March 8, 2024 12:55

[Clang] Fix dependence of this in explicit object lambdas

2812fd9

Sirraide marked this pull request as ready for review March 8, 2024 14:34

llvmbot added the clang:modules C++20 modules and Clang Header Modules label Mar 8, 2024

[Clang] Add release note

0a03b5f

Sirraide linked an issue Mar 8, 2024 that may be closed by this pull request

ICE inside nested lambdas, with reference captures, when the inner lambda is recursive using c++23s deducing this #84425

Closed

[Clang] Add tests for issue llvm#84425

eeae945

Sirraide changed the title ~~[Clang] [Sema] WIP: Fix dependence of DREs in lambdas with an explicit object parameter~~ [Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter Mar 8, 2024

[Clang] Add test for llvm#86054

60917a0

Sirraide linked an issue Mar 23, 2024 that may be closed by this pull request

[Clang] Crash when using deducing this and references in lambda captures #86054

Closed

Sirraide mentioned this pull request Mar 23, 2024

[Clang] Deducing this Lambda ignores assignment rules for captured references #86398

Closed

[Clang] Add test for llvm#86398

957dd9a

Sirraide linked an issue Mar 23, 2024 that may be closed by this pull request

[Clang] Deducing this Lambda ignores assignment rules for captured references #86398

Closed

Sirraide mentioned this pull request Mar 23, 2024

[Clang] Deducing this Lambda does not generate all the needed function calls #86399

Closed

Sirraide linked an issue Mar 23, 2024 that may be closed by this pull request

[Clang] Deducing this Lambda does not generate all the needed function calls #86399

Closed

[Clang] Add test for llvm#86399

f5964b9

Sirraide linked an issue Mar 23, 2024 that may be closed by this pull request

ICE when returning the captured reference in the deducing this lambda #79754

Closed

[Clang] Add test for llvm#79754

858cc50

Sirraide mentioned this pull request Mar 23, 2024

Deducing this lambda causes crash when using explicit reference capture #70604

Closed

Sirraide linked an issue Mar 23, 2024 that may be closed by this pull request

Deducing this lambda causes crash when using explicit reference capture #70604

Closed

[Clang] Add test for llvm#70604

5e3a72c

Sirraide mentioned this pull request Apr 1, 2024

[Clang] Crash when taking the address of a capture in a lambda with an explicit object parameter in overload pattern #87210

Closed

Sirraide linked an issue Apr 1, 2024 that may be closed by this pull request

[Clang] Crash when taking the address of a capture in a lambda with an explicit object parameter in overload pattern #87210

Closed

Sirraide removed a link to an issue Apr 1, 2024

[Clang] Crash when taking the address of a capture in a lambda with an explicit object parameter in overload pattern #87210

Closed

erichkeane approved these changes Apr 1, 2024

View reviewed changes

Merge branch 'main' into dependent-captures

b967f4a

Sirraide merged commit 38824f2 into llvm:main Apr 9, 2024

Sirraide mentioned this pull request Apr 11, 2024

[Clang] Look through type sugar when accessing FunctionProtoType #88428

Merged

Sirraide mentioned this pull request Apr 23, 2024

Crash with reference captures in inherited lambda with explicit parameters #89541

Closed

Sirraide deleted the dependent-captures branch April 23, 2024 18:12

erikolofsson mentioned this pull request May 11, 2024

Clang-18 CRASHING on VALID recursive lambda code #87861

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter #84473

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter #84473

Uh oh!

Sirraide commented Mar 8, 2024 •

edited

Loading

Uh oh!

llvmbot commented Mar 8, 2024 •

edited

Loading

Uh oh!

Sirraide commented Mar 8, 2024

Uh oh!

Sirraide commented Mar 8, 2024

Uh oh!

Link1J commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 26, 2024

Uh oh!

erichkeane left a comment

Uh oh!

Sirraide commented Apr 9, 2024 •

edited

Loading

Uh oh!

jsji commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

jsji commented Apr 11, 2024

Uh oh!

Uh oh!

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter #84473

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter #84473

Uh oh!

Conversation

Sirraide commented Mar 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Mar 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sirraide commented Mar 8, 2024

Uh oh!

Sirraide commented Mar 8, 2024

Uh oh!

Link1J commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 23, 2024

Uh oh!

Sirraide commented Mar 26, 2024

Uh oh!

erichkeane left a comment

Choose a reason for hiding this comment

Uh oh!

Sirraide commented Apr 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jsji commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

Sirraide commented Apr 11, 2024

Uh oh!

jsji commented Apr 11, 2024

Uh oh!

Uh oh!

Sirraide commented Mar 8, 2024 •

edited

Loading

llvmbot commented Mar 8, 2024 •

edited

Loading

Sirraide commented Apr 9, 2024 •

edited

Loading