[clang] [llvm] BPF address space insn (PR #84410)

[Yingchi Long via cfe-commits]

@@ -0,0 +1,52 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 4
+; RUN: opt --bpf-check-and-opt-ir -S -mtriple=bpf-pc-linux < %s | FileCheck %s
+
+; Generated from the following C code:
+;
+;   extern int __uptr *magic1();
+;   extern int __uptr *magic2();
+;
+;   void test(long i) {
+; int __uptr *a;
+;
+; if (i > 42)
+;   a = magic1();
+; else
+;   a = magic2();
+; a[5] = 7;
+;   }
+;
+; Using the following command:
+;
+;   clang --target=bpf -O2 -S -emit-llvm -o t.ll t.c
+
+; Function Attrs: nounwind

inclyc wrote:

this function attrs looks outdated

https://github.com/llvm/llvm-project/pull/84410
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] BPF address space insn (PR #84410)

[Yingchi Long via cfe-commits]

@@ -638,6 +643,31 @@ SDValue BPFTargetLowering::LowerDYNAMIC_STACKALLOC(SDValue 
Op,
   return DAG.getMergeValues(Ops, SDLoc());
 }
 
+SDValue BPFTargetLowering::LowerADDRSPACECAST(SDValue Op,
+  SelectionDAG &DAG) const {
+  auto *ACast = dyn_cast(Op);
+  const SDValue &Ptr = ACast->getOperand(0);
+  unsigned SrcAS = ACast->getSrcAddressSpace();
+  unsigned DstAS = ACast->getDestAddressSpace();
+  SDLoc DL(Op);
+
+  if (SrcAS > 0 && DstAS > 0) {
+SmallString<64> Msg;
+raw_svector_ostream OS(Msg);
+OS << "Can't cast address space " << SrcAS << " to " << DstAS
+   << ": either source or destination address space has to be zero";
+fail(DL, DAG, Msg);

inclyc wrote:

Our `fail` method is used for `DiagnosticInfoUnsupported` diagnostic, should we 
create a new diagnostic kind?

https://github.com/llvm/llvm-project/pull/84410
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] BPF address space insn (PR #84410)

[Yingchi Long via cfe-commits]

@@ -0,0 +1,92 @@
+//=== BPFIRPeephole.cpp - IR Peephole Transformation 
--===//

inclyc wrote:

nit

https://github.com/llvm/llvm-project/pull/84410
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] BPF address space insn (PR #84410)

[Yingchi Long via cfe-commits]

@@ -31,6 +31,9 @@ def SDT_BPFMEMCPY   : SDTypeProfile<0, 4, [SDTCisVT<0, 
i64>,
SDTCisVT<1, i64>,
SDTCisVT<2, i64>,
SDTCisVT<3, i64>]>;
+def SDT_BPFAddrSpaceCast : SDTypeProfile<0, 3, [SDTCisPtrTy<0>,

inclyc wrote:

(question) Why not just use the common "addrspacecast" ISD node?

https://github.com/llvm/llvm-project/pull/84410
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Fix Hungarian Prefix in readability-identifier-naming (PR #84236)

[Piotr Zegar via cfe-commits]

@@ -229,7 +229,8 @@ Changes in existing checks
 
 - Improved :doc:`readability-identifier-naming
   ` check in 
`GetConfigPerFile`
-  mode by resolving symbolic links to header files.
+  mode by resolving symbolic links to header files. Fixed handling of Hungarian

PiotrZSL wrote:

It's not documented, just an "idea". Release notes in Clang-tidy 17 were a 
little bit unreadable, so in Calng-tidy 18 I push a little bit to unify them: 
https://releases.llvm.org/18.1.0/tools/clang/tools/extra/docs/ReleaseNotes.html

https://github.com/llvm/llvm-project/pull/84236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Wang Pengcheng via cfe-commits]

https://github.com/wangpc-pp updated 
https://github.com/llvm/llvm-project/pull/76357

>From a54f47f8055e898b6452183663863f6df01e98e1 Mon Sep 17 00:00:00 2001
From: wangpc 
Date: Mon, 25 Dec 2023 18:52:36 +0800
Subject: [PATCH 1/2] [RFC][RISCV] Support RISC-V Profiles in -march option

This PR implements the draft
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/36.

Currently, we replace specified profile in `-march` with standard
arch string.
---
 clang/test/Driver/riscv-profiles.c   | 324 +++
 llvm/include/llvm/Support/RISCVISAInfo.h |   2 +
 llvm/lib/Support/RISCVISAInfo.cpp|  76 ++
 llvm/lib/Target/RISCV/RISCV.td   |   6 +
 llvm/lib/Target/RISCV/RISCVProfiles.td   | 189 +
 llvm/lib/Target/RISCV/RISCVSubtarget.h   |  19 ++
 llvm/test/CodeGen/RISCV/attributes.ll|  25 ++
 7 files changed, 641 insertions(+)
 create mode 100644 clang/test/Driver/riscv-profiles.c
 create mode 100644 llvm/lib/Target/RISCV/RISCVProfiles.td

diff --git a/clang/test/Driver/riscv-profiles.c 
b/clang/test/Driver/riscv-profiles.c
new file mode 100644
index 00..8d1a7faf607838
--- /dev/null
+++ b/clang/test/Driver/riscv-profiles.c
@@ -0,0 +1,324 @@
+// RUN: %clang -### -c %s 2>&1 -march=rvi20u32 | FileCheck 
-check-prefix=RVI20U32 %s
+// RVI20U32: "-target-feature" "-a"
+// RVI20U32: "-target-feature" "-c"
+// RVI20U32: "-target-feature" "-d"
+// RVI20U32: "-target-feature" "-f"
+// RVI20U32: "-target-feature" "-m"
+// RVI20U32: "-target-feature" "+rvi20u32"
+
+// RUN: %clang -### -c %s 2>&1 -march=rvi20u64 | FileCheck 
-check-prefix=RVI20U64 %s
+// RVI20U64: "-target-feature" "-a"
+// RVI20U64: "-target-feature" "-c"
+// RVI20U64: "-target-feature" "-d"
+// RVI20U64: "-target-feature" "-f"
+// RVI20U64: "-target-feature" "-m"
+// RVI20U64: "-target-feature" "+rvi20u64"
+
+// RUN: %clang -### -c %s 2>&1 -march=rva20u64 | FileCheck 
-check-prefix=RVA20U64 %s
+// RVA20U64: "-target-feature" "+m"
+// RVA20U64: "-target-feature" "+a"
+// RVA20U64: "-target-feature" "+f"
+// RVA20U64: "-target-feature" "+d"
+// RVA20U64: "-target-feature" "+c"
+// RVA20U64: "-target-feature" "+ziccamoa"
+// RVA20U64: "-target-feature" "+ziccif"
+// RVA20U64: "-target-feature" "+zicclsm"
+// RVA20U64: "-target-feature" "+ziccrse"
+// RVA20U64: "-target-feature" "+zicntr"
+// RVA20U64: "-target-feature" "+zicsr"
+// RVA20U64: "-target-feature" "+za128rs"
+// RVA20U64: "-target-feature" "+rva20u64"
+
+// RUN: %clang -### -c %s 2>&1 -march=rva20s64 | FileCheck 
-check-prefix=RVA20S64 %s
+// RVA20S64: "-target-feature" "+m"
+// RVA20S64: "-target-feature" "+a"
+// RVA20S64: "-target-feature" "+f"
+// RVA20S64: "-target-feature" "+d"
+// RVA20S64: "-target-feature" "+c"
+// RVA20S64: "-target-feature" "+ziccamoa"
+// RVA20S64: "-target-feature" "+ziccif"
+// RVA20S64: "-target-feature" "+zicclsm"
+// RVA20S64: "-target-feature" "+ziccrse"
+// RVA20S64: "-target-feature" "+zicntr"
+// RVA20S64: "-target-feature" "+zicsr"
+// RVA20S64: "-target-feature" "+zifencei"
+// RVA20S64: "-target-feature" "+za128rs"
+// RVA20S64: "-target-feature" "+ssccptr"
+// RVA20S64: "-target-feature" "+sstvala"
+// RVA20S64: "-target-feature" "+sstvecd"
+// RVA20S64: "-target-feature" "+svade"
+// RVA20S64: "-target-feature" "+svbare"
+// RVA20S64: "-target-feature" "+rva20s64"
+
+// RUN: %clang -### -c %s 2>&1 -march=rva22u64 | FileCheck 
-check-prefix=RVA22U64 %s
+// RVA22U64: "-target-feature" "+m"
+// RVA22U64: "-target-feature" "+a"
+// RVA22U64: "-target-feature" "+f"
+// RVA22U64: "-target-feature" "+d"
+// RVA22U64: "-target-feature" "+c"
+// RVA22U64: "-target-feature" "+zic64b"
+// RVA22U64: "-target-feature" "+zicbom"
+// RVA22U64: "-target-feature" "+zicbop"
+// RVA22U64: "-target-feature" "+zicboz"
+// RVA22U64: "-target-feature" "+ziccamoa"
+// RVA22U64: "-target-feature" "+ziccif"
+// RVA22U64: "-target-feature" "+zicclsm"
+// RVA22U64: "-target-feature" "+ziccrse"
+// RVA22U64: "-target-feature" "+zicntr"
+// RVA22U64: "-target-feature" "+zicsr"
+// RVA22U64: "-target-feature" "+zihintpause"
+// RVA22U64: "-target-feature" "+zihpm"
+// RVA22U64: "-target-feature" "+za64rs"
+// RVA22U64: "-target-feature" "+zfhmin"
+// RVA22U64: "-target-feature" "+zba"
+// RVA22U64: "-target-feature" "+zbb"
+// RVA22U64: "-target-feature" "+zbs"
+// RVA22U64: "-target-feature" "+zkt"
+// RVA22U64: "-target-feature" "+rva22u64"
+
+// RUN: %clang -### -c %s 2>&1 -march=rva22s64 | FileCheck 
-check-prefix=RVA22S64 %s
+// RVA22S64: "-target-feature" "+m"
+// RVA22S64: "-target-feature" "+a"
+// RVA22S64: "-target-feature" "+f"
+// RVA22S64: "-target-feature" "+d"
+// RVA22S64: "-target-feature" "+c"
+// RVA22S64: "-target-feature" "+zic64b"
+// RVA22S64: "-target-feature" "+zicbom"
+// RVA22S64: "-target-feature" "+zicbop"
+// RVA22S64: "-target-feature" "+zicboz"
+// RVA22S64: "-target-feature" "+ziccamoa"
+// RVA22S64: "-target-feature" "+ziccif"
+// RVA22S64: "-target-feature" "+zicclsm"
+// RVA

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[Balazs Benics via cfe-commits]

https://github.com/steakhal created 
https://github.com/llvm/llvm-project/pull/84446

Note that this patch will be necessary to fix `forEachArgumentWithParam()` and 
`forEachArgumentWithParamType()` matchers for deducing "this"; which is my true 
motivation.

>From 9ffc1b9ec60a9638c5b07cb25574ddb2420b77a2 Mon Sep 17 00:00:00 2001
From: Balazs Benics 
Date: Thu, 7 Mar 2024 19:23:48 +0100
Subject: [PATCH] [clang][ASTMatcher] Add matchers for
 isExplicitObjectMemberFunction()

---
 clang/docs/LibASTMatchersReference.html   | 15 +++
 clang/docs/ReleaseNotes.rst   |  1 +
 clang/include/clang/ASTMatchers/ASTMatchers.h | 19 +++
 clang/include/clang/Testing/CommandLineArgs.h |  1 +
 clang/include/clang/Testing/TestClangConfig.h | 16 +++-
 clang/lib/ASTMatchers/Dynamic/Registry.cpp|  1 +
 clang/lib/Testing/CommandLineArgs.cpp |  7 +++
 .../ASTMatchers/ASTMatchersNarrowingTest.cpp  | 14 ++
 .../ASTMatchers/ASTMatchersNodeTest.cpp   |  2 +-
 clang/unittests/ASTMatchers/ASTMatchersTest.h | 14 ++
 10 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/clang/docs/LibASTMatchersReference.html 
b/clang/docs/LibASTMatchersReference.html
index 8a06084955aa6b..bb1b68f6671b1a 100644
--- a/clang/docs/LibASTMatchersReference.html
+++ b/clang/docs/LibASTMatchersReference.html
@@ -3546,6 +3546,21 @@ Narrowing Matchers
 
 
 
+MatcherCXXMethodDecl>isExplicitObjectMemberFunction
+Matches if the given method 
declaration declares a member function with an explicit object parameter.
+
+Given
+struct A {
+  int operator-(this A, int);
+  void fun(this A &&self);
+  static int operator()(int);
+  int operator+(int);
+};
+
+cxxMethodDecl(isExplicitObjectMemberFunction()) matches the first two methods 
but not the last two.
+
+
+
 MatcherCXXMethodDecl>isCopyAssignmentOperator
 Matches if 
the given method declaration declares a copy assignment
 operator.
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 942820a5268576..898380f94b7956 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -415,6 +415,7 @@ AST Matchers
 
 
 - ``isInStdNamespace`` now supports Decl declared with ``extern "C++"``.
+- Add ``isExplicitObjectMemberFunction``.
 
 clang-format
 
diff --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index ced89ff127ab3e..96dbcdc344e131 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -6366,6 +6366,25 @@ AST_MATCHER(CXXMethodDecl, isConst) {
   return Node.isConst();
 }
 
+/// Matches if the given method declaration declares a member function with an
+/// explicit object parameter.
+///
+/// Given
+/// \code
+/// struct A {
+///  int operator-(this A, int);
+///  void fun(this A &&self);
+///  static int operator()(int);
+///  int operator+(int);
+/// };
+/// \endcode
+///
+/// cxxMethodDecl(isExplicitObjectMemberFunction()) matches the first two
+/// methods but not the last two.
+AST_MATCHER(CXXMethodDecl, isExplicitObjectMemberFunction) {
+  return Node.isExplicitObjectMemberFunction();
+}
+
 /// Matches if the given method declaration declares a copy assignment
 /// operator.
 ///
diff --git a/clang/include/clang/Testing/CommandLineArgs.h 
b/clang/include/clang/Testing/CommandLineArgs.h
index 4dd28718dfa67c..e71907e8bbd0c6 100644
--- a/clang/include/clang/Testing/CommandLineArgs.h
+++ b/clang/include/clang/Testing/CommandLineArgs.h
@@ -28,6 +28,7 @@ enum TestLanguage {
   Lang_CXX14,
   Lang_CXX17,
   Lang_CXX20,
+  Lang_CXX23,
   Lang_OpenCL,
   Lang_OBJC,
   Lang_OBJCXX
diff --git a/clang/include/clang/Testing/TestClangConfig.h 
b/clang/include/clang/Testing/TestClangConfig.h
index 92d5cc3cff994f..1b4efca80e9d47 100644
--- a/clang/include/clang/Testing/TestClangConfig.h
+++ b/clang/include/clang/Testing/TestClangConfig.h
@@ -34,24 +34,30 @@ struct TestClangConfig {
   bool isCXX() const {
 return Language == Lang_CXX03 || Language == Lang_CXX11 ||
Language == Lang_CXX14 || Language == Lang_CXX17 ||
-   Language == Lang_CXX20;
+   Language == Lang_CXX20 || Language == Lang_CXX23;
   }
 
   bool isCXX11OrLater() const {
 return Language == Lang_CXX11 || Language == Lang_CXX14 ||
-   Language == Lang_CXX17 || Language == Lang_CXX20;
+   Language == Lang_CXX17 || Language == Lang_CXX20 ||
+   Language == Lang_CXX23;
   }
 
   bool isCXX14OrLater() const {
 return Language == Lang_CXX14 || Language == Lang_CXX17 ||
-   Language == Lang_CXX20;
+   Language == Lang_CXX20 || Language == Lang_CXX23;
   }
 
   bool isCXX17OrLater() const {
-return Language == Lang_CXX17 || Language == Lang_CXX20;
+return Language ==

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Balazs Benics (steakhal)


Changes

Note that this patch will be necessary to fix `forEachArgumentWithParam()` and 
`forEachArgumentWithParamType()` matchers for deducing "this"; which is my true 
motivation.

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


10 Files Affected:

- (modified) clang/docs/LibASTMatchersReference.html (+15) 
- (modified) clang/docs/ReleaseNotes.rst (+1) 
- (modified) clang/include/clang/ASTMatchers/ASTMatchers.h (+19) 
- (modified) clang/include/clang/Testing/CommandLineArgs.h (+1) 
- (modified) clang/include/clang/Testing/TestClangConfig.h (+11-5) 
- (modified) clang/lib/ASTMatchers/Dynamic/Registry.cpp (+1) 
- (modified) clang/lib/Testing/CommandLineArgs.cpp (+7) 
- (modified) clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp (+14) 
- (modified) clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp (+1-1) 
- (modified) clang/unittests/ASTMatchers/ASTMatchersTest.h (+10-4) 


``diff
diff --git a/clang/docs/LibASTMatchersReference.html 
b/clang/docs/LibASTMatchersReference.html
index 8a06084955aa6b..bb1b68f6671b1a 100644
--- a/clang/docs/LibASTMatchersReference.html
+++ b/clang/docs/LibASTMatchersReference.html
@@ -3546,6 +3546,21 @@ Narrowing Matchers
 
 
 
+MatcherCXXMethodDecl>isExplicitObjectMemberFunction
+Matches if the given method 
declaration declares a member function with an explicit object parameter.
+
+Given
+struct A {
+  int operator-(this A, int);
+  void fun(this A &&self);
+  static int operator()(int);
+  int operator+(int);
+};
+
+cxxMethodDecl(isExplicitObjectMemberFunction()) matches the first two methods 
but not the last two.
+
+
+
 MatcherCXXMethodDecl>isCopyAssignmentOperator
 Matches if 
the given method declaration declares a copy assignment
 operator.
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 942820a5268576..898380f94b7956 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -415,6 +415,7 @@ AST Matchers
 
 
 - ``isInStdNamespace`` now supports Decl declared with ``extern "C++"``.
+- Add ``isExplicitObjectMemberFunction``.
 
 clang-format
 
diff --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index ced89ff127ab3e..96dbcdc344e131 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -6366,6 +6366,25 @@ AST_MATCHER(CXXMethodDecl, isConst) {
   return Node.isConst();
 }
 
+/// Matches if the given method declaration declares a member function with an
+/// explicit object parameter.
+///
+/// Given
+/// \code
+/// struct A {
+///  int operator-(this A, int);
+///  void fun(this A &&self);
+///  static int operator()(int);
+///  int operator+(int);
+/// };
+/// \endcode
+///
+/// cxxMethodDecl(isExplicitObjectMemberFunction()) matches the first two
+/// methods but not the last two.
+AST_MATCHER(CXXMethodDecl, isExplicitObjectMemberFunction) {
+  return Node.isExplicitObjectMemberFunction();
+}
+
 /// Matches if the given method declaration declares a copy assignment
 /// operator.
 ///
diff --git a/clang/include/clang/Testing/CommandLineArgs.h 
b/clang/include/clang/Testing/CommandLineArgs.h
index 4dd28718dfa67c..e71907e8bbd0c6 100644
--- a/clang/include/clang/Testing/CommandLineArgs.h
+++ b/clang/include/clang/Testing/CommandLineArgs.h
@@ -28,6 +28,7 @@ enum TestLanguage {
   Lang_CXX14,
   Lang_CXX17,
   Lang_CXX20,
+  Lang_CXX23,
   Lang_OpenCL,
   Lang_OBJC,
   Lang_OBJCXX
diff --git a/clang/include/clang/Testing/TestClangConfig.h 
b/clang/include/clang/Testing/TestClangConfig.h
index 92d5cc3cff994f..1b4efca80e9d47 100644
--- a/clang/include/clang/Testing/TestClangConfig.h
+++ b/clang/include/clang/Testing/TestClangConfig.h
@@ -34,24 +34,30 @@ struct TestClangConfig {
   bool isCXX() const {
 return Language == Lang_CXX03 || Language == Lang_CXX11 ||
Language == Lang_CXX14 || Language == Lang_CXX17 ||
-   Language == Lang_CXX20;
+   Language == Lang_CXX20 || Language == Lang_CXX23;
   }
 
   bool isCXX11OrLater() const {
 return Language == Lang_CXX11 || Language == Lang_CXX14 ||
-   Language == Lang_CXX17 || Language == Lang_CXX20;
+   Language == Lang_CXX17 || Language == Lang_CXX20 ||
+   Language == Lang_CXX23;
   }
 
   bool isCXX14OrLater() const {
 return Language == Lang_CXX14 || Language == Lang_CXX17 ||
-   Language == Lang_CXX20;
+   Language == Lang_CXX20 || Language == Lang_CXX23;
   }
 
   bool isCXX17OrLater() const {
-return Language == Lang_CXX17 || Language == Lang_CXX20;
+return Language == Lang_CXX17 || Language == Lang_CXX20 ||
+   Language == Lang_CXX23;
   }
 
-  bool isCXX20OrLater() const { return Language == Lang_C

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Wang Pengcheng via cfe-commits]

@@ -0,0 +1,189 @@
+//===-- RISCVProfiles.td - RISC-V Profiles -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+class RISCVProfile features>

wangpc-pp wrote:

Would it be nice if we needn't add a long feature list to `-mattr` with 
`-mattr=+profile`? :-)

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[Balazs Benics via cfe-commits]

https://github.com/steakhal edited 
https://github.com/llvm/llvm-project/pull/84446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Wang Pengcheng via cfe-commits]

@@ -138,6 +150,8 @@ class RISCVSubtarget : public RISCVGenSubtargetInfo {
   /// initializeProperties().
   RISCVProcFamilyEnum getProcFamily() const { return RISCVProcFamily; }
 
+  RISCVProfileEnum getRISCVProfile() const { return RISCVProfile; }

wangpc-pp wrote:

It depends on whether we need to know profile info in backend.
Currently we needn't, but I think it can be useful.

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Craig Topper via cfe-commits]

@@ -0,0 +1,189 @@
+//===-- RISCVProfiles.td - RISC-V Profiles -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+class RISCVProfile features>

topperc wrote:

Where are we using long lists in mattr? Tests should only add what they need.

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 851ab41 - [clang][test] Fix constant __builtin_popcountg test requiring __int128 (#84412)

[via cfe-commits]

Author: OverMighty
Date: 2024-03-08T09:50:21+01:00
New Revision: 851ab41d33fcbc72bc334dfc2d5d4c0902ccbb23

URL: 
https://github.com/llvm/llvm-project/commit/851ab41d33fcbc72bc334dfc2d5d4c0902ccbb23
DIFF: 
https://github.com/llvm/llvm-project/commit/851ab41d33fcbc72bc334dfc2d5d4c0902ccbb23.diff

LOG: [clang][test] Fix constant __builtin_popcountg test requiring __int128 
(#84412)

See
https://lab.llvm.org/buildbot/#/builders/245/builds/21611/steps/5/logs/FAIL__Clang__constant-builtins-2_c.

Added: 


Modified: 
clang/test/Sema/constant-builtins-2.c

Removed: 




diff  --git a/clang/test/Sema/constant-builtins-2.c 
b/clang/test/Sema/constant-builtins-2.c
index 0935abe4c65fbe..6dd1d88759c751 100644
--- a/clang/test/Sema/constant-builtins-2.c
+++ b/clang/test/Sema/constant-builtins-2.c
@@ -242,7 +242,9 @@ char popcount12[__builtin_popcountg(0xF0F0U) == 8 ? 1 : -1];
 char popcount13[__builtin_popcountg(~0U) == BITSIZE(int) ? 1 : -1];
 char popcount14[__builtin_popcountg(~0UL) == BITSIZE(long) ? 1 : -1];
 char popcount15[__builtin_popcountg(~0ULL) == BITSIZE(long long) ? 1 : -1];
+#ifdef __SIZEOF_INT128__
 char popcount16[__builtin_popcountg(~(unsigned __int128)0) == 
BITSIZE(__int128) ? 1 : -1];
+#endif
 char popcount17[__builtin_popcountg(~(unsigned _BitInt(128))0) == 
BITSIZE(_BitInt(128)) ? 1 : -1];
 
 char parity1[__builtin_parity(0) == 0 ? 1 : -1];



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][test] Fix constant __builtin_popcountg test requiring __int128 (PR #84412)

[Timm Baeder via cfe-commits]

https://github.com/tbaederr closed 
https://github.com/llvm/llvm-project/pull/84412
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Error on explicit specialization of lambda call operator (PR #84343)

[Mariya Podchishchaeva via cfe-commits]

https://github.com/Fznamznon closed 
https://github.com/llvm/llvm-project/pull/84343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] dd36138 - [clang] Error on explicit specialization of lambda call operator (#84343)

[via cfe-commits]

Author: Mariya Podchishchaeva
Date: 2024-03-08T09:52:42+01:00
New Revision: dd36138e9c23c462ce5379a3d83530fb4ebec9e7

URL: 
https://github.com/llvm/llvm-project/commit/dd36138e9c23c462ce5379a3d83530fb4ebec9e7
DIFF: 
https://github.com/llvm/llvm-project/commit/dd36138e9c23c462ce5379a3d83530fb4ebec9e7.diff

LOG: [clang] Error on explicit specialization of lambda call operator (#84343)

Fixes https://github.com/llvm/llvm-project/issues/83267

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaCXX/lambda-expressions.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index fe7bbe437831ed..225ca85e18115d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -250,6 +250,10 @@ Bug Fixes in This Version
   for variables created through copy initialization having side-effects in 
C++17 and later.
   Fixes (#GH64356) (#GH79518).
 
+- Clang now emits errors for explicit specializations/instatiations of lambda 
call
+  operator.
+  Fixes (#GH83267).
+
 Bug Fixes to Compiler Builtins
 ^^
 

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c8dfdc08f5ea07..a80c8b75e863ed 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8170,6 +8170,8 @@ let CategoryName = "Lambda Issue" in {
   def warn_cxx11_compat_generic_lambda : Warning<
 "generic lambdas are incompatible with C++11">,
 InGroup, DefaultIgnore;
+  def err_lambda_explicit_spec : Error<
+"lambda call operator should not be explicitly specialized or 
instantiated">;
 
   // C++17 '*this' captures.
   def warn_cxx14_compat_star_this_lambda_capture : Warning<

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 67e56a917a51de..910d0dfbf9f65f 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -15795,10 +15795,19 @@ Decl *Sema::ActOnStartOfFunctionDef(Scope 
*FnBodyScope, Decl *D,
   // captures during transformation of nested lambdas, it is necessary to
   // have the LSI properly restored.
   if (isGenericLambdaCallOperatorSpecialization(FD)) {
-assert(inTemplateInstantiation() &&
-   "There should be an active template instantiation on the stack "
-   "when instantiating a generic lambda!");
-RebuildLambdaScopeInfo(cast(D));
+// C++2c 7.5.5.2p17 A member of a closure type shall not be explicitly
+// instantiated, explicitly specialized.
+if (FD->getTemplateSpecializationInfo()
+->isExplicitInstantiationOrSpecialization()) {
+  Diag(FD->getLocation(), diag::err_lambda_explicit_spec);
+  FD->setInvalidDecl();
+  PushFunctionScope();
+} else {
+  assert(inTemplateInstantiation() &&
+ "There should be an active template instantiation on the stack "
+ "when instantiating a generic lambda!");
+  RebuildLambdaScopeInfo(cast(D));
+}
   } else {
 // Enter a new function scope
 PushFunctionScope();
@@ -16317,9 +16326,8 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
 }
   }
 
-  assert(
-  (FD == getCurFunctionDecl() || getCurLambda()->CallOperator == FD) &&
-  "Function parsing confused");
+  assert((FD == getCurFunctionDecl(/*AllowLambdas=*/true)) &&
+ "Function parsing confused");
 } else if (ObjCMethodDecl *MD = dyn_cast_or_null(dcl)) {
   assert(MD == getCurMethodDecl() && "Method parsing confused");
   MD->setBody(Body);

diff  --git a/clang/test/SemaCXX/lambda-expressions.cpp 
b/clang/test/SemaCXX/lambda-expressions.cpp
index 41cf5a46c38922..0516a5da31ae9a 100644
--- a/clang/test/SemaCXX/lambda-expressions.cpp
+++ b/clang/test/SemaCXX/lambda-expressions.cpp
@@ -732,3 +732,18 @@ void GH67492() {
   constexpr auto test = 42;
   auto lambda = (test, []() noexcept(true) {});
 }
+
+namespace GH83267 {
+auto l = [](auto a) { return 1; };
+using type = decltype(l);
+
+template<>
+auto type::operator()(int a) const { // expected-error{{lambda call operator 
should not be explicitly specialized or instantiated}}
+  return c; // expected-error {{use of undeclared identifier 'c'}}
+}
+
+auto ll = [](auto a) { return 1; }; // expected-error{{lambda call operator 
should not be explicitly specialized or instantiated}}
+using t = decltype(ll);
+template auto t::operator()(int a) const; // expected-note {{in 
instantiation}}
+
+}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Craig Topper via cfe-commits]

@@ -138,6 +150,8 @@ class RISCVSubtarget : public RISCVGenSubtargetInfo {
   /// initializeProperties().
   RISCVProcFamilyEnum getProcFamily() const { return RISCVProcFamily; }
 
+  RISCVProfileEnum getRISCVProfile() const { return RISCVProfile; }

topperc wrote:

If we use the profile in the backend wouldn't that mean the profile gets 
different treatment than the equivalent list of extensions?

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement CTAD for type alias template. (PR #77890)

[Haojian Wu via cfe-commits]

hokein wrote:

> > Thank you for all the reviews, I will wait 1 or 2 days before merging it in 
> > case anyone has more comments.
> 
> Sure! Do you plan to keep working on completing this feature?

Yeah, I plan to complete this feature before the next clang release. If anyone 
is willing to help, that would be even greater.

BTW, should we close https://github.com/llvm/llvm-project/issues/54051 with 
this PR? or should we keep it open until the feature is fully implemented? The 
`is_deducible` part is a major missing piece, I think we can close #54051 and 
open a separate issue to track the missing piece, WDYT?


https://github.com/llvm/llvm-project/pull/77890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 881df55 - [clang] Fix -Wunused-variable in SemaChecking.cpp (NFC)

[Jie Fu via cfe-commits]

Author: Jie Fu
Date: 2024-03-08T17:03:51+08:00
New Revision: 881df557501d339c7a14b16d68e43da5c732b424

URL: 
https://github.com/llvm/llvm-project/commit/881df557501d339c7a14b16d68e43da5c732b424
DIFF: 
https://github.com/llvm/llvm-project/commit/881df557501d339c7a14b16d68e43da5c732b424.diff

LOG: [clang] Fix -Wunused-variable in SemaChecking.cpp (NFC)

llvm-project/clang/lib/Sema/SemaChecking.cpp:19192:15:
error: unused variable 'Field1Parent' [-Werror,-Wunused-variable]
  const Type *Field1Parent = Field1->getParent()->getTypeForDecl();
  ^
llvm-project/clang/lib/Sema/SemaChecking.cpp:19193:15:
error: unused variable 'Field2Parent' [-Werror,-Wunused-variable]
  const Type *Field2Parent = Field2->getParent()->getTypeForDecl();
  ^
2 errors generated.

Added: 


Modified: 
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index b34b8df0020137..a5f42b630c3fa2 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19189,8 +19189,10 @@ static bool isLayoutCompatible(ASTContext &C, EnumDecl 
*ED1, EnumDecl *ED2) {
 static bool isLayoutCompatible(ASTContext &C, FieldDecl *Field1,
FieldDecl *Field2,
bool AreUnionMembers = false) {
-  const Type *Field1Parent = Field1->getParent()->getTypeForDecl();
-  const Type *Field2Parent = Field2->getParent()->getTypeForDecl();
+  [[maybe_unused]] const Type *Field1Parent =
+  Field1->getParent()->getTypeForDecl();
+  [[maybe_unused]] const Type *Field2Parent =
+  Field2->getParent()->getTypeForDecl();
   assert(((Field1Parent->isStructureOrClassType() &&
Field2Parent->isStructureOrClassType()) ||
   (Field1Parent->isUnionType() && Field2Parent->isUnionType())) &&



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86] Finally handle target of __builtin_ia32_cmp[p|s][s|d] from avx into sse/sse2/avx (PR #84136)

[Phoebe Wang via cfe-commits]

https://github.com/phoebewang approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/84136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86] Finally handle target of __builtin_ia32_cmp[p|s][s|d] from avx into sse/sse2/avx (PR #84136)

[Shengchen Kan via cfe-commits]

https://github.com/KanRobert approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/84136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers][X86] Add rounding and exception notes to conversions (PR #83447)

[Phoebe Wang via cfe-commits]

@@ -1405,11 +1413,12 @@ static __inline__ __m128d __DEFAULT_FN_ATTRS 
_mm_cvtss_sd(__m128d __a,
 
 /// Converts the two double-precision floating-point elements of a
 ///128-bit vector of [2 x double] into two signed 32-bit integer values,
-///returned in the lower 64 bits of a 128-bit vector of [4 x i32].
+///returned in the lower 64 bits of a 128-bit vector of [4 x i32],
+///truncating inexact results.

phoebewang wrote:

The last sentence is not necessary and has ambiguity in truncating the 
fractional part or truncating higher bits to 32-bit.

https://github.com/llvm/llvm-project/pull/83447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

[Wang Pengcheng via cfe-commits]

@@ -0,0 +1,189 @@
+//===-- RISCVProfiles.td - RISC-V Profiles -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+class RISCVProfile features>

wangpc-pp wrote:

There are some scenarios I think it can be useful:
* When adding new `RISCVProcessorModel`, we can just specify profile feature 
and those implemented optional extensions.
* When disassembling some object files, we don't need a long `-mattr` if we 
know it's compiled with a profile.
* When doing some end-to-end tests that we need to discard CPU specific 
features (so we can't use `-mcpu`), we don't need a long `-mattr`.

Above are my usages in reality.

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (PR #83842)

[via cfe-commits]

bgra8 wrote:

@sdkrystian we, at google, bisected lots (~1k) of clang crashes to this 
revision. Looks to me Facebook code is also impacted.

We need some time to provide a repro. Until then can you please revert?

https://github.com/llvm/llvm-project/pull/83842
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] Model more getline/getdelim pre and postconditions (PR #83027)

[Balázs Kéri via cfe-commits]

balazske wrote:

Additionally, the checked preconditions look not exact. For example the POSIX 
documentation for `getdelim` says: "If *n is non-zero, the application shall 
ensure that *lineptr either points to an object of size at least *n bytes, or 
is a null pointer." This means `*lineptr` can be NULL when `*n` is a nonzero 
value. The buffer size of `*lineptr` could be checked that is at least `*n` (if 
`*lineptr` is not NULL).

https://github.com/llvm/llvm-project/pull/83027
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

[Axel Lundberg via cfe-commits]

Zonotora wrote:

@zygoloid @AaronBallman any updates?

https://github.com/llvm/llvm-project/pull/75481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers][X86] Add specific results to comparisons (PR #83316)

[Simon Pilgrim via cfe-commits]

RKSimon wrote:

> @RKSimon note this will affect what the tooltips show. Is that okay?

I think so - we're just losing the extra info about -1/0 or 1/0 result values?

https://github.com/llvm/llvm-project/pull/83316
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[Piotr Zegar via cfe-commits]

https://github.com/PiotrZSL approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/84446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement CTAD for type alias template. (PR #77890)

[via cfe-commits]

cor3ntin wrote:

> BTW, should we close #54051 with this PR? or should we keep it open until the 
> feature is fully implemented? The `is_deducible` part is a major missing 
> piece, I think we can close #54051 and open a separate issue to track the 
> missing piece, WDYT?

Sounds good

https://github.com/llvm/llvm-project/pull/77890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[Balazs Benics via cfe-commits]

steakhal wrote:

Thanks for the prompt review @PiotrZSL!
I plan to merge it by the end of the day, unless someone objects.

https://github.com/llvm/llvm-project/pull/84446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [Sema] No longer diagnose type definitions in `offsetof` in C23 mode (PR #84169)

[via cfe-commits]

Sirraide wrote:

> Should we verify that we diagnose the case where the definition includes a 
> comma?

It’s UB if the type contains a comma (unless I’m somehow looking at the wrong C 
standard again...), so I don’t think we need to diagnose it.

https://github.com/llvm/llvm-project/pull/84169
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/82310

>From f340fb3dd66e436566d5a65da0a35d77a6a0bde6 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/4] The lambda call inside of a type alias

---
 clang/docs/ReleaseNotes.rst   |  2 +
 clang/include/clang/AST/DeclCXX.h |  4 +
 clang/include/clang/Sema/Sema.h   |  8 ++
 clang/lib/Frontend/FrontendActions.cpp|  2 +
 clang/lib/Sema/SemaConcept.cpp| 15 ++--
 clang/lib/Sema/SemaTemplate.cpp   |  9 +-
 clang/lib/Sema/SemaTemplateInstantiate.cpp| 64 ++-
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  5 ++
 clang/lib/Sema/TreeTransform.h|  9 ++
 .../alias-template-with-lambdas.cpp   | 82 +++
 10 files changed, 186 insertions(+), 14 deletions(-)
 create mode 100644 clang/test/SemaTemplate/alias-template-with-lambdas.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1b901a27fd19d1..bfe00cb6b21ee6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -329,6 +329,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Clang now supports direct lambda calls inside of a type alias template 
declarations.
+  This addresses (#GH70601), (#GH76674), (#GH79555), (#GH81145) and so on.
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 9cebaff63bb0db..7aed4d5cbc002e 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1869,6 +1869,10 @@ class CXXRecordDecl : public RecordDecl {
 DL.MethodTyInfo = TS;
   }
 
+  void setLambdaDependencyKind(unsigned Kind) {
+getLambdaData().DependencyKind = Kind;
+  }
+
   void setLambdaIsGeneric(bool IsGeneric) {
 assert(DefinitionData && DefinitionData->IsLambda &&
"setting lambda property of non-lambda class");
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..c6c40b1811442d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10131,6 +10131,8 @@ class Sema final {
 
   /// We are building deduction guides for a class.
   BuildingDeductionGuides,
+
+  TypeAliasTemplateInstantiation,
 } Kind;
 
 /// Was the enclosing context a non-instantiation SFINAE context?
@@ -10220,6 +10222,12 @@ class Sema final {
   FunctionDecl *Entity, ExceptionSpecification,
   SourceRange InstantiationRange = SourceRange());
 
+/// Note that we are instantiating a type alias template declaration.
+InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
+  TypeAliasTemplateDecl *Template,
+  ArrayRef TemplateArgs,
+  SourceRange InstantiationRange = SourceRange());
+
 /// Note that we are instantiating a default argument in a
 /// template-id.
 InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
diff --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index b9ed5dedfa4223..43d6e2230fb129 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -426,6 +426,8 @@ class DefaultTemplateInstCallback : public 
TemplateInstantiationCallback {
   return "BuildingBuiltinDumpStructCall";
 case CodeSynthesisContext::BuildingDeductionGuides:
   return "BuildingDeductionGuides";
+case Sema::CodeSynthesisContext::TypeAliasTemplateInstantiation:
+  return "TypeAliasTemplateInstantiation";
 }
 return "";
   }
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..5cc6236c3991b6 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -614,14 +614,13 @@ bool Sema::SetupConstraintScope(
 // reference the original primary template.
 // We walk up the instantiated template chain so that nested lambdas get
 // handled properly.
-for (FunctionTemplateDecl *FromMemTempl =
- PrimaryTemplate->getInstantiatedFromMemberTemplate();
- FromMemTempl;
- FromMemTempl = FromMemTempl->getInstantiatedFromMemberTemplate()) {
-  if (addInstantiatedParametersToScope(FD, 
FromMemTempl->getTemplatedDecl(),
-   Scope, MLTAL))
-return true;
-}
+FunctionTemplateDecl *FromMemTempl =
+PrimaryTemplate->getInstantiatedFromMemberTemplate();
+while (FromMemTempl && FromMemTempl->getInstantiatedFromMemberTemplate())
+  FromMemTempl = FromMemTemp

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/82310

>From f340fb3dd66e436566d5a65da0a35d77a6a0bde6 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/5] The lambda call inside of a type alias

---
 clang/docs/ReleaseNotes.rst   |  2 +
 clang/include/clang/AST/DeclCXX.h |  4 +
 clang/include/clang/Sema/Sema.h   |  8 ++
 clang/lib/Frontend/FrontendActions.cpp|  2 +
 clang/lib/Sema/SemaConcept.cpp| 15 ++--
 clang/lib/Sema/SemaTemplate.cpp   |  9 +-
 clang/lib/Sema/SemaTemplateInstantiate.cpp| 64 ++-
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  5 ++
 clang/lib/Sema/TreeTransform.h|  9 ++
 .../alias-template-with-lambdas.cpp   | 82 +++
 10 files changed, 186 insertions(+), 14 deletions(-)
 create mode 100644 clang/test/SemaTemplate/alias-template-with-lambdas.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1b901a27fd19d1..bfe00cb6b21ee6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -329,6 +329,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Clang now supports direct lambda calls inside of a type alias template 
declarations.
+  This addresses (#GH70601), (#GH76674), (#GH79555), (#GH81145) and so on.
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 9cebaff63bb0db..7aed4d5cbc002e 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1869,6 +1869,10 @@ class CXXRecordDecl : public RecordDecl {
 DL.MethodTyInfo = TS;
   }
 
+  void setLambdaDependencyKind(unsigned Kind) {
+getLambdaData().DependencyKind = Kind;
+  }
+
   void setLambdaIsGeneric(bool IsGeneric) {
 assert(DefinitionData && DefinitionData->IsLambda &&
"setting lambda property of non-lambda class");
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..c6c40b1811442d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10131,6 +10131,8 @@ class Sema final {
 
   /// We are building deduction guides for a class.
   BuildingDeductionGuides,
+
+  TypeAliasTemplateInstantiation,
 } Kind;
 
 /// Was the enclosing context a non-instantiation SFINAE context?
@@ -10220,6 +10222,12 @@ class Sema final {
   FunctionDecl *Entity, ExceptionSpecification,
   SourceRange InstantiationRange = SourceRange());
 
+/// Note that we are instantiating a type alias template declaration.
+InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
+  TypeAliasTemplateDecl *Template,
+  ArrayRef TemplateArgs,
+  SourceRange InstantiationRange = SourceRange());
+
 /// Note that we are instantiating a default argument in a
 /// template-id.
 InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
diff --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index b9ed5dedfa4223..43d6e2230fb129 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -426,6 +426,8 @@ class DefaultTemplateInstCallback : public 
TemplateInstantiationCallback {
   return "BuildingBuiltinDumpStructCall";
 case CodeSynthesisContext::BuildingDeductionGuides:
   return "BuildingDeductionGuides";
+case Sema::CodeSynthesisContext::TypeAliasTemplateInstantiation:
+  return "TypeAliasTemplateInstantiation";
 }
 return "";
   }
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..5cc6236c3991b6 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -614,14 +614,13 @@ bool Sema::SetupConstraintScope(
 // reference the original primary template.
 // We walk up the instantiated template chain so that nested lambdas get
 // handled properly.
-for (FunctionTemplateDecl *FromMemTempl =
- PrimaryTemplate->getInstantiatedFromMemberTemplate();
- FromMemTempl;
- FromMemTempl = FromMemTempl->getInstantiatedFromMemberTemplate()) {
-  if (addInstantiatedParametersToScope(FD, 
FromMemTempl->getTemplatedDecl(),
-   Scope, MLTAL))
-return true;
-}
+FunctionTemplateDecl *FromMemTempl =
+PrimaryTemplate->getInstantiatedFromMemberTemplate();
+while (FromMemTempl && FromMemTempl->getInstantiatedFromMemberTemplate())
+  FromMemTempl = FromMemTemp

[clang] [flang] [flang][draft] Improve debug info generation. (PR #84202)

[via cfe-commits]

jeanPerier wrote:

Great to see work on debug info, thanks!

I am in line with @tblah that we should aim at generating it from FIR/HLFIR as 
much as possible. For types, as Tom mentioned,  fir.type_info could be updated 
to be created with the type declaration location if it is not already the case.

Variable names that are meant to be reversible (there are [APIs to 
demangle](https://github.com/llvm/llvm-project/blob/d36d805373c27103edf13164260ef679efd30dc1/flang/include/flang/Optimizer/Support/InternalNames.h#L135)),
 so it would seems reasonable to me to start by using this for to identify 
Module variables.

+1 for a design doc/RFC on the topic.

https://github.com/llvm/llvm-project/pull/84202
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] Model more getline/getdelim pre and postconditions (PR #83027)

[Alejandro Álvarez Ayllón via cfe-commits]

alejandro-alvarez-sonarsource wrote:

> : "If *n is non-zero, the application shall ensure that *lineptr either 
> points to an object of size at least *n bytes, or is a null pointer."

Ah! I was following at the 2008 version, and there "[...], or is a null 
pointer." is missing. I will update accordingly. I wonder, though, if the 
pointer is NULL, would an undefined (as non-initialized) *n be acceptable?

https://github.com/llvm/llvm-project/pull/83027
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/82310

>From f340fb3dd66e436566d5a65da0a35d77a6a0bde6 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/6] The lambda call inside of a type alias

---
 clang/docs/ReleaseNotes.rst   |  2 +
 clang/include/clang/AST/DeclCXX.h |  4 +
 clang/include/clang/Sema/Sema.h   |  8 ++
 clang/lib/Frontend/FrontendActions.cpp|  2 +
 clang/lib/Sema/SemaConcept.cpp| 15 ++--
 clang/lib/Sema/SemaTemplate.cpp   |  9 +-
 clang/lib/Sema/SemaTemplateInstantiate.cpp| 64 ++-
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  5 ++
 clang/lib/Sema/TreeTransform.h|  9 ++
 .../alias-template-with-lambdas.cpp   | 82 +++
 10 files changed, 186 insertions(+), 14 deletions(-)
 create mode 100644 clang/test/SemaTemplate/alias-template-with-lambdas.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1b901a27fd19d1..bfe00cb6b21ee6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -329,6 +329,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Clang now supports direct lambda calls inside of a type alias template 
declarations.
+  This addresses (#GH70601), (#GH76674), (#GH79555), (#GH81145) and so on.
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 9cebaff63bb0db..7aed4d5cbc002e 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1869,6 +1869,10 @@ class CXXRecordDecl : public RecordDecl {
 DL.MethodTyInfo = TS;
   }
 
+  void setLambdaDependencyKind(unsigned Kind) {
+getLambdaData().DependencyKind = Kind;
+  }
+
   void setLambdaIsGeneric(bool IsGeneric) {
 assert(DefinitionData && DefinitionData->IsLambda &&
"setting lambda property of non-lambda class");
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..c6c40b1811442d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10131,6 +10131,8 @@ class Sema final {
 
   /// We are building deduction guides for a class.
   BuildingDeductionGuides,
+
+  TypeAliasTemplateInstantiation,
 } Kind;
 
 /// Was the enclosing context a non-instantiation SFINAE context?
@@ -10220,6 +10222,12 @@ class Sema final {
   FunctionDecl *Entity, ExceptionSpecification,
   SourceRange InstantiationRange = SourceRange());
 
+/// Note that we are instantiating a type alias template declaration.
+InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
+  TypeAliasTemplateDecl *Template,
+  ArrayRef TemplateArgs,
+  SourceRange InstantiationRange = SourceRange());
+
 /// Note that we are instantiating a default argument in a
 /// template-id.
 InstantiatingTemplate(Sema &SemaRef, SourceLocation PointOfInstantiation,
diff --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index b9ed5dedfa4223..43d6e2230fb129 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -426,6 +426,8 @@ class DefaultTemplateInstCallback : public 
TemplateInstantiationCallback {
   return "BuildingBuiltinDumpStructCall";
 case CodeSynthesisContext::BuildingDeductionGuides:
   return "BuildingDeductionGuides";
+case Sema::CodeSynthesisContext::TypeAliasTemplateInstantiation:
+  return "TypeAliasTemplateInstantiation";
 }
 return "";
   }
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..5cc6236c3991b6 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -614,14 +614,13 @@ bool Sema::SetupConstraintScope(
 // reference the original primary template.
 // We walk up the instantiated template chain so that nested lambdas get
 // handled properly.
-for (FunctionTemplateDecl *FromMemTempl =
- PrimaryTemplate->getInstantiatedFromMemberTemplate();
- FromMemTempl;
- FromMemTempl = FromMemTempl->getInstantiatedFromMemberTemplate()) {
-  if (addInstantiatedParametersToScope(FD, 
FromMemTempl->getTemplatedDecl(),
-   Scope, MLTAL))
-return true;
-}
+FunctionTemplateDecl *FromMemTempl =
+PrimaryTemplate->getInstantiatedFromMemberTemplate();
+while (FromMemTempl && FromMemTempl->getInstantiatedFromMemberTemplate())
+  FromMemTempl = FromMemTemp

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good to me.

https://github.com/llvm/llvm-project/pull/82310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Younan Zhang via cfe-commits]

zyn0217 wrote:

So, I have:
1. rebased the patch on top of the recent Sema refactors.
2. incorporated the fix for https://github.com/llvm/llvm-project/issues/82104, 
which is a slight change on `HandleFunction`.
3. separated the `CodeSynthesisContext` iteration logic into three helper 
functions i.e. `getPrimaryTemplateOfGenericLambda`, 
`getEnclosingTypeAliasTemplateDecl` and `isLambdaEnclosedByTypeAliasDecl` - I 
hope this looks clearer.
4. clarified some comments.

In terms of the lambda dependencies, I'm not entirely sure if we can accept the 
current approach. In practice, it is possible to avoid such a hack at the 
moment, since we don't actually rely on the lambda substitution but rather the 
template arguments.

Do you think it will be useful in the future that we need something more e.g. 
the substituted parameters, to compute the dependency? @cor3ntin 

https://github.com/llvm/llvm-project/pull/82310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check for a
+  /// lambda because 'this' is the lambda's 'this'-pointer.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool SkipLambdaCaptureCheck = false);

andreasfertig wrote:

Sounds good! Thanks!

https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

https://github.com/andreasfertig edited 
https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix the lambda call expression inside of a type alias declaration (PR #82310)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 edited 
https://github.com/llvm/llvm-project/pull/82310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)" (PR #84457)

[Krystian Stasiowski via cfe-commits]

https://github.com/sdkrystian created 
https://github.com/llvm/llvm-project/pull/84457

This reverts commit a642eb89bdaf10c6b4994fc1187de27b441236ed.

>From 02f98e180b94bec0c6abafeaaf8a7513f5116eab Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski 
Date: Fri, 8 Mar 2024 05:44:48 -0500
Subject: [PATCH] Revert "[Clang][Sema] Fix crash when using name of
 UnresolvedUsingValueDecl with template arguments (#83842)"

This reverts commit a642eb89bdaf10c6b4994fc1187de27b441236ed.
---
 clang/docs/ReleaseNotes.rst   |  2 --
 clang/lib/Sema/SemaDecl.cpp   |  5 +---
 clang/lib/Sema/SemaTemplate.cpp   | 10 +++
 .../unqual-unresolved-using-value.cpp | 30 ---
 4 files changed, 5 insertions(+), 42 deletions(-)
 delete mode 100644 clang/test/SemaTemplate/unqual-unresolved-using-value.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 225ca85e18115d..0ee2801766a9cc 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -332,8 +332,6 @@ Bug Fixes to C++ Support
   our attention by an attempt to fix in (#GH77703). Fixes (#GH83385).
 - Fix evaluation of some immediate calls in default arguments.
   Fixes (#GH80630)
-- Fix a crash when an explicit template argument list is used with a name for 
which lookup
-  finds a non-template function and a dependent using declarator.
 - Fixed an issue where the ``RequiresExprBody`` was involved in the lambda 
dependency
   calculation. (#GH56556), (#GH82849).
 - Fix a bug where overload resolution falsely reported an ambiguity when it 
was comparing
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 910d0dfbf9f65f..1f4a041e88dfff 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -1110,9 +1110,7 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
 //   unqualified-id followed by a < and name lookup finds either one
 //   or more functions or finds nothing.
 if (!IsFilteredTemplateName)
-  FilterAcceptableTemplateNames(Result,
-/*AllowFunctionTemplates=*/true,
-/*AllowDependent=*/true);
+  FilterAcceptableTemplateNames(Result);
 
 bool IsFunctionTemplate;
 bool IsVarTemplate;
@@ -1122,7 +1120,6 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
   Template = Context.getOverloadedTemplateName(Result.begin(),
Result.end());
 } else if (!Result.empty()) {
-  assert(!Result.isUnresolvableResult());
   auto *TD = cast(getAsTemplateNameDecl(
   *Result.begin(), /*AllowFunctionTemplates=*/true,
   /*AllowDependent=*/false));
diff --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 7e91815c2d52a8..83eee83aa6cad8 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -491,20 +491,18 @@ bool Sema::LookupTemplateName(LookupResult &Found,
 // To keep our behavior consistent, we apply the "finds nothing" part in
 // all language modes, and diagnose the empty lookup in ActOnCallExpr if we
 // successfully form a call to an undeclared template-id.
-bool AnyFunctions =
-getLangOpts().CPlusPlus20 && llvm::any_of(Found, [](NamedDecl *ND) {
+bool AllFunctions =
+getLangOpts().CPlusPlus20 && llvm::all_of(Found, [](NamedDecl *ND) {
   return isa(ND->getUnderlyingDecl());
 });
-if (AnyFunctions || (Found.empty() && !IsDependent)) {
+if (AllFunctions || (Found.empty() && !IsDependent)) {
   // If lookup found any functions, or if this is a name that can only be
   // used for a function, then strongly assume this is a function
   // template-id.
   *ATK = (Found.empty() && Found.getLookupName().isIdentifier())
  ? AssumedTemplateKind::FoundNothing
  : AssumedTemplateKind::FoundFunctions;
-  FilterAcceptableTemplateNames(Found,
-/*AllowFunctionTemplates*/ true,
-/*AllowDependent*/ true);
+  Found.clear();
   return false;
 }
   }
diff --git a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp 
b/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
deleted file mode 100644
index 688e7a0a10b779..00
--- a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
+++ /dev/null
@@ -1,30 +0,0 @@
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
-
-template
-struct A : T {
-  using T::f;
-  using T::g;
-  using T::h;
-
-  void f();
-  void g();
-
-  void i() {
-f();
-g(); // expected-error{{no member named 'g' in 'A'}}
-h(); // expected-error{{expected '(' for function-style cast or type 
construction}}
-  // expected-error@-1{{expected expression}}
-  }
-};
-
-struct B {
-  template
-  void f();
-
-  void g();

[clang] [clang][NFC] Refactor `clang/test/SemaCXX/type-traits.cpp` to use modern `static_assert` (PR #77584)

[Amirreza Ashouri via cfe-commits]

AMP999 wrote:

@cor3ntin All checks are green now. Could you help me land this patch for me?

https://github.com/llvm/llvm-project/pull/77584
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)" (PR #84457)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Krystian Stasiowski (sdkrystian)


Changes

This reverts commit a642eb89bdaf10c6b4994fc1187de27b441236ed.

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


4 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (-2) 
- (modified) clang/lib/Sema/SemaDecl.cpp (+1-4) 
- (modified) clang/lib/Sema/SemaTemplate.cpp (+4-6) 
- (removed) clang/test/SemaTemplate/unqual-unresolved-using-value.cpp (-30) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 225ca85e18115d..0ee2801766a9cc 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -332,8 +332,6 @@ Bug Fixes to C++ Support
   our attention by an attempt to fix in (#GH77703). Fixes (#GH83385).
 - Fix evaluation of some immediate calls in default arguments.
   Fixes (#GH80630)
-- Fix a crash when an explicit template argument list is used with a name for 
which lookup
-  finds a non-template function and a dependent using declarator.
 - Fixed an issue where the ``RequiresExprBody`` was involved in the lambda 
dependency
   calculation. (#GH56556), (#GH82849).
 - Fix a bug where overload resolution falsely reported an ambiguity when it 
was comparing
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 910d0dfbf9f65f..1f4a041e88dfff 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -1110,9 +1110,7 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
 //   unqualified-id followed by a < and name lookup finds either one
 //   or more functions or finds nothing.
 if (!IsFilteredTemplateName)
-  FilterAcceptableTemplateNames(Result,
-/*AllowFunctionTemplates=*/true,
-/*AllowDependent=*/true);
+  FilterAcceptableTemplateNames(Result);
 
 bool IsFunctionTemplate;
 bool IsVarTemplate;
@@ -1122,7 +1120,6 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
   Template = Context.getOverloadedTemplateName(Result.begin(),
Result.end());
 } else if (!Result.empty()) {
-  assert(!Result.isUnresolvableResult());
   auto *TD = cast(getAsTemplateNameDecl(
   *Result.begin(), /*AllowFunctionTemplates=*/true,
   /*AllowDependent=*/false));
diff --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 7e91815c2d52a8..83eee83aa6cad8 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -491,20 +491,18 @@ bool Sema::LookupTemplateName(LookupResult &Found,
 // To keep our behavior consistent, we apply the "finds nothing" part in
 // all language modes, and diagnose the empty lookup in ActOnCallExpr if we
 // successfully form a call to an undeclared template-id.
-bool AnyFunctions =
-getLangOpts().CPlusPlus20 && llvm::any_of(Found, [](NamedDecl *ND) {
+bool AllFunctions =
+getLangOpts().CPlusPlus20 && llvm::all_of(Found, [](NamedDecl *ND) {
   return isa(ND->getUnderlyingDecl());
 });
-if (AnyFunctions || (Found.empty() && !IsDependent)) {
+if (AllFunctions || (Found.empty() && !IsDependent)) {
   // If lookup found any functions, or if this is a name that can only be
   // used for a function, then strongly assume this is a function
   // template-id.
   *ATK = (Found.empty() && Found.getLookupName().isIdentifier())
  ? AssumedTemplateKind::FoundNothing
  : AssumedTemplateKind::FoundFunctions;
-  FilterAcceptableTemplateNames(Found,
-/*AllowFunctionTemplates*/ true,
-/*AllowDependent*/ true);
+  Found.clear();
   return false;
 }
   }
diff --git a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp 
b/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
deleted file mode 100644
index 688e7a0a10b779..00
--- a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
+++ /dev/null
@@ -1,30 +0,0 @@
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
-
-template
-struct A : T {
-  using T::f;
-  using T::g;
-  using T::h;
-
-  void f();
-  void g();
-
-  void i() {
-f();
-g(); // expected-error{{no member named 'g' in 'A'}}
-h(); // expected-error{{expected '(' for function-style cast or type 
construction}}
-  // expected-error@-1{{expected expression}}
-  }
-};
-
-struct B {
-  template
-  void f();
-
-  void g();
-
-  template
-  void h();
-};
-
-template struct A; // expected-note{{in instantiation of member function 
'A::i' requested here}}

``




https://github.com/llvm/llvm-project/pull/84457
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)" (PR #84457)

[Krystian Stasiowski via cfe-commits]

https://github.com/sdkrystian edited 
https://github.com/llvm/llvm-project/pull/84457
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)" (PR #84457)

[Krystian Stasiowski via cfe-commits]

https://github.com/sdkrystian closed 
https://github.com/llvm/llvm-project/pull/84457
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ee94bd2 - Revert "[Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (#83842)" (#84457)

[via cfe-commits]

Author: Krystian Stasiowski
Date: 2024-03-08T05:57:04-05:00
New Revision: ee94bd20ba09975de493675dd6a0b7fc7dd5cece

URL: 
https://github.com/llvm/llvm-project/commit/ee94bd20ba09975de493675dd6a0b7fc7dd5cece
DIFF: 
https://github.com/llvm/llvm-project/commit/ee94bd20ba09975de493675dd6a0b7fc7dd5cece.diff

LOG: Revert "[Clang][Sema] Fix crash when using name of 
UnresolvedUsingValueDecl with template arguments (#83842)" (#84457)

This reverts commit a642eb89bdaf10c6b4994fc1187de27b441236ed (see #83842)

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaTemplate.cpp

Removed: 
clang/test/SemaTemplate/unqual-unresolved-using-value.cpp



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 225ca85e18115d..0ee2801766a9cc 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -332,8 +332,6 @@ Bug Fixes to C++ Support
   our attention by an attempt to fix in (#GH77703). Fixes (#GH83385).
 - Fix evaluation of some immediate calls in default arguments.
   Fixes (#GH80630)
-- Fix a crash when an explicit template argument list is used with a name for 
which lookup
-  finds a non-template function and a dependent using declarator.
 - Fixed an issue where the ``RequiresExprBody`` was involved in the lambda 
dependency
   calculation. (#GH56556), (#GH82849).
 - Fix a bug where overload resolution falsely reported an ambiguity when it 
was comparing

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 910d0dfbf9f65f..1f4a041e88dfff 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -1110,9 +1110,7 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
 //   unqualified-id followed by a < and name lookup finds either one
 //   or more functions or finds nothing.
 if (!IsFilteredTemplateName)
-  FilterAcceptableTemplateNames(Result,
-/*AllowFunctionTemplates=*/true,
-/*AllowDependent=*/true);
+  FilterAcceptableTemplateNames(Result);
 
 bool IsFunctionTemplate;
 bool IsVarTemplate;
@@ -1122,7 +1120,6 @@ Sema::NameClassification Sema::ClassifyName(Scope *S, 
CXXScopeSpec &SS,
   Template = Context.getOverloadedTemplateName(Result.begin(),
Result.end());
 } else if (!Result.empty()) {
-  assert(!Result.isUnresolvableResult());
   auto *TD = cast(getAsTemplateNameDecl(
   *Result.begin(), /*AllowFunctionTemplates=*/true,
   /*AllowDependent=*/false));

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 7e91815c2d52a8..83eee83aa6cad8 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -491,20 +491,18 @@ bool Sema::LookupTemplateName(LookupResult &Found,
 // To keep our behavior consistent, we apply the "finds nothing" part in
 // all language modes, and diagnose the empty lookup in ActOnCallExpr if we
 // successfully form a call to an undeclared template-id.
-bool AnyFunctions =
-getLangOpts().CPlusPlus20 && llvm::any_of(Found, [](NamedDecl *ND) {
+bool AllFunctions =
+getLangOpts().CPlusPlus20 && llvm::all_of(Found, [](NamedDecl *ND) {
   return isa(ND->getUnderlyingDecl());
 });
-if (AnyFunctions || (Found.empty() && !IsDependent)) {
+if (AllFunctions || (Found.empty() && !IsDependent)) {
   // If lookup found any functions, or if this is a name that can only be
   // used for a function, then strongly assume this is a function
   // template-id.
   *ATK = (Found.empty() && Found.getLookupName().isIdentifier())
  ? AssumedTemplateKind::FoundNothing
  : AssumedTemplateKind::FoundFunctions;
-  FilterAcceptableTemplateNames(Found,
-/*AllowFunctionTemplates*/ true,
-/*AllowDependent*/ true);
+  Found.clear();
   return false;
 }
   }

diff  --git a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp 
b/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
deleted file mode 100644
index 688e7a0a10b779..00
--- a/clang/test/SemaTemplate/unqual-unresolved-using-value.cpp
+++ /dev/null
@@ -1,30 +0,0 @@
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
-
-template
-struct A : T {
-  using T::f;
-  using T::g;
-  using T::h;
-
-  void f();
-  void g();
-
-  void i() {
-f();
-g(); // expected-error{{no member named 'g' in 'A'}}
-h(); // expected-error{{expected '(' for function-style cast or type 
construction}}
-  // expected-error@-1{{expected expression}}
-  }
-};
-
-struct B {
-  template
-  void f();
-
-  void g();
-
-  template
-  void h();
-};
-
-template struct A; // expec

[clang] [clang][NFC] Refactor `clang/test/SemaCXX/type-traits.cpp` to use modern `static_assert` (PR #77584)

[via cfe-commits]

https://github.com/cor3ntin closed 
https://github.com/llvm/llvm-project/pull/77584
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

[Nikita Popov via cfe-commits]

nikic wrote:

> Have you thought about the implications for dynamic (non-constant) indices?

inrange is only supported on constant expressions, and I think the consensus is 
that it should not be extended to non-constant cases. In that case, we would 
represent the information independently of the GEP using an intrinsic instead.

(Technically a constant expression GEP can also have a dynamic index, but that 
case is not practically relevant.)

> Stuff like
> 
> ```
>   %gep = getelementptr [50 x {i32, [10 x i32]}], ptr %base, i32 0, i32 
> %outer_idx, i32 1, i32 %inner_idx
> ```
> 
> The current representation allows an `inrange` on the second-to-last index 
> which to my understanding restricts the range to the `[10 x i32]` into which 
> `%gep` falls structurally.
> 
> It seems like neither proposed representation is able to capture that in a 
> single `ptradd` (it could be captured with a sequence of two `ptradd`s, but 
> that's an awkward tradeoff).
>
> The first proposed representation at least allows handling the case when 
> there is only a single dynamic index, and the `inrange` is to the right of it.

ptradd wouldn't support multi-index GEPs anyway, so the representation would be 
something like
```
%p1 = ptradd ptr %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 4
%p3 = ptradd ptr %p2, i32 %inner_idx * 4
```
if we support scaling inside ptradd (or separate multiply/shift instructions 
otherwise). Where `%p1` likely gets LICMed and/or CSEd.

If we did support inrange on non-constant ptradd then we would encode the 
constraints that it's inrange of the inner array as
```
; relative to source
%p2 = ptradd ptr inrange(4, 44) %p1, i32 4
; relative to result
%p2 = ptradd ptr inrange(0, 40) %p1, i32 4
```

Though if we consider a variant where we don't have that extra constant ptradd 
(i.e. drop the struct with the `i32` element):
```
%p1 = ptradd ptr %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 %inner_idx * 4
```
And then want to restrict inrange to the inner array, then for the 
source-relative case we can write:
```
%p1 = ptradd ptr %base, i32 %outer_idx * 44
%p2 = ptradd ptr inrange(0, 40) %p1, i32 %inner_idx * 4
```
While the result-relative case can't represent this without a dummy ptradd 0.

> (I guess this is an extension to @aeubanks' point. It feels like `inrange` 
> _should_ be useful for things like alias analysis. But I guess it's not used 
> for that at the moment.)

If we supported inrange on instruction GEP, then yes, it would be useful for AA.



https://github.com/llvm/llvm-project/pull/84341
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when using name of UnresolvedUsingValueDecl with template arguments (PR #83842)

[Krystian Stasiowski via cfe-commits]

sdkrystian wrote:

@bgra8 Reverted. Any sort of repro would be appreciated :)

https://github.com/llvm/llvm-project/pull/83842
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

https://github.com/andreasfertig updated 
https://github.com/llvm/llvm-project/pull/84193

>From 680c99b2d832a5fad617f632df4a750f9c6f1cae Mon Sep 17 00:00:00 2001
From: Andreas Fertig 
Date: Wed, 6 Mar 2024 14:20:00 +0100
Subject: [PATCH] [C++20][Coroutines] Lambda-coroutine with operator new in
 promise_type

Fix #84064

According to http://eel.is/c++draft/dcl.fct.def.coroutine#9 the first
parameter for overload resolution of `operator new` is `size_t` followed
by the arguments of the coroutine function.
http://eel.is/c++draft/dcl.fct.def.coroutine#4 states that the first argument
is the lvalue of `*this` if the coroutine is a member function.

Before this patch, Clang handled class types correctly but ignored lambdas.
This patch adds support for lambda coroutines with a `promise_type` that
implements a custom `operator new`.

The patch does consider C++23 `static operator()`, which already worked as
there is no `this` parameter.
---
 clang/include/clang/Sema/Sema.h  | 12 -
 clang/lib/Sema/SemaCoroutine.cpp | 18 +++-
 clang/lib/Sema/SemaExprCXX.cpp   | 16 +--
 clang/test/SemaCXX/gh84064-1.cpp | 79 
 clang/test/SemaCXX/gh84064-2.cpp | 53 +
 5 files changed, 169 insertions(+), 9 deletions(-)
 create mode 100644 clang/test/SemaCXX/gh84064-1.cpp
 create mode 100644 clang/test/SemaCXX/gh84064-2.cpp

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..8b4c18140a89e6 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -6752,10 +6752,18 @@ class Sema final {
 SourceLocation RParenLoc);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
+  /// lambda because 'this' refers to the closure object.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool ThisRefersToClosureObject = false);
 
   /// Build a CXXThisExpr and mark it referenced in the current context.
-  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit);
+  ///
+  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
+  /// lambda because 'this' refers to the closure object.
+  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit,
+ bool ThisRefersToClosureObject = false);
   void MarkThisReferenced(CXXThisExpr *This);
 
   /// Try to retrieve the type of the 'this' pointer.
diff --git a/clang/lib/Sema/SemaCoroutine.cpp b/clang/lib/Sema/SemaCoroutine.cpp
index a969b9383563b2..301a5ff72a3b2a 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -25,6 +25,7 @@
 #include "clang/Sema/Initialization.h"
 #include "clang/Sema/Overload.h"
 #include "clang/Sema/ScopeInfo.h"
+#include "clang/Sema/Sema.h"
 #include "clang/Sema/SemaInternal.h"
 #include "llvm/ADT/SmallSet.h"
 
@@ -1378,8 +1379,21 @@ bool CoroutineStmtBuilder::makeReturnOnAllocFailure() {
 static bool collectPlacementArgs(Sema &S, FunctionDecl &FD, SourceLocation Loc,
  SmallVectorImpl &PlacementArgs) {
   if (auto *MD = dyn_cast(&FD)) {
-if (MD->isImplicitObjectMemberFunction() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+if (MD->isImplicitObjectMemberFunction()) {
+  ExprResult ThisExpr{};
+
+  if (isLambdaCallOperator(MD) && !MD->isStatic()) {
+Qualifiers ThisQuals = MD->getMethodQualifiers();
+CXXRecordDecl *Record = MD->getParent();
+
+Sema::CXXThisScopeRAII ThisScope(S, Record, ThisQuals,
+ Record != nullptr);
+
+ThisExpr = S.ActOnCXXThis(Loc, /*ThisRefersToClosureObject=*/true);
+  } else {
+ThisExpr = S.ActOnCXXThis(Loc);
+  }
+
   if (ThisExpr.isInvalid())
 return false;
   ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index c34a40fa7c81ac..88e3d9ced044cb 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -1414,7 +1414,8 @@ bool Sema::CheckCXXThisCapture(SourceLocation Loc, const 
bool Explicit,
   return false;
 }
 
-ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
+ExprResult Sema::ActOnCXXThis(SourceLocation Loc,
+  bool ThisRefersToClosureObject) {
   /// C++ 9.3.2: In the body of a non-static member function, the keyword this
   /// is a non-lvalue expression whose value is the address of the object for
   /// which the function is called.
@@ -1434,13 +1435,18 @@ ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
 return Diag(Loc, diag::err_invalid_this_use) << 0;
   }
 
-  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false);
+  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false

[clang] [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (PR #84459)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 created 
https://github.com/llvm/llvm-project/pull/84459

We don't modify the MLTAL parameter in `SetupConstraintScope`, and it is better 
if we don't copy the 120-byte object each time we call the function.

>From 6d51233690d0030e3191198c1a7a330be723b1af Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Fri, 8 Mar 2024 18:40:27 +0800
Subject: [PATCH] [Sema] Avoid unnecessary copy on
 MultiLevelTemplateArgumentList. NFC

We don't modify the MLTAL parameter in SetupConstraintScope, and it
is better if we don't copy the 120-byte object each time we call the
function.
---
 clang/include/clang/Sema/Sema.h | 10 ++
 clang/lib/Sema/SemaConcept.cpp  |  3 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..2cac7e6ca08fad 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -11607,12 +11607,14 @@ class Sema final {
   LocalInstantiationScope &Scope,
   const MultiLevelTemplateArgumentList &TemplateArgs);
 
-  /// used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
+  /// Used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
   /// the case of lambdas) set up the LocalInstantiationScope of the current
   /// function.
-  bool SetupConstraintScope(
-  FunctionDecl *FD, std::optional> TemplateArgs,
-  MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope);
+  bool
+  SetupConstraintScope(FunctionDecl *FD,
+   std::optional> TemplateArgs,
+   const MultiLevelTemplateArgumentList &MLTAL,
+   LocalInstantiationScope &Scope);
 
   /// Used during constraint checking, sets up the constraint template argument
   /// lists, and calls SetupConstraintScope to set up the
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..a8e387e35fb4c9 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -586,7 +586,8 @@ bool Sema::addInstantiatedCapturesToScope(
 
 bool Sema::SetupConstraintScope(
 FunctionDecl *FD, std::optional> TemplateArgs,
-MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope) {
+const MultiLevelTemplateArgumentList &MLTAL,
+LocalInstantiationScope &Scope) {
   if (FD->isTemplateInstantiation() && FD->getPrimaryTemplate()) {
 FunctionTemplateDecl *PrimaryTemplate = FD->getPrimaryTemplate();
 InstantiatingTemplate Inst(

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (PR #84459)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Younan Zhang (zyn0217)


Changes

We don't modify the MLTAL parameter in `SetupConstraintScope`, and it is better 
if we don't copy the 120-byte object each time we call the function.

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


2 Files Affected:

- (modified) clang/include/clang/Sema/Sema.h (+6-4) 
- (modified) clang/lib/Sema/SemaConcept.cpp (+2-1) 


``diff
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..2cac7e6ca08fad 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -11607,12 +11607,14 @@ class Sema final {
   LocalInstantiationScope &Scope,
   const MultiLevelTemplateArgumentList &TemplateArgs);
 
-  /// used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
+  /// Used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
   /// the case of lambdas) set up the LocalInstantiationScope of the current
   /// function.
-  bool SetupConstraintScope(
-  FunctionDecl *FD, std::optional> TemplateArgs,
-  MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope);
+  bool
+  SetupConstraintScope(FunctionDecl *FD,
+   std::optional> TemplateArgs,
+   const MultiLevelTemplateArgumentList &MLTAL,
+   LocalInstantiationScope &Scope);
 
   /// Used during constraint checking, sets up the constraint template argument
   /// lists, and calls SetupConstraintScope to set up the
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..a8e387e35fb4c9 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -586,7 +586,8 @@ bool Sema::addInstantiatedCapturesToScope(
 
 bool Sema::SetupConstraintScope(
 FunctionDecl *FD, std::optional> TemplateArgs,
-MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope) {
+const MultiLevelTemplateArgumentList &MLTAL,
+LocalInstantiationScope &Scope) {
   if (FD->isTemplateInstantiation() && FD->getPrimaryTemplate()) {
 FunctionTemplateDecl *PrimaryTemplate = FD->getPrimaryTemplate();
 InstantiatingTemplate Inst(

``




https://github.com/llvm/llvm-project/pull/84459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

[Nikita Popov via cfe-commits]

nikic wrote:

> And then want to restrict inrange to the inner array, then for the 
> source-relative case we can write:
> 
> ```
> %p1 = ptradd ptr %base, i32 %outer_idx * 44
> %p2 = ptradd ptr inrange(0, 40) %p1, i32 %inner_idx * 4
> ```
>
> While the result-relative case can't represent this without a dummy ptradd 0.

Hm no, the result-relative case can obviously also represent this, just need to 
move it to the first one:
```
%p1 = ptradd ptr inrange(0, 40) %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 %inner_idx * 4
```

In a sense this is more natural because the restriction is logically introduced 
by the first ptradd, not by the second one.


https://github.com/llvm/llvm-project/pull/84341
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

@@ -1378,8 +1379,21 @@ bool CoroutineStmtBuilder::makeReturnOnAllocFailure() {
 static bool collectPlacementArgs(Sema &S, FunctionDecl &FD, SourceLocation Loc,
  SmallVectorImpl &PlacementArgs) {
   if (auto *MD = dyn_cast(&FD)) {
-if (MD->isImplicitObjectMemberFunction() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+if (MD->isImplicitObjectMemberFunction()) {
+  ExprResult ThisExpr{};
+
+  if (isLambdaCallOperator(MD) && !MD->isStatic()) {
+Qualifiers ThisQuals = MD->getMethodQualifiers();
+CXXRecordDecl *Record = MD->getParent();
+
+Sema::CXXThisScopeRAII ThisScope(S, Record, ThisQuals,
+ Record != nullptr);
+
+ThisExpr = S.ActOnCXXThis(Loc, /*SkipLambdaCaptureCheck*/ true);

andreasfertig wrote:

Updated and using `ThisRefersToClosureObject` suggested by @cor3ntin.

https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (PR #84459)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

Changes to `Sema.h` look good to me.

https://github.com/llvm/llvm-project/pull/84459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Expose CreateExecutor() and ResetExecutor() in extended Interpreter interface (PR #84460)

[Stefan Gränitz via cfe-commits]

https://github.com/weliveindetail created 
https://github.com/llvm/llvm-project/pull/84460

IncrementalExecutor is an implementation detail of the Interpreter. In order to 
test extended features properly, we must be able to setup and tear down the 
executor manually.

From 10f8d3eb040a5838d84d8a84fe636c7c2a7d196b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?= 
Date: Fri, 8 Mar 2024 00:08:56 +0100
Subject: [PATCH 1/2] [clang-repl] Expose RuntimeInterfaceBuilder for
 customizations

---
 clang/include/clang/Interpreter/Interpreter.h |  35 ++-
 clang/lib/Interpreter/Interpreter.cpp | 247 ++
 clang/unittests/Interpreter/CMakeLists.txt|   1 +
 .../Interpreter/InterpreterExtensionsTest.cpp |  79 ++
 4 files changed, 253 insertions(+), 109 deletions(-)
 create mode 100644 clang/unittests/Interpreter/InterpreterExtensionsTest.cpp

diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index c8f932e95c4798..d972d960dcb7cd 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -18,6 +18,7 @@
 #include "clang/AST/GlobalDecl.h"
 #include "clang/Interpreter/PartialTranslationUnit.h"
 #include "clang/Interpreter/Value.h"
+#include "clang/Sema/Ownership.h"
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
@@ -75,17 +76,26 @@ class IncrementalCompilerBuilder {
   llvm::StringRef CudaSDKPath;
 };
 
+/// Generate glue code between the Interpreter's built-in runtime and user 
code.
+class RuntimeInterfaceBuilder {
+public:
+  virtual ~RuntimeInterfaceBuilder() = default;
+
+  using TransformExprFunction = ExprResult(RuntimeInterfaceBuilder *Builder,
+   Expr *, ArrayRef);
+  virtual TransformExprFunction *getPrintValueTransformer() = 0;
+};
+
 /// Provides top-level interfaces for incremental compilation and execution.
 class Interpreter {
   std::unique_ptr TSCtx;
   std::unique_ptr IncrParser;
   std::unique_ptr IncrExecutor;
+  std::unique_ptr RuntimeIB;
 
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
-  Interpreter(std::unique_ptr CI, llvm::Error &Err);
-
   llvm::Error CreateExecutor();
   unsigned InitPTUSize = 0;
 
@@ -94,8 +104,25 @@ class Interpreter {
   // printing happens, it's in an invalid state.
   Value LastValue;
 
+  // Add a call to an Expr to report its result. We query the function from
+  // RuntimeInterfaceBuilder once and store it as a function pointer to avoid
+  // frequent virtual function calls.
+  RuntimeInterfaceBuilder::TransformExprFunction *AddPrintValueCall = nullptr;
+
+protected:
+  // Derived classes can make use an extended interface of the Interpreter.
+  // That's useful for testing and out-of-tree clients.
+  Interpreter(std::unique_ptr CI, llvm::Error &Err);
+
+  // Lazily construct the RuntimeInterfaceBuilder. The provided instance will 
be
+  // used for the entire lifetime of the interpreter. The default 
implementation
+  // targets the in-process __clang_Interpreter runtime. Override this to use a
+  // custom runtime.
+  virtual std::unique_ptr FindRuntimeInterface();
+
 public:
-  ~Interpreter();
+  virtual ~Interpreter();
+
   static llvm::Expected>
   create(std::unique_ptr CI);
   static llvm::Expected>
@@ -143,8 +170,6 @@ class Interpreter {
 private:
   size_t getEffectivePTUSize() const;
 
-  bool FindRuntimeInterface();
-
   llvm::DenseMap Dtors;
 
   llvm::SmallVector ValuePrintingInfo;
diff --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 37696b28976428..3485da8196683a 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -507,9 +507,13 @@ static constexpr llvm::StringRef MagicRuntimeInterface[] = 
{
 "__clang_Interpreter_SetValueWithAlloc",
 "__clang_Interpreter_SetValueCopyArr", "__ci_newtag"};
 
-bool Interpreter::FindRuntimeInterface() {
+static std::unique_ptr
+createInProcessRuntimeInterfaceBuilder(Interpreter &Interp, ASTContext &Ctx,
+   Sema &S);
+
+std::unique_ptr Interpreter::FindRuntimeInterface() {
   if (llvm::all_of(ValuePrintingInfo, [](Expr *E) { return E != nullptr; }))
-return true;
+return nullptr;
 
   Sema &S = getCompilerInstance()->getSema();
   ASTContext &Ctx = S.getASTContext();
@@ -528,120 +532,34 @@ bool Interpreter::FindRuntimeInterface() {
 
   if (!LookupInterface(ValuePrintingInfo[NoAlloc],
MagicRuntimeInterface[NoAlloc]))
-return false;
+return nullptr;
   if (!LookupInterface(ValuePrintingInfo[WithAlloc],
MagicRuntimeInterface[WithAlloc]))
-return false;
+return nullptr;
   if (!LookupInterface(ValuePrintingInfo[CopyArray],
MagicRuntimeInterface[CopyArray]))
-return false;
+return nullptr;
   if (!LookupInterface(ValuePrintingInfo[NewTag],

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

https://github.com/weliveindetail created 
https://github.com/llvm/llvm-project/pull/84461

The LLJITBuilder interface provides a very convenient way to configure the 
ORCv2 JIT engine. IncrementalExecutor already used it internally to construct 
the JIT, but didn't provide external access. This patch lifts control of the 
creation process to the Interpreter and allows injection of a custom instance 
through the extended interface. The Interpreter's default behavior remains 
unchanged and the IncrementalExecutor remains an implementation detail.

From f87c7ccf59ad436087ada4be479102f7317d50ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?= 
Date: Fri, 8 Mar 2024 00:08:56 +0100
Subject: [PATCH 1/3] [clang-repl] Expose RuntimeInterfaceBuilder for
 customizations

---
 clang/include/clang/Interpreter/Interpreter.h |  35 ++-
 clang/lib/Interpreter/Interpreter.cpp | 247 ++
 clang/unittests/Interpreter/CMakeLists.txt|   1 +
 .../Interpreter/InterpreterExtensionsTest.cpp |  79 ++
 4 files changed, 253 insertions(+), 109 deletions(-)
 create mode 100644 clang/unittests/Interpreter/InterpreterExtensionsTest.cpp

diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index c8f932e95c4798..d972d960dcb7cd 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -18,6 +18,7 @@
 #include "clang/AST/GlobalDecl.h"
 #include "clang/Interpreter/PartialTranslationUnit.h"
 #include "clang/Interpreter/Value.h"
+#include "clang/Sema/Ownership.h"
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
@@ -75,17 +76,26 @@ class IncrementalCompilerBuilder {
   llvm::StringRef CudaSDKPath;
 };
 
+/// Generate glue code between the Interpreter's built-in runtime and user 
code.
+class RuntimeInterfaceBuilder {
+public:
+  virtual ~RuntimeInterfaceBuilder() = default;
+
+  using TransformExprFunction = ExprResult(RuntimeInterfaceBuilder *Builder,
+   Expr *, ArrayRef);
+  virtual TransformExprFunction *getPrintValueTransformer() = 0;
+};
+
 /// Provides top-level interfaces for incremental compilation and execution.
 class Interpreter {
   std::unique_ptr TSCtx;
   std::unique_ptr IncrParser;
   std::unique_ptr IncrExecutor;
+  std::unique_ptr RuntimeIB;
 
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
-  Interpreter(std::unique_ptr CI, llvm::Error &Err);
-
   llvm::Error CreateExecutor();
   unsigned InitPTUSize = 0;
 
@@ -94,8 +104,25 @@ class Interpreter {
   // printing happens, it's in an invalid state.
   Value LastValue;
 
+  // Add a call to an Expr to report its result. We query the function from
+  // RuntimeInterfaceBuilder once and store it as a function pointer to avoid
+  // frequent virtual function calls.
+  RuntimeInterfaceBuilder::TransformExprFunction *AddPrintValueCall = nullptr;
+
+protected:
+  // Derived classes can make use an extended interface of the Interpreter.
+  // That's useful for testing and out-of-tree clients.
+  Interpreter(std::unique_ptr CI, llvm::Error &Err);
+
+  // Lazily construct the RuntimeInterfaceBuilder. The provided instance will 
be
+  // used for the entire lifetime of the interpreter. The default 
implementation
+  // targets the in-process __clang_Interpreter runtime. Override this to use a
+  // custom runtime.
+  virtual std::unique_ptr FindRuntimeInterface();
+
 public:
-  ~Interpreter();
+  virtual ~Interpreter();
+
   static llvm::Expected>
   create(std::unique_ptr CI);
   static llvm::Expected>
@@ -143,8 +170,6 @@ class Interpreter {
 private:
   size_t getEffectivePTUSize() const;
 
-  bool FindRuntimeInterface();
-
   llvm::DenseMap Dtors;
 
   llvm::SmallVector ValuePrintingInfo;
diff --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 37696b28976428..3485da8196683a 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -507,9 +507,13 @@ static constexpr llvm::StringRef MagicRuntimeInterface[] = 
{
 "__clang_Interpreter_SetValueWithAlloc",
 "__clang_Interpreter_SetValueCopyArr", "__ci_newtag"};
 
-bool Interpreter::FindRuntimeInterface() {
+static std::unique_ptr
+createInProcessRuntimeInterfaceBuilder(Interpreter &Interp, ASTContext &Ctx,
+   Sema &S);
+
+std::unique_ptr Interpreter::FindRuntimeInterface() {
   if (llvm::all_of(ValuePrintingInfo, [](Expr *E) { return E != nullptr; }))
-return true;
+return nullptr;
 
   Sema &S = getCompilerInstance()->getSema();
   ASTContext &Ctx = S.getASTContext();
@@ -528,120 +532,34 @@ bool Interpreter::FindRuntimeInterface() {
 
   if (!LookupInterface(ValuePrintingInfo[NoAlloc],
MagicRuntimeInterface[NoAlloc]))
-return false;
+return nullptr;
   if (!LookupInterface(ValuePrintingInfo[WithAlloc],

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

@@ -0,0 +1,54 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -I%S/Inputs -std=c++20 %s
+
+// expected-no-diagnostics
+
+#include "std-coroutine.h"
+
+using size_t = decltype(sizeof(0));
+
+struct Generator {
+  struct promise_type {
+int _val{};
+
+Generator get_return_object() noexcept
+{
+  return {};
+}
+
+std::suspend_never initial_suspend() noexcept
+{
+  return {};
+}
+
+std::suspend_always final_suspend() noexcept
+{
+  return {};
+}
+
+void return_void() noexcept {}
+void unhandled_exception() noexcept {}
+
+template
+static void*
+operator new(size_t size,
+ This&,
+ TheRest&&...) noexcept
+{
+return nullptr;
+}
+
+static void operator delete(void*, size_t)
+{
+}
+  };
+};
+
+int main()
+{
+  auto lamb = []() -> Generator {

andreasfertig wrote:

I added tests that capture the `this` pointer. Please, let me know if you have 
new questions or if the previous ones are still open.

https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Expose CreateExecutor() and ResetExecutor() in extended Interpreter interface (PR #84460)

[via cfe-commits]

Stefan =?utf-8?q?Gränitz?= 
Message-ID:
In-Reply-To: 


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Stefan Gränitz (weliveindetail)


Changes

IncrementalExecutor is an implementation detail of the Interpreter. In order to 
test extended features properly, we must be able to setup and tear down the 
executor manually.

---

Patch is 21.24 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/84460.diff


4 Files Affected:

- (modified) clang/include/clang/Interpreter/Interpreter.h (+38-6) 
- (modified) clang/lib/Interpreter/Interpreter.cpp (+160-104) 
- (modified) clang/unittests/Interpreter/CMakeLists.txt (+2) 
- (added) clang/unittests/Interpreter/InterpreterExtensionsTest.cpp (+105) 


``diff
diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index c8f932e95c4798..344f38da5ab21b 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -18,6 +18,7 @@
 #include "clang/AST/GlobalDecl.h"
 #include "clang/Interpreter/PartialTranslationUnit.h"
 #include "clang/Interpreter/Value.h"
+#include "clang/Sema/Ownership.h"
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
@@ -75,18 +76,26 @@ class IncrementalCompilerBuilder {
   llvm::StringRef CudaSDKPath;
 };
 
+/// Generate glue code between the Interpreter's built-in runtime and user 
code.
+class RuntimeInterfaceBuilder {
+public:
+  virtual ~RuntimeInterfaceBuilder() = default;
+
+  using TransformExprFunction = ExprResult(RuntimeInterfaceBuilder *Builder,
+   Expr *, ArrayRef);
+  virtual TransformExprFunction *getPrintValueTransformer() = 0;
+};
+
 /// Provides top-level interfaces for incremental compilation and execution.
 class Interpreter {
   std::unique_ptr TSCtx;
   std::unique_ptr IncrParser;
   std::unique_ptr IncrExecutor;
+  std::unique_ptr RuntimeIB;
 
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
-  Interpreter(std::unique_ptr CI, llvm::Error &Err);
-
-  llvm::Error CreateExecutor();
   unsigned InitPTUSize = 0;
 
   // This member holds the last result of the value printing. It's a class
@@ -94,8 +103,33 @@ class Interpreter {
   // printing happens, it's in an invalid state.
   Value LastValue;
 
+  // Add a call to an Expr to report its result. We query the function from
+  // RuntimeInterfaceBuilder once and store it as a function pointer to avoid
+  // frequent virtual function calls.
+  RuntimeInterfaceBuilder::TransformExprFunction *AddPrintValueCall = nullptr;
+
+protected:
+  // Derived classes can make use an extended interface of the Interpreter.
+  // That's useful for testing and out-of-tree clients.
+  Interpreter(std::unique_ptr CI, llvm::Error &Err);
+
+  // Create the internal IncrementalExecutor, or re-create it after calling
+  // ResetExecutor().
+  llvm::Error CreateExecutor();
+
+  // Delete the internal IncrementalExecutor. This causes a hard shutdown of 
the
+  // JIT engine. In particular, it doesn't run cleanup or destructors.
+  void ResetExecutor();
+
+  // Lazily construct the RuntimeInterfaceBuilder. The provided instance will 
be
+  // used for the entire lifetime of the interpreter. The default 
implementation
+  // targets the in-process __clang_Interpreter runtime. Override this to use a
+  // custom runtime.
+  virtual std::unique_ptr FindRuntimeInterface();
+
 public:
-  ~Interpreter();
+  virtual ~Interpreter();
+
   static llvm::Expected>
   create(std::unique_ptr CI);
   static llvm::Expected>
@@ -143,8 +177,6 @@ class Interpreter {
 private:
   size_t getEffectivePTUSize() const;
 
-  bool FindRuntimeInterface();
-
   llvm::DenseMap Dtors;
 
   llvm::SmallVector ValuePrintingInfo;
diff --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 37696b28976428..0b4ef946de6ac4 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -36,9 +36,11 @@
 #include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Sema/Lookup.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
+#include "llvm/ExecutionEngine/Orc/JITTargetMachineBuilder.h"
 #include "llvm/ExecutionEngine/Orc/LLJIT.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Support/Errc.h"
+#include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/TargetParser/Host.h"
@@ -368,9 +370,22 @@ Interpreter::Parse(llvm::StringRef Code) {
   return IncrParser->Parse(Code);
 }
 
+static llvm::Expected
+createJITTargetMachineBuilder(const std::string &TT) {
+  if (TT == llvm::sys::getProcessTriple())
+return llvm::orc::JITTargetMachineBuilder::detectHost();
+  // FIXME: This can fail as well if the target is not registered! We just 
don't
+  // catch it yet.
+  return llvm::orc::JITTargetMachineBuilder(llvm::Triple(TT));
+}
+
 llvm::Error Interpreter::CreateExec

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[via cfe-commits]

Stefan =?utf-8?q?Gränitz?= ,
Stefan =?utf-8?q?Gränitz?= 
Message-ID:
In-Reply-To: 


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Stefan Gränitz (weliveindetail)


Changes

The LLJITBuilder interface provides a very convenient way to configure the 
ORCv2 JIT engine. IncrementalExecutor already used it internally to construct 
the JIT, but didn't provide external access. This patch lifts control of the 
creation process to the Interpreter and allows injection of a custom instance 
through the extended interface. The Interpreter's default behavior remains 
unchanged and the IncrementalExecutor remains an implementation detail.

---

Patch is 29.61 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/84461.diff


6 Files Affected:

- (modified) clang/include/clang/Interpreter/Interpreter.h (+47-6) 
- (modified) clang/lib/Interpreter/IncrementalExecutor.cpp (+18-15) 
- (modified) clang/lib/Interpreter/IncrementalExecutor.h (+7-2) 
- (modified) clang/lib/Interpreter/Interpreter.cpp (+174-107) 
- (modified) clang/unittests/Interpreter/CMakeLists.txt (+2) 
- (added) clang/unittests/Interpreter/InterpreterExtensionsTest.cpp (+220) 


``diff
diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index c8f932e95c4798..8b47a899873715 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -18,6 +18,7 @@
 #include "clang/AST/GlobalDecl.h"
 #include "clang/Interpreter/PartialTranslationUnit.h"
 #include "clang/Interpreter/Value.h"
+#include "clang/Sema/Ownership.h"
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
@@ -28,7 +29,9 @@
 
 namespace llvm {
 namespace orc {
+class JITTargetMachineBuilder;
 class LLJIT;
+class LLJITBuilder;
 class ThreadSafeContext;
 } // namespace orc
 } // namespace llvm
@@ -75,18 +78,26 @@ class IncrementalCompilerBuilder {
   llvm::StringRef CudaSDKPath;
 };
 
+/// Generate glue code between the Interpreter's built-in runtime and user 
code.
+class RuntimeInterfaceBuilder {
+public:
+  virtual ~RuntimeInterfaceBuilder() = default;
+
+  using TransformExprFunction = ExprResult(RuntimeInterfaceBuilder *Builder,
+   Expr *, ArrayRef);
+  virtual TransformExprFunction *getPrintValueTransformer() = 0;
+};
+
 /// Provides top-level interfaces for incremental compilation and execution.
 class Interpreter {
   std::unique_ptr TSCtx;
   std::unique_ptr IncrParser;
   std::unique_ptr IncrExecutor;
+  std::unique_ptr RuntimeIB;
 
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
-  Interpreter(std::unique_ptr CI, llvm::Error &Err);
-
-  llvm::Error CreateExecutor();
   unsigned InitPTUSize = 0;
 
   // This member holds the last result of the value printing. It's a class
@@ -94,8 +105,40 @@ class Interpreter {
   // printing happens, it's in an invalid state.
   Value LastValue;
 
+  // Add a call to an Expr to report its result. We query the function from
+  // RuntimeInterfaceBuilder once and store it as a function pointer to avoid
+  // frequent virtual function calls.
+  RuntimeInterfaceBuilder::TransformExprFunction *AddPrintValueCall = nullptr;
+
+protected:
+  // Derived classes can make use an extended interface of the Interpreter.
+  // That's useful for testing and out-of-tree clients.
+  Interpreter(std::unique_ptr CI, llvm::Error &Err);
+
+  // Create the internal IncrementalExecutor, or re-create it after calling
+  // ResetExecutor().
+  llvm::Error CreateExecutor();
+
+  // Delete the internal IncrementalExecutor. This causes a hard shutdown of 
the
+  // JIT engine. In particular, it doesn't run cleanup or destructors.
+  void ResetExecutor();
+
+  // Lazily construct the RuntimeInterfaceBuilder. The provided instance will 
be
+  // used for the entire lifetime of the interpreter. The default 
implementation
+  // targets the in-process __clang_Interpreter runtime. Override this to use a
+  // custom runtime.
+  virtual std::unique_ptr FindRuntimeInterface();
+
+  // Lazily construct thev ORCv2 JITBuilder. This called when the internal
+  // IncrementalExecutor is created. The default implementation populates an
+  // in-process JIT with debugging support. Override this to configure the JIT
+  // engine used for execution.
+  virtual llvm::Expected>
+  CreateJITBuilder(CompilerInstance &CI);
+
 public:
-  ~Interpreter();
+  virtual ~Interpreter();
+
   static llvm::Expected>
   create(std::unique_ptr CI);
   static llvm::Expected>
@@ -143,8 +186,6 @@ class Interpreter {
 private:
   size_t getEffectivePTUSize() const;
 
-  bool FindRuntimeInterface();
-
   llvm::DenseMap Dtors;
 
   llvm::SmallVector ValuePrintingInfo;
diff --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
index 40bcef94797d43..6f036107c14a9c 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.cpp
++

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

@@ -1434,13 +1434,18 @@ ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
 return Diag(Loc, diag::err_invalid_this_use) << 0;
   }
 
-  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false);
+  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false,
+  SkipLambdaCaptureCheck);
 }
 
-Expr *Sema::BuildCXXThisExpr(SourceLocation Loc, QualType Type,
- bool IsImplicit) {
+Expr *Sema::BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool 
IsImplicit,
+ bool SkipLambdaCaptureCheck) {
   auto *This = CXXThisExpr::Create(Context, Loc, Type, IsImplicit);
-  MarkThisReferenced(This);
+
+  if (!SkipLambdaCaptureCheck) {

andreasfertig wrote:

I assume your question is answered by my answer above: 
https://github.com/llvm/llvm-project/pull/84193#discussion_r1515631511.

https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Expose CreateExecutor() and ResetExecutor() in extended Interpreter interface (PR #84460)

[via cfe-commits]

Stefan =?utf-8?q?Gränitz?= 
Message-ID:
In-Reply-To: 


github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 5d33f7176b002da244823ca0e6b524777890dd9d 
023cab5a10e381533c9dc2a7c15823bb9bb9e54e -- 
clang/unittests/Interpreter/InterpreterExtensionsTest.cpp 
clang/include/clang/Interpreter/Interpreter.h 
clang/lib/Interpreter/Interpreter.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/unittests/Interpreter/InterpreterExtensionsTest.cpp 
b/clang/unittests/Interpreter/InterpreterExtensionsTest.cpp
index 8b88db1fcf..f1c3d65ab0 100644
--- a/clang/unittests/Interpreter/InterpreterExtensionsTest.cpp
+++ b/clang/unittests/Interpreter/InterpreterExtensionsTest.cpp
@@ -33,9 +33,7 @@ public:
   llvm::Error &Err)
   : Interpreter(std::move(CI), Err) {}
 
-  llvm::Error testCreateExecutor() {
-return Interpreter::CreateExecutor();
-  }
+  llvm::Error testCreateExecutor() { return Interpreter::CreateExecutor(); }
 
   void resetExecutor() { Interpreter::ResetExecutor(); }
 };

``




https://github.com/llvm/llvm-project/pull/84460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Allow access to a public template alias declaration that refers to friend's private nested type (PR #83847)

[Qizhi Hu via cfe-commits]

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/83847

>From da384cdf38f64d7c956c07b007f417dd223177ef Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Mon, 4 Mar 2024 21:51:07 +0800
Subject: [PATCH] [Clang][Sema] Allow access to a public template alias
 declaration that refers to friend's private nested type

---
 clang/docs/ReleaseNotes.rst |  4 
 clang/lib/Sema/SemaAccess.cpp   |  9 +
 clang/test/SemaTemplate/PR25708.cpp | 23 +++
 3 files changed, 36 insertions(+)
 create mode 100644 clang/test/SemaTemplate/PR25708.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 0ee2801766a9cc..3f4bd5503983d5 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -254,6 +254,10 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
+- Allow access to a public template alias declaration that refers to friend's
+  private nested type.
+  Fixes (#GH25708).
+
 Bug Fixes to Compiler Builtins
 ^^
 
diff --git a/clang/lib/Sema/SemaAccess.cpp b/clang/lib/Sema/SemaAccess.cpp
index 4af3c0f30a8e8a..0c8d15210f439c 100644
--- a/clang/lib/Sema/SemaAccess.cpp
+++ b/clang/lib/Sema/SemaAccess.cpp
@@ -1481,6 +1481,15 @@ static Sema::AccessResult CheckAccess(Sema &S, 
SourceLocation Loc,
   }
 
   EffectiveContext EC(S.CurContext);
+  if (!S.CodeSynthesisContexts.empty()) {
+auto &Active = S.CodeSynthesisContexts.back();
+if (Active.Kind == Sema::CodeSynthesisContext::TemplateInstantiation &&
+Active.Entity)
+  if (auto *RD =
+  dyn_cast_or_null(Active.Entity->getDeclContext()))
+EC.Records.push_back(RD);
+  }
+
   switch (CheckEffectiveAccess(S, EC, Loc, Entity)) {
   case AR_accessible: return Sema::AR_accessible;
   case AR_inaccessible: return Sema::AR_inaccessible;
diff --git a/clang/test/SemaTemplate/PR25708.cpp 
b/clang/test/SemaTemplate/PR25708.cpp
new file mode 100644
index 00..cc2e7551a6abaa
--- /dev/null
+++ b/clang/test/SemaTemplate/PR25708.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++14 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// expected-no-diagnostics
+
+struct FooAccessor
+{
+template 
+using Foo = typename T::Foo;
+};
+
+class Type
+{
+friend struct FooAccessor;
+
+using Foo = int;
+};
+
+int main()
+{
+FooAccessor::Foo t;
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

[Nikita Popov via cfe-commits]

nikic wrote:

So yeah, I think the source-relative representation is better if we consider 
only the current vtable / GlobalSplit use case (where we'd just convert 
result-relative to source-relative anyway), while the result-relative 
representation is better if we consider a potential extension to instruction 
GEP / non-constant indices in the future.

If we have something like
```
struct Foo { int a, int b, int c };
struct Foo foo[100];
fn(&foo[x]);
```
then we could pass `ptradd ptr inrange(0, 12) @foo, i64 %x * 12` to the 
function and know (for AA purposes) that it only accesses a single struct in 
the array.

This would also be consistent with the alternative intrinsic based 
representation, which would go something like `%p = ptradd ptr @foo, i64 %x * 
12; %p2 = call @llvm.memory.region.decl.p0(ptr %p, i64 0, i64 12)`.

-

With that in mind, I'm leaning towards keeping the result-relative encoding. 
For constant GEPs it makes little difference because we can also ways just 
add/subtract the necessary offset, but this seems more future-proof if we do 
decide to extend to instructions.

https://github.com/llvm/llvm-project/pull/84341
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Expose CreateExecutor() and ResetExecutor() in extended Interpreter interface (PR #84460)

[Stefan Gränitz via cfe-commits]

weliveindetail wrote:

This PR was factored out for isolated review and to reduce the size of the 
follow-up patch in https://github.com/llvm/llvm-project/pull/84461. It depends 
on the previous change in https://github.com/llvm/llvm-project/pull/83126. 
Combined patch size will shrink significantly, once it landed (tonight 
hopefully). Until then please refer to the single commit 
https://github.com/llvm/llvm-project/pull/84460/commits/023cab5a10e381533c9dc2a7c15823bb9bb9e54e

https://github.com/llvm/llvm-project/pull/84460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

@@ -373,21 +373,32 @@ Interpreter::Parse(llvm::StringRef Code) {
 static llvm::Expected
 createJITTargetMachineBuilder(const std::string &TT) {
   if (TT == llvm::sys::getProcessTriple())
+// This fails immediately if the target backend is not registered
 return llvm::orc::JITTargetMachineBuilder::detectHost();
-  // FIXME: This can fail as well if the target is not registered! We just 
don't
-  // catch it yet.
+
+  // If the target backend is not registered, LLJITBuilder::create() will fail
   return llvm::orc::JITTargetMachineBuilder(llvm::Triple(TT));
 }
 
+llvm::Expected>
+Interpreter::CreateJITBuilder(CompilerInstance &CI) {
+  auto JTMB = createJITTargetMachineBuilder(CI.getTargetOpts().Triple);
+  if (!JTMB)
+return JTMB.takeError();
+  return IncrementalExecutor::createDefaultJITBuilder(std::move(*JTMB));
+}
+
 llvm::Error Interpreter::CreateExecutor() {
-  const clang::TargetInfo &TI =
-  getCompilerInstance()->getASTContext().getTargetInfo();
   if (IncrExecutor)
 return llvm::make_error("Operation failed. "
"Execution engine exists",
std::error_code());
+  llvm::Expected> JB =
+  CreateJITBuilder(*getCompilerInstance());

weliveindetail wrote:

We keep creating a new LLJITBuilder for each new IncrementalExecutor. This is 
questionable, but I didn't want to clutter the patch unnecessarily. I am happy 
to change that in a follow-up PR.

https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

https://github.com/weliveindetail commented:

This PR depends on two predecessor patches, but I wanted to share it for review 
already. For the moment please refer to the single commit in 
https://github.com/llvm/llvm-project/pull/84461/commits/cc46034e5288ba54dfc8a0ea7d54792cbb99227d
 for review.

https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

https://github.com/weliveindetail edited 
https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

@@ -102,4 +124,97 @@ TEST(InterpreterExtensionsTest, FindRuntimeInterface) {
   EXPECT_EQ(1U, Interp.RuntimeIBPtr->TransformerQueries);
 }
 
+class CustomJBInterpreter : public Interpreter {
+  using CustomJITBuilderCreatorFunction =
+  
std::function>()>;
+  CustomJITBuilderCreatorFunction JBCreator = nullptr;
+
+public:
+  CustomJBInterpreter(std::unique_ptr CI, llvm::Error 
&ErrOut)
+  : Interpreter(std::move(CI), ErrOut) {}
+
+  ~CustomJBInterpreter() override {
+// Skip cleanUp() because it would trigger LLJIT default dtors
+Interpreter::ResetExecutor();
+  }
+
+  void setCustomJITBuilderCreator(CustomJITBuilderCreatorFunction Fn) {
+JBCreator = std::move(Fn);
+  }
+
+  llvm::Expected>
+  CreateJITBuilder(CompilerInstance &CI) override {
+if (JBCreator)
+  return JBCreator();
+return Interpreter::CreateJITBuilder(CI);
+  }
+
+  llvm::Error CreateExecutor() { return Interpreter::CreateExecutor(); }
+};
+
+static void initArmTarget() {
+  static llvm::once_flag F;
+  llvm::call_once(F, [] {
+LLVMInitializeARMTarget();
+LLVMInitializeARMTargetInfo();
+LLVMInitializeARMTargetMC();
+LLVMInitializeARMAsmPrinter();
+  });
+}
+
+llvm::llvm_shutdown_obj Shutdown;
+
+TEST(InterpreterExtensionsTest, DefaultCrossJIT) {
+  IncrementalCompilerBuilder CB;
+  CB.SetTargetTriple("armv6-none-eabi");
+  auto CI = cantFail(CB.CreateCpp());
+  llvm::Error ErrOut = llvm::Error::success();
+  CustomJBInterpreter Interp(std::move(CI), ErrOut);
+  cantFail(std::move(ErrOut));
+
+  initArmTarget();
+  cantFail(Interp.CreateExecutor());
+}
+
+TEST(InterpreterExtensionsTest, CustomCrossJIT) {
+  std::string TargetTriple = "armv6-none-eabi";
+
+  IncrementalCompilerBuilder CB;
+  CB.SetTargetTriple(TargetTriple);
+  auto CI = cantFail(CB.CreateCpp());
+  llvm::Error ErrOut = llvm::Error::success();
+  CustomJBInterpreter Interp(std::move(CI), ErrOut);
+  cantFail(std::move(ErrOut));
+
+  using namespace llvm::orc;
+  LLJIT *JIT = nullptr;
+  std::vector> Objs;
+  Interp.setCustomJITBuilderCreator([&]() {
+initArmTarget();
+auto JTMB = JITTargetMachineBuilder(llvm::Triple(TargetTriple));
+JTMB.setCPU("cortex-m0plus");
+auto JB = std::make_unique();
+JB->setJITTargetMachineBuilder(JTMB);
+JB->setPlatformSetUp(setUpInactivePlatform);
+JB->setNotifyCreatedCallback([&](LLJIT &J) {
+  ObjectLayer &ObjLayer = J.getObjLinkingLayer();
+  auto *JITLinkObjLayer = llvm::dyn_cast(&ObjLayer);

weliveindetail wrote:

We know that the ARM target uses JITLink, but we could also check explicitly. 
It seems nice to check that we produce some actual code. Maybe we want checks 
on the object code in the future? This might be a good template for such tests.

https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-repl] Factor out CreateJITBuilder() and allow specialization in derived classes (PR #84461)

[Stefan Gränitz via cfe-commits]

@@ -102,4 +124,97 @@ TEST(InterpreterExtensionsTest, FindRuntimeInterface) {
   EXPECT_EQ(1U, Interp.RuntimeIBPtr->TransformerQueries);
 }
 
+class CustomJBInterpreter : public Interpreter {
+  using CustomJITBuilderCreatorFunction =
+  
std::function>()>;
+  CustomJITBuilderCreatorFunction JBCreator = nullptr;
+
+public:
+  CustomJBInterpreter(std::unique_ptr CI, llvm::Error 
&ErrOut)
+  : Interpreter(std::move(CI), ErrOut) {}
+
+  ~CustomJBInterpreter() override {
+// Skip cleanUp() because it would trigger LLJIT default dtors
+Interpreter::ResetExecutor();
+  }
+
+  void setCustomJITBuilderCreator(CustomJITBuilderCreatorFunction Fn) {
+JBCreator = std::move(Fn);
+  }
+
+  llvm::Expected>
+  CreateJITBuilder(CompilerInstance &CI) override {
+if (JBCreator)
+  return JBCreator();
+return Interpreter::CreateJITBuilder(CI);
+  }
+
+  llvm::Error CreateExecutor() { return Interpreter::CreateExecutor(); }
+};
+
+static void initArmTarget() {
+  static llvm::once_flag F;
+  llvm::call_once(F, [] {
+LLVMInitializeARMTarget();
+LLVMInitializeARMTargetInfo();
+LLVMInitializeARMTargetMC();
+LLVMInitializeARMAsmPrinter();
+  });
+}
+
+llvm::llvm_shutdown_obj Shutdown;
+
+TEST(InterpreterExtensionsTest, DefaultCrossJIT) {
+  IncrementalCompilerBuilder CB;
+  CB.SetTargetTriple("armv6-none-eabi");
+  auto CI = cantFail(CB.CreateCpp());
+  llvm::Error ErrOut = llvm::Error::success();
+  CustomJBInterpreter Interp(std::move(CI), ErrOut);
+  cantFail(std::move(ErrOut));
+
+  initArmTarget();
+  cantFail(Interp.CreateExecutor());
+}
+
+TEST(InterpreterExtensionsTest, CustomCrossJIT) {
+  std::string TargetTriple = "armv6-none-eabi";
+
+  IncrementalCompilerBuilder CB;
+  CB.SetTargetTriple(TargetTriple);
+  auto CI = cantFail(CB.CreateCpp());
+  llvm::Error ErrOut = llvm::Error::success();
+  CustomJBInterpreter Interp(std::move(CI), ErrOut);
+  cantFail(std::move(ErrOut));
+
+  using namespace llvm::orc;
+  LLJIT *JIT = nullptr;
+  std::vector> Objs;
+  Interp.setCustomJITBuilderCreator([&]() {
+initArmTarget();
+auto JTMB = JITTargetMachineBuilder(llvm::Triple(TargetTriple));
+JTMB.setCPU("cortex-m0plus");
+auto JB = std::make_unique();
+JB->setJITTargetMachineBuilder(JTMB);
+JB->setPlatformSetUp(setUpInactivePlatform);
+JB->setNotifyCreatedCallback([&](LLJIT &J) {
+  ObjectLayer &ObjLayer = J.getObjLinkingLayer();
+  auto *JITLinkObjLayer = llvm::dyn_cast(&ObjLayer);
+  JITLinkObjLayer->setReturnObjectBuffer(
+  [&Objs](std::unique_ptr MB) {
+Objs.push_back(std::move(MB));
+  });
+  JIT = &J;
+  return llvm::Error::success();
+});
+return JB;
+  });
+
+  EXPECT_EQ(0U, Objs.size());
+  cantFail(Interp.CreateExecutor());
+  cantFail(Interp.ParseAndExecute("int a = 1;"));

weliveindetail wrote:

This works cross-platform, because we don't actually execute code. 
InactivePlatform suppresses execution of the respective initializers.

https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

https://github.com/andreasfertig updated 
https://github.com/llvm/llvm-project/pull/84193

>From 9f8a741864b01e89ea17b5ea4c4296da27ef Mon Sep 17 00:00:00 2001
From: Andreas Fertig 
Date: Wed, 6 Mar 2024 14:20:00 +0100
Subject: [PATCH] [C++20][Coroutines] Lambda-coroutine with operator new in
 promise_type

Fix #84064

According to http://eel.is/c++draft/dcl.fct.def.coroutine#9 the first
parameter for overload resolution of `operator new` is `size_t` followed
by the arguments of the coroutine function.
http://eel.is/c++draft/dcl.fct.def.coroutine#4 states that the first argument
is the lvalue of `*this` if the coroutine is a member function.

Before this patch, Clang handled class types correctly but ignored lambdas.
This patch adds support for lambda coroutines with a `promise_type` that
implements a custom `operator new`.

The patch does consider C++23 `static operator()`, which already worked as
there is no `this` parameter.
---
 clang/include/clang/Sema/Sema.h  | 12 -
 clang/lib/Sema/SemaCoroutine.cpp | 18 +++-
 clang/lib/Sema/SemaExprCXX.cpp   | 16 +--
 clang/test/SemaCXX/gh84064-1.cpp | 79 
 clang/test/SemaCXX/gh84064-2.cpp | 53 +
 5 files changed, 169 insertions(+), 9 deletions(-)
 create mode 100644 clang/test/SemaCXX/gh84064-1.cpp
 create mode 100644 clang/test/SemaCXX/gh84064-2.cpp

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..8b4c18140a89e6 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -6752,10 +6752,18 @@ class Sema final {
 SourceLocation RParenLoc);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
+  /// lambda because 'this' refers to the closure object.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool ThisRefersToClosureObject = false);
 
   /// Build a CXXThisExpr and mark it referenced in the current context.
-  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit);
+  ///
+  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
+  /// lambda because 'this' refers to the closure object.
+  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit,
+ bool ThisRefersToClosureObject = false);
   void MarkThisReferenced(CXXThisExpr *This);
 
   /// Try to retrieve the type of the 'this' pointer.
diff --git a/clang/lib/Sema/SemaCoroutine.cpp b/clang/lib/Sema/SemaCoroutine.cpp
index a969b9383563b2..301a5ff72a3b2a 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -25,6 +25,7 @@
 #include "clang/Sema/Initialization.h"
 #include "clang/Sema/Overload.h"
 #include "clang/Sema/ScopeInfo.h"
+#include "clang/Sema/Sema.h"
 #include "clang/Sema/SemaInternal.h"
 #include "llvm/ADT/SmallSet.h"
 
@@ -1378,8 +1379,21 @@ bool CoroutineStmtBuilder::makeReturnOnAllocFailure() {
 static bool collectPlacementArgs(Sema &S, FunctionDecl &FD, SourceLocation Loc,
  SmallVectorImpl &PlacementArgs) {
   if (auto *MD = dyn_cast(&FD)) {
-if (MD->isImplicitObjectMemberFunction() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+if (MD->isImplicitObjectMemberFunction()) {
+  ExprResult ThisExpr{};
+
+  if (isLambdaCallOperator(MD) && !MD->isStatic()) {
+Qualifiers ThisQuals = MD->getMethodQualifiers();
+CXXRecordDecl *Record = MD->getParent();
+
+Sema::CXXThisScopeRAII ThisScope(S, Record, ThisQuals,
+ Record != nullptr);
+
+ThisExpr = S.ActOnCXXThis(Loc, /*ThisRefersToClosureObject=*/true);
+  } else {
+ThisExpr = S.ActOnCXXThis(Loc);
+  }
+
   if (ThisExpr.isInvalid())
 return false;
   ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index c34a40fa7c81ac..88e3d9ced044cb 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -1414,7 +1414,8 @@ bool Sema::CheckCXXThisCapture(SourceLocation Loc, const 
bool Explicit,
   return false;
 }
 
-ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
+ExprResult Sema::ActOnCXXThis(SourceLocation Loc,
+  bool ThisRefersToClosureObject) {
   /// C++ 9.3.2: In the body of a non-static member function, the keyword this
   /// is a non-lvalue expression whose value is the address of the object for
   /// which the function is called.
@@ -1434,13 +1435,18 @@ ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
 return Diag(Loc, diag::err_invalid_this_use) << 0;
   }
 
-  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false);
+  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false

[clang-tools-extra] [clang-tidy] Fix Hungarian Prefix in readability-identifier-naming (PR #84236)

[Dmitry Polukhin via cfe-commits]

@@ -229,7 +229,8 @@ Changes in existing checks
 
 - Improved :doc:`readability-identifier-naming
   ` check in 
`GetConfigPerFile`
-  mode by resolving symbolic links to header files.
+  mode by resolving symbolic links to header files. Fixed handling of Hungarian

dmpolukhin wrote:

OK, if you think it makes Release Notes more readable.

https://github.com/llvm/llvm-project/pull/84236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Fix Hungarian Prefix in readability-identifier-naming (PR #84236)

[Dmitry Polukhin via cfe-commits]

https://github.com/dmpolukhin approved this pull request.


https://github.com/llvm/llvm-project/pull/84236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (PR #84459)

[via cfe-commits]

https://github.com/cor3ntin approved this pull request.


https://github.com/llvm/llvm-project/pull/84459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

https://github.com/NagyDonat created 
https://github.com/llvm/llvm-project/pull/84469

Previously, the function `isCLibraryFunction()` and logic relying on it only 
accepted functions that are declared directly within a TU (i.e. not in a 
namespace or a class). However C++ headers like  declare many C 
standard library functions within the namespace `std`, so this commit ensures 
that functions within the namespace `std` are also accepted.

After this commit it will be possible to match functions like `malloc` or 
`free` with `CallDescription::Mode::CLibrary`.

>From c357aa998204e6693430c801f5b7d3a9e5e09e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 8 Mar 2024 13:06:01 +0100
Subject: [PATCH] [analyzer] Accept C library functions from the `std`
 namespace

Previously, the function `isCLibraryFunction()` and logic relying on it
only accepted functions that are declared directly within a TU (i.e. not
in a namespace or a class). However C++ headers like  declare
many C standard library functions within the namespace `std`, so this
commit ensures that functions within the namespace `std` are also
accepted.

After this commit it will be possible to match functions like `malloc` or
`free` with `CallDescription::Mode::CLibrary`.
---
 .../StaticAnalyzer/Core/PathSensitive/CallDescription.h  | 8 ++--
 clang/lib/StaticAnalyzer/Core/CheckerContext.cpp | 9 ++---
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
index 3432d2648633c2..7da65734a44cf3 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the `std::` namespace.)
 CLibrary,
 
 /// Matches "simple" functions that are not methods. (Static methods are
diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index d6d4cec9dd3d4d..c1ae9b441d98d1 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -87,9 +88,11 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   if (!II)
 return false;
 
-  // Look through 'extern "C"' and anything similar invented in the future.
-  // If this function is not in TU directly, it is not a C library function.
-  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit())
+  // C library functions are either declared directly within a TU (the common
+  // case) or they are accessed through the namespace `std::` (when they are
+  // used in C++ via headers like ).
+  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
+  !AnalysisDeclContext::isInStdNamespace(FD))
 return false;
 
   // If this function is not externally visible, it is not a C library 
function.

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (NagyDonat)


Changes

Previously, the function `isCLibraryFunction()` and logic relying on it only 
accepted functions that are declared directly within a TU (i.e. not in a 
namespace or a class). However C++ headers like  declare many C 
standard library functions within the namespace `std`, so this commit ensures 
that functions within the namespace `std` are also accepted.

After this commit it will be possible to match functions like `malloc` or 
`free` with `CallDescription::Mode::CLibrary`.

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


2 Files Affected:

- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h (+2-6) 
- (modified) clang/lib/StaticAnalyzer/Core/CheckerContext.cpp (+6-3) 


``diff
diff --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
index 3432d2648633c2..7da65734a44cf3 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the `std::` namespace.)
 CLibrary,
 
 /// Matches "simple" functions that are not methods. (Static methods are
diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index d6d4cec9dd3d4d..c1ae9b441d98d1 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -87,9 +88,11 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   if (!II)
 return false;
 
-  // Look through 'extern "C"' and anything similar invented in the future.
-  // If this function is not in TU directly, it is not a C library function.
-  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit())
+  // C library functions are either declared directly within a TU (the common
+  // case) or they are accessed through the namespace `std::` (when they are
+  // used in C++ via headers like ).
+  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
+  !AnalysisDeclContext::isInStdNamespace(FD))
 return false;
 
   // If this function is not externally visible, it is not a C library 
function.

``




https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 6a0618a0289cb0c23ef3e5c820418650cc1d0fdc 
c357aa998204e6693430c801f5b7d3a9e5e09e37 -- 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index c1ae9b441d..a67b44724b 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -92,7 +92,7 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   // case) or they are accessed through the namespace `std::` (when they are
   // used in C++ via headers like ).
   if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
-  !AnalysisDeclContext::isInStdNamespace(FD))
+  !AnalysisDeclContext::isInStdNamespace(FD))
 return false;
 
   // If this function is not externally visible, it is not a C library 
function.

``




https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


https://github.com/NagyDonat updated 
https://github.com/llvm/llvm-project/pull/84469

>From c357aa998204e6693430c801f5b7d3a9e5e09e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 8 Mar 2024 13:06:01 +0100
Subject: [PATCH 1/2] [analyzer] Accept C library functions from the `std`
 namespace

Previously, the function `isCLibraryFunction()` and logic relying on it
only accepted functions that are declared directly within a TU (i.e. not
in a namespace or a class). However C++ headers like  declare
many C standard library functions within the namespace `std`, so this
commit ensures that functions within the namespace `std` are also
accepted.

After this commit it will be possible to match functions like `malloc` or
`free` with `CallDescription::Mode::CLibrary`.
---
 .../StaticAnalyzer/Core/PathSensitive/CallDescription.h  | 8 ++--
 clang/lib/StaticAnalyzer/Core/CheckerContext.cpp | 9 ++---
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
index 3432d2648633c2..7da65734a44cf3 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the `std::` namespace.)
 CLibrary,
 
 /// Matches "simple" functions that are not methods. (Static methods are
diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index d6d4cec9dd3d4d..c1ae9b441d98d1 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -87,9 +88,11 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   if (!II)
 return false;
 
-  // Look through 'extern "C"' and anything similar invented in the future.
-  // If this function is not in TU directly, it is not a C library function.
-  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit())
+  // C library functions are either declared directly within a TU (the common
+  // case) or they are accessed through the namespace `std::` (when they are
+  // used in C++ via headers like ).
+  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
+  !AnalysisDeclContext::isInStdNamespace(FD))
 return false;
 
   // If this function is not externally visible, it is not a C library 
function.

>From 6afadd86a6ee790f58c7339dc019d8c8eac8a6b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 8 Mar 2024 13:22:27 +0100
Subject: [PATCH 2/2] Don't match methods from the namespace `std`

Only accept those functions whose declaration is _directly_ within the
namespace `std` (that is, not within a class or a sub-namespace).
Transparent declaration contexts (e.g. `extern "C"`) are still allowed,
but this prevents matching methods.
---
 clang/lib/StaticAnalyzer/Core/CheckerContext.cpp | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index c1ae9b441d98d1..5e706d17eeae14 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,7 +12,6 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
-#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -91,8 +90,8 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   // C library functions are either declared directly within a TU (the common
   // case) or they are accessed through the namespace `std::` (when they are
   // used in C++ vi

[clang] 5d98d88 - [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (#84459)

[via cfe-commits]

Author: Younan Zhang
Date: 2024-03-08T20:26:31+08:00
New Revision: 5d98d8822c69bc9d32c25190beaf1eaccf9ddd37

URL: 
https://github.com/llvm/llvm-project/commit/5d98d8822c69bc9d32c25190beaf1eaccf9ddd37
DIFF: 
https://github.com/llvm/llvm-project/commit/5d98d8822c69bc9d32c25190beaf1eaccf9ddd37.diff

LOG: [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC 
(#84459)

We don't modify the MLTAL parameter in `SetupConstraintScope`, and it is
better if we don't copy the 120-byte object each time we call the
function.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaConcept.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 592c7871a4a55d..2cac7e6ca08fad 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -11607,12 +11607,14 @@ class Sema final {
   LocalInstantiationScope &Scope,
   const MultiLevelTemplateArgumentList &TemplateArgs);
 
-  /// used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
+  /// Used by SetupConstraintCheckingTemplateArgumentsAndScope to 
recursively(in
   /// the case of lambdas) set up the LocalInstantiationScope of the current
   /// function.
-  bool SetupConstraintScope(
-  FunctionDecl *FD, std::optional> TemplateArgs,
-  MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope);
+  bool
+  SetupConstraintScope(FunctionDecl *FD,
+   std::optional> TemplateArgs,
+   const MultiLevelTemplateArgumentList &MLTAL,
+   LocalInstantiationScope &Scope);
 
   /// Used during constraint checking, sets up the constraint template argument
   /// lists, and calls SetupConstraintScope to set up the

diff  --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 2878e4d31ee8fe..a8e387e35fb4c9 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -586,7 +586,8 @@ bool Sema::addInstantiatedCapturesToScope(
 
 bool Sema::SetupConstraintScope(
 FunctionDecl *FD, std::optional> TemplateArgs,
-MultiLevelTemplateArgumentList MLTAL, LocalInstantiationScope &Scope) {
+const MultiLevelTemplateArgumentList &MLTAL,
+LocalInstantiationScope &Scope) {
   if (FD->isTemplateInstantiation() && FD->getPrimaryTemplate()) {
 FunctionTemplateDecl *PrimaryTemplate = FD->getPrimaryTemplate();
 InstantiatingTemplate Inst(



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Avoid unnecessary copy on MultiLevelTemplateArgumentList. NFC (PR #84459)

[Younan Zhang via cfe-commits]

https://github.com/zyn0217 closed 
https://github.com/llvm/llvm-project/pull/84459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (PR #84446)

[Aaron Ballman via cfe-commits]

https://github.com/AaronBallman approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/84446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


https://github.com/NagyDonat updated 
https://github.com/llvm/llvm-project/pull/84469

>From c357aa998204e6693430c801f5b7d3a9e5e09e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 8 Mar 2024 13:06:01 +0100
Subject: [PATCH 1/3] [analyzer] Accept C library functions from the `std`
 namespace

Previously, the function `isCLibraryFunction()` and logic relying on it
only accepted functions that are declared directly within a TU (i.e. not
in a namespace or a class). However C++ headers like  declare
many C standard library functions within the namespace `std`, so this
commit ensures that functions within the namespace `std` are also
accepted.

After this commit it will be possible to match functions like `malloc` or
`free` with `CallDescription::Mode::CLibrary`.
---
 .../StaticAnalyzer/Core/PathSensitive/CallDescription.h  | 8 ++--
 clang/lib/StaticAnalyzer/Core/CheckerContext.cpp | 9 ++---
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
index 3432d2648633c2..7da65734a44cf3 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the `std::` namespace.)
 CLibrary,
 
 /// Matches "simple" functions that are not methods. (Static methods are
diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index d6d4cec9dd3d4d..c1ae9b441d98d1 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -87,9 +88,11 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   if (!II)
 return false;
 
-  // Look through 'extern "C"' and anything similar invented in the future.
-  // If this function is not in TU directly, it is not a C library function.
-  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit())
+  // C library functions are either declared directly within a TU (the common
+  // case) or they are accessed through the namespace `std::` (when they are
+  // used in C++ via headers like ).
+  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
+  !AnalysisDeclContext::isInStdNamespace(FD))
 return false;
 
   // If this function is not externally visible, it is not a C library 
function.

>From 6afadd86a6ee790f58c7339dc019d8c8eac8a6b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 8 Mar 2024 13:22:27 +0100
Subject: [PATCH 2/3] Don't match methods from the namespace `std`

Only accept those functions whose declaration is _directly_ within the
namespace `std` (that is, not within a class or a sub-namespace).
Transparent declaration contexts (e.g. `extern "C"`) are still allowed,
but this prevents matching methods.
---
 clang/lib/StaticAnalyzer/Core/CheckerContext.cpp | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp 
b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
index c1ae9b441d98d1..5e706d17eeae14 100644
--- a/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
+++ b/clang/lib/StaticAnalyzer/Core/CheckerContext.cpp
@@ -12,7 +12,6 @@
 
//===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
-#include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/StringExtras.h"
@@ -91,8 +90,8 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   // C library functions are either declared directly within a TU (the common
   // case) or they are accessed through the namespace `std::` (when they

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

[Andreas Fertig via cfe-commits]

andreasfertig wrote:

The clang-format check fails due to a change in `clang/docs/ReleaseNotes. rst`, 
which isn't mine. What's the protocol? Shall I fix the format issue, or can my 
change be merged anyway?

https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Allow access to a public template alias declaration that refers to friend's private nested type (PR #83847)

[Qizhi Hu via cfe-commits]

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/83847

>From 1c37abe8f7b26bd44fcf8e18a4cbc5104c7bd908 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Mon, 4 Mar 2024 21:51:07 +0800
Subject: [PATCH] [Clang][Sema] Allow access to a public template alias
 declaration that refers to friend's private nested type

---
 clang/docs/ReleaseNotes.rst |  6 +-
 clang/lib/Sema/SemaAccess.cpp   |  9 +
 clang/test/SemaTemplate/PR25708.cpp | 23 +++
 3 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaTemplate/PR25708.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 0ee2801766a9cc..2d76d3717ab954 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -254,6 +254,10 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
+- Allow access to a public template alias declaration that refers to friend's
+  private nested type.
+  Fixes (#GH25708).
+
 Bug Fixes to Compiler Builtins
 ^^
 
@@ -402,7 +406,7 @@ RISC-V Support
 CUDA/HIP Language Changes
 ^
 
-- PTX is no longer included by default when compiling for CUDA. Using 
+- PTX is no longer included by default when compiling for CUDA. Using
   ``--cuda-include-ptx=all`` will return the old behavior.
 
 CUDA Support
diff --git a/clang/lib/Sema/SemaAccess.cpp b/clang/lib/Sema/SemaAccess.cpp
index 4af3c0f30a8e8a..0c8d15210f439c 100644
--- a/clang/lib/Sema/SemaAccess.cpp
+++ b/clang/lib/Sema/SemaAccess.cpp
@@ -1481,6 +1481,15 @@ static Sema::AccessResult CheckAccess(Sema &S, 
SourceLocation Loc,
   }
 
   EffectiveContext EC(S.CurContext);
+  if (!S.CodeSynthesisContexts.empty()) {
+auto &Active = S.CodeSynthesisContexts.back();
+if (Active.Kind == Sema::CodeSynthesisContext::TemplateInstantiation &&
+Active.Entity)
+  if (auto *RD =
+  dyn_cast_or_null(Active.Entity->getDeclContext()))
+EC.Records.push_back(RD);
+  }
+
   switch (CheckEffectiveAccess(S, EC, Loc, Entity)) {
   case AR_accessible: return Sema::AR_accessible;
   case AR_inaccessible: return Sema::AR_inaccessible;
diff --git a/clang/test/SemaTemplate/PR25708.cpp 
b/clang/test/SemaTemplate/PR25708.cpp
new file mode 100644
index 00..cc2e7551a6abaa
--- /dev/null
+++ b/clang/test/SemaTemplate/PR25708.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++14 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// expected-no-diagnostics
+
+struct FooAccessor
+{
+template 
+using Foo = typename T::Foo;
+};
+
+class Type
+{
+friend struct FooAccessor;
+
+using Foo = int;
+};
+
+int main()
+{
+FooAccessor::Foo t;
+}

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86] Finally handle target of __builtin_ia32_cmp[p|s][s|d] from avx into sse/sse2/avx (PR #84136)

[Simon Pilgrim via cfe-commits]

https://github.com/RKSimon approved this pull request.

LGTM - but @pogo59 needs a headup as it will affect some ongoing documentation 
cleanup work

https://github.com/llvm/llvm-project/pull/84136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[Kristóf Umann via cfe-commits]

https://github.com/Szelethus commented:

Makes perfect sense to me. Can you add a testcase for `std::malloc` or 
something similar?

https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[Kristóf Umann via cfe-commits]

@@ -87,9 +87,11 @@ bool CheckerContext::isCLibraryFunction(const FunctionDecl 
*FD,
   if (!II)
 return false;
 
-  // Look through 'extern "C"' and anything similar invented in the future.
-  // If this function is not in TU directly, it is not a C library function.
-  if (!FD->getDeclContext()->getRedeclContext()->isTranslationUnit())
+  // C library functions are either declared directly within a TU (the common
+  // case) or they are accessed through the namespace `std` (when they are used
+  // in C++ via headers like ).

Szelethus wrote:

Same here.

https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[Kristóf Umann via cfe-commits]

@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the namespace `std`.)

Szelethus wrote:

Might as well go the extra mile and mention an example, like `std::malloc`.

https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[Kristóf Umann via cfe-commits]

https://github.com/Szelethus edited 
https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


NagyDonat wrote:

Currently MallocChecker doesn't use this `CDM::CLibrary` mode in the 
`CallDescription` for `malloc` -- because before this commit it would've been 
incorrect to use it. I'm planning to ensure that functions like `malloc` are 
matched in this mode; but I would like to do it in separate commits.

This means that I cannot create a simple testcase that demonstrates the 
advantage of this commit: the limitations of `isCLibraryFunction` meant that 
many checkers just didn't use it even if they were handling C library 
functions; but I don't know about a case where it was used and incorrect.

However, my followup commits will soon add testcases that demonstrate the 
effects of this change, so I think it's a forgivable sin to merge this without 
a TC.

https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Accept C library functions from the `std` namespace (PR #84469)

[via cfe-commits]

=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -41,12 +41,8 @@ class CallDescription {
 ///  - We also accept calls where the number of arguments or parameters is
 ///greater than the specified value.
 /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
-/// Note that functions whose declaration context is not a TU (e.g.
-/// methods, functions in namespaces) are not accepted as C library
-/// functions.
-/// FIXME: If I understand it correctly, this discards calls where C++ code
-/// refers a C library function through the namespace `std::` via headers
-/// like .
+/// (This mode only matches functions that are declared either directly
+/// within a TU or in the namespace `std`.)

NagyDonat wrote:

I think saying "functions from the C standard library" (at the beginning of 
this comment block) is clear enough, mentioning `malloc` is redundant after it. 
Also, technically, we are not using this mode for `malloc` _yet_. 

https://github.com/llvm/llvm-project/pull/84469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix type of enumerators in incomplete enumerations (PR #84068)

[Aaron Ballman via cfe-commits]

https://github.com/AaronBallman approved this pull request.

Hmm, the rules are different between C and C++, but I think we may be okay. In 
C++:

https://eel.is/c++draft/enum#dcl.enum-5.sentence-6
Following the closing brace of an enum-specifier, each enumerator has the type 
of its enumeration.

In C23 6.7.3.3p12:
During the processing of each enumeration constant in the enumerator list, the 
type of the enumeration constant shall be: 

p15:
The enumeration member type for an enumerated type without fixed underlying 
type upon completion is:
— int if all the values of the enumeration are representable as an int; or,
— the enumerated type.140)

Footnote 140) The integer type selected during processing of the enumerator 
list (before completion) of the enumeration may not be the same as the 
compatible implementation-defined integer type selected for the completed 
enumeration.

So I believe:
```
typedef enum EnumA {
  A
} EnumA;

enum EnumB {
  B,
  B1 = 1,
  B2 = A == B1
};
```
is not an enum compare warning in C++ because `B1` doesn't have an enumeration 
type due to the enumeration not being fully-defined, and is not an enum compare 
warning in C because `A` has type `int` (due to p15) and `B1` has type `int` 
(due to p12).

I think we play a bit fast-and-loose with the way we treat enum constants in C 
in Clang, but that's outside of the scope of this patch. So LGTM aside from 
some tiny nits!

https://github.com/llvm/llvm-project/pull/84068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix type of enumerators in incomplete enumerations (PR #84068)

[Aaron Ballman via cfe-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/84068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix type of enumerators in incomplete enumerations (PR #84068)

[Aaron Ballman via cfe-commits]

@@ -264,11 +264,14 @@ namespace {
 }
 
 QualType Expr::getEnumCoercedType(const ASTContext &Ctx) const {
-  if (isa(this->getType()))
-return this->getType();
-  else if (const auto *ECD = this->getEnumConstantDecl())
-return Ctx.getTypeDeclType(cast(ECD->getDeclContext()));
-  return this->getType();
+  if (isa(getType())) {
+return getType();
+  } else if (const auto *ECD = getEnumConstantDecl()) {
+const auto *ED = cast(ECD->getDeclContext());
+if (ED->isCompleteDefinition())
+  return Ctx.getTypeDeclType(ED);
+  }

AaronBallman wrote:

```suggestion
  if (isa(getType()))
return getType();
  if (const auto *ECD = getEnumConstantDecl()) {
const auto *ED = cast(ECD->getDeclContext());
if (ED->isCompleteDefinition())
  return Ctx.getTypeDeclType(ED);
  }
```
No `else` after `return` via our coding standard, NFC

https://github.com/llvm/llvm-project/pull/84068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix type of enumerators in incomplete enumerations (PR #84068)

[Aaron Ballman via cfe-commits]

@@ -6,7 +6,9 @@ typedef enum EnumA {
 } EnumA;
 
 enum EnumB {
-  B
+  B,

AaronBallman wrote:

It might be good to capture some of what I wrote in the review summary as a 
comment here so it's clear why this is correct in both C and C++.

https://github.com/llvm/llvm-project/pull/84068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4d1d127 - [HIP] Make the HIP default architecture use the enum value (#84400)

[via cfe-commits]

Author: Joseph Huber
Date: 2024-03-08T06:54:52-06:00
New Revision: 4d1d1271b8612c72e0020c9d9f42d2ef70f717e7

URL: 
https://github.com/llvm/llvm-project/commit/4d1d1271b8612c72e0020c9d9f42d2ef70f717e7
DIFF: 
https://github.com/llvm/llvm-project/commit/4d1d1271b8612c72e0020c9d9f42d2ef70f717e7.diff

LOG: [HIP] Make the HIP default architecture use the enum value (#84400)

Summary:
This default enum is used in other places, we should keep it consistent.

Added: 


Modified: 
clang/include/clang/Basic/Cuda.h
clang/lib/Driver/Driver.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 916cb4b7ef34a7..3e77a74c7c0092 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -123,7 +123,7 @@ enum class CudaArch {
   LAST,
 
   CudaDefault = CudaArch::SM_52,
-  HIPDefault = CudaArch::GFX803,
+  HIPDefault = CudaArch::GFX906,
 };
 
 static inline bool IsNVIDIAGpuArch(CudaArch A) {

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 96e6ad77f5e50d..fce43430a91374 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -3373,7 +3373,7 @@ class OffloadingActionBuilder final {
  const Driver::InputList &Inputs)
 : CudaActionBuilderBase(C, Args, Inputs, Action::OFK_HIP) {
 
-  DefaultCudaArch = CudaArch::GFX906;
+  DefaultCudaArch = CudaArch::HIPDefault;
 
   if (Args.hasArg(options::OPT_fhip_emit_relocatable,
   options::OPT_fno_hip_emit_relocatable)) {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HIP] Make the HIP default architecture use the enum value (PR #84400)

[Joseph Huber via cfe-commits]

https://github.com/jhuber6 closed 
https://github.com/llvm/llvm-project/pull/84400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [Sema] WIP: Fix dependence of DREs in lambdas with an explicit object parameter (PR #84473)

[via cfe-commits]

https://github.com/Sirraide created 
https://github.com/llvm/llvm-project/pull/84473

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]](https://eel.is/c++draft/temp.dep.expr) states that
> An 
> [id-expression](https://eel.is/c++draft/expr.prim.id.general#nt:id-expression)
>  is type-dependent if [...] its terminal name is
>  - associated by name lookup with an entity captured by copy 
> ([[expr.prim.lambda.capture]](https://eel.is/c++draft/expr.prim.lambda.capture))
>  in a 
> [lambda-expression](https://eel.is/c++draft/expr.prim.lambda.general#nt:lambda-expression)
>  that has an explicit object parameter whose type is dependent 
> ([[dcl.fct]](https://eel.is/c++draft/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:
```c++
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:
1. we’re treating by-reference captures as dependent rather than by-value 
captures;
2. tree transform doesn’t seem to check whether referring to such a by-value 
capture makes a DRE dependent;
3. 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;
4. we also don’t check for implicit by-value captures;
5. 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:
1. This is just due to a misplaced `!`, so that’s an easy fix.
2. This entails checking if the DRE is captured by value by a lambda with an 
explicit object parameter in `TreeTransform::TransformDeclRefExpr`. 
That’s also an easy fix.
3. 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.
4. Check for implicit captures as well in 3.
5. 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.

>From 870e6a6def8c17859ffbb30906f91912268f872d Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Fri, 8 Mar 2024 11:55:42 +0100
Subject: [PATCH 1/2] [Clang] Fix dependence of DREs in lambdas with an
 explicit object parameter

---
 clang/lib/Sema/SemaExpr.cpp| 44 +---
 clang/lib/Sema/TreeTransform.h |  4 +-
 clang/test/SemaCXX/cxx2b-deducing-this.cpp | 81 ++
 3 files changed, 116 insertions(+), 13 deletions(-)

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(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 Captu

[clang] [Clang] [Sema] WIP: Fix dependence of DREs in lambdas with an explicit object parameter (PR #84473)

[via cfe-commits]

https://github.com/Sirraide converted_to_draft 
https://github.com/llvm/llvm-project/pull/84473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits