[Bug 273753] [exp-run] Against llvm-17-update branch on GitHub

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 07 Jan 2024 17:51:09 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273753

--- Comment #119 from commit-hook@FreeBSD.org ---
A commit in branch stable/14 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=fc0670dd3a4d9d7c7e564d1138f109660881519e

commit fc0670dd3a4d9d7c7e564d1138f109660881519e
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2023-12-07 12:47:54 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2024-01-07 17:46:19 +0000

    Merge commit 158f4f30adb4 from llvm git (by Corentin Jabot):

      [Clang] Do not change the type of captured vars when checking lambda
constraints

      When checking the constraint of a lambda, we need to respect the
constness
      of the call operator when establishing the type of capture variables.

      In D124351, this was done by adding const to the captured variable...
      However, that would change the type of the variable outside of the scope
      of the lambda, which is clearly not the desired outcome.

      Instead, to ensure const-correctness, we need to populate
      a LambdaScopeInfo with the capture variables before checking the
      constraints of a generic lambda.

      There is no changelog as I'd like to tentatively propose we backport
      this change to RC3 as it is a regression introduced in the Clang 17
      cycle.

      Fixes #61267

      Reviewed By: aaron.ballman, #clang-language-wg

      Differential Revision: https://reviews.llvm.org/D158433

    Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):

      [Clang] Add captures to the instantiation scope of lambda call operators

      Like concepts checking, a trailing return type of a lambda
      in a dependent context may refer to captures in which case
      they may need to be rebuilt, so the map of local decl
      should include captures.

      This patch reveal a pre-existing issue.
      `this` is always recomputed by TreeTransform.

      `*this` (like all captures) only become `const`
      after the parameter list.

      However, if try to recompute the value of `this` (in a parameter)
      during template instantiation while determining the type of the call
operator,
      we will determine  it to be const (unless the lambda is mutable).

      There is no good way to know at that point that we are in a parameter
      or not, the easiest/best solution is to transform the type of this.

      Note that doing so break a handful of HLSL tests.
      So this is a prototype at this point.

      Fixes #65067
      Fixes #63675

      Reviewed By: erichkeane

      Differential Revision: https://reviews.llvm.org/D159126

    This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
    instantiated in this scope"), function findInstantiationOf' error when
    building databases/mongodb44.

    PR:             273753
    MFC after:      1 month

    (cherry picked from commit feb5b0c76f9c7b510583b0489918300cbf966e0f)

 .../llvm-project/clang/include/clang/Sema/Sema.h   | 10 +++++++
 .../llvm-project/clang/lib/Sema/SemaConcept.cpp    | 29 ++++++--------------
 contrib/llvm-project/clang/lib/Sema/SemaDecl.cpp   | 16 +++++++----
 contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp   | 15 +++++-----
 contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp | 32 ++++++++++++++++++++++
 .../clang/lib/Sema/SemaTemplateInstantiateDecl.cpp |  3 ++
 .../llvm-project/clang/lib/Sema/TreeTransform.h    | 11 +++++++-
 7 files changed, 82 insertions(+), 34 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.