[all-commits] [llvm/llvm-project] 3733b0: [Clang] Fix a DeclContext mismatch when parsing ne...

[Younan Zhang via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3733b0cff314e1427b1a905e6e7438b536f9a96d
      https://github.com/llvm/llvm-project/commit/3733b0cff314e1427b1a905e6e7438b536f9a96d
  Author: Younan Zhang <zyn7109 at gmail.com>
  Date:   2024-10-15 (Tue, 15 Oct 2024)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/lib/Sema/SemaExpr.cpp
    M clang/lib/Sema/SemaExprCXX.cpp
    M clang/test/SemaCXX/lambda-capture-type-deduction.cpp

  Log Message:
  -----------
  [Clang] Fix a DeclContext mismatch when parsing nested lambda parameters (#112177)

When parsing its function parameters, we don't change the CurContext to
the lambda's function declaration. However,
CheckIfAnyEnclosingLambdasMustCaptureAnyPotentialCaptures() has not
yet adapted to such behavior when nested lambdas come into play.
Consider the following case,

    struct Foo {};

    template <int, Foo f> struct Arr {};

    constexpr void foo() {
      constexpr Foo F;
      [&]<int I>() {
         [&](Arr<I, F>) {};
       }.template operator()<42>();
    }

As per [basic.def.odr]p5.2, the use of F constitutes an ODR-use. And
per [basic.def.odr]p10, F should be ODR-usable in that interleaving
scope.

We failed to accept the case because the call to tryCaptureVariable()
in getStackIndexOfNearestEnclosingCaptureCapableLambda() suggested
that F is needlessly captureable. That was due to a missed handling
for AfterParameterList in FunctionScopeIndexToStopAt, where it still
presumed DC and LSI matched.

Fixes #47400
Fixes #90896



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications