[clang] 4d62929 - [C++20] [Modules] Disambuguous Clang module and C++20 Named module further

2024-03-12 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-13T13:57:52+08:00
New Revision: 4d62929852849f768d7397f634cfdebc85de96a4

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

LOG: [C++20] [Modules] Disambuguous Clang module and C++20 Named module further

This patch tries to make the boundary of clang module and C++20 named
module more clear.

The changes included:

- Rename `TranslationUnitKind::TU_Module` to
  `TranslationUnitKind::TU_ClangModule`.
- Rename `Sema::ActOnModuleInclude` to `Sema::ActOnAnnotModuleInclude`.
- Rename `ActOnModuleBegin` to `Sema::ActOnAnnotModuleBegin`.
- Rename `Sema::ActOnModuleEnd` to `Sema::ActOnAnnotModuleEnd`.
- Removes a warning if we're trying to compile a non-module unit as
  C++20 module unit. This is not actually useful and makes (the future)
  implementation unnecessarily complex.

This patch meant to be a NFC fix. But it shows that it fixed a bug
suprisingly that previously we would surppress the unused-value warning
in named modules. Because it shares the same logic with clang modules,
which has headers semantics. This shows the change is meaningful.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Frontend/FrontendActions.h
clang/include/clang/Sema/Sema.h
clang/lib/Parse/Parser.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaModule.cpp
clang/test/CXX/module/dcl.dcl/dcl.module/dcl.module.interface/p1.cppm
clang/test/Modules/pr72828.cppm

Removed: 
clang/test/Modules/missing-module-declaration.cppm



diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c54105507753eb..d7ab1635cf12bc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11516,8 +11516,6 @@ def err_module_not_defined : Error<
 def err_module_redeclaration : Error<
   "translation unit contains multiple module declarations">;
 def note_prev_module_declaration : Note<"previous module declaration is here">;
-def err_module_declaration_missing : Error<
-  "missing 'export module' declaration in module interface unit">;
 def err_module_declaration_missing_after_global_module_introducer : Error<
   "missing 'module' declaration at end of global module fragment "
   "introduced here">;

diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index 862952d336ef31..08fc706e3cbf74 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -560,11 +560,6 @@ class LangOptions : public LangOptionsBase {
 return getCompilingModule() != CMK_None;
   }
 
-  /// Are we compiling a standard c++ module interface?
-  bool isCompilingModuleInterface() const {
-return getCompilingModule() == CMK_ModuleInterface;
-  }
-
   /// Are we compiling a module implementation?
   bool isCompilingModuleImplementation() const {
 return !isCompilingModule() && !ModuleName.empty();
@@ -993,8 +988,8 @@ enum TranslationUnitKind {
   /// not complete.
   TU_Prefix,
 
-  /// The translation unit is a module.
-  TU_Module,
+  /// The translation unit is a clang module.
+  TU_ClangModule,
 
   /// The translation unit is a is a complete translation unit that we might
   /// incrementally extend later.

diff  --git a/clang/include/clang/Frontend/FrontendActions.h 
b/clang/include/clang/Frontend/FrontendActions.h
index 8441af2ee3e718..a620ddfc40447d 100644
--- a/clang/include/clang/Frontend/FrontendActions.h
+++ b/clang/include/clang/Frontend/FrontendActions.h
@@ -125,7 +125,7 @@ class GenerateModuleAction : public ASTFrontendAction {
  StringRef InFile) override;
 
   TranslationUnitKind getTranslationUnitKind() override {
-return TU_Module;
+return TU_ClangModule;
   }
 
   bool hasASTFileSupport() const override { return false; }
@@ -138,7 +138,9 @@ class GenerateInterfaceStubsAction : public 
ASTFrontendAction {
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
-  TranslationUnitKind getTranslationUnitKind() override { return TU_Module; }
+  TranslationUnitKind getTranslationUnitKind() override {
+return TU_ClangModule;
+  }
   bool hasASTFileSupport() const override { return false; }
 };
 
@@ -159,6 +161,8 @@ class GenerateModuleInterfaceAction : public 
GenerateModuleAction {
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
+  TranslationUnitKind getTranslationUnitKind() override { return TU_Complete; }
+
   std::unique_ptr
   CreateOutputFile(CompilerInstance 

[clang] [llvm] [WebAssembly] Implement an alternative translation for -wasm-enable-sjlj (PR #84137)

2024-03-12 Thread YAMAMOTO Takashi via cfe-commits

https://github.com/yamt updated https://github.com/llvm/llvm-project/pull/84137

>From 6c1bfa0aa292d81102a9aeb86ca4264516beb634 Mon Sep 17 00:00:00 2001
From: YAMAMOTO Takashi 
Date: Fri, 9 Feb 2024 15:49:55 +0900
Subject: [PATCH 01/13] [WebAssembly] Implement an alternative translation for
 -wasm-enable-sjlj

Instead of maintaining per-function-invocation malloc()'ed tables to
track which functions each label belongs to, store the equivalent info
in jump buffers (jmp_buf) themselves.

Also, use a less emscripten-looking ABI symbols:

saveSetjmp -> __wasm_sjlj_setjmp
testSetjmp -> __wasm_sjlj_test
getTempRet0-> (removed)
__wasm_longjmp -> __wasm_sjlj_longjmp

Enabled with:

-mllvm -wasm-enable-sjlj -mllvm -experimental-wasm-enable-alt-sjlj

(-experimental-wasm-enable-alt-sjlj is the new option this change
introduces.)

While I want to use this for WASI, it should work for emscripten as well.

An example runtime and a few tests:
https://github.com/yamt/garbage/tree/wasm-sjlj-alt2/wasm/longjmp

Discussion:
https://docs.google.com/document/d/1ZvTPT36K5jjiedF8MCXbEmYjULJjI723aOAks1IdLLg/edit
---
 clang/lib/Driver/ToolChains/WebAssembly.cpp   |  14 ++
 .../MCTargetDesc/WebAssemblyMCTargetDesc.cpp  |   3 +
 .../MCTargetDesc/WebAssemblyMCTargetDesc.h|   1 +
 .../WebAssemblyLowerEmscriptenEHSjLj.cpp  | 174 +++---
 .../WebAssembly/WebAssemblyTargetMachine.cpp  |   4 +
 5 files changed, 131 insertions(+), 65 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/WebAssembly.cpp 
b/clang/lib/Driver/ToolChains/WebAssembly.cpp
index b8c2573d6265fb..2e7c8e6e8d13f7 100644
--- a/clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ b/clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -386,6 +386,20 @@ void WebAssembly::addClangTargetOptions(const ArgList 
,
   // Backend needs '-exception-model=wasm' to use Wasm EH instructions
   CC1Args.push_back("-exception-model=wasm");
 }
+
+if (Opt.starts_with("-experimental-wasm-enable-alt-sjlj")) {
+  // '-mllvm -experimental-wasm-enable-alt-sjlj'  should be used with
+  // '-mllvm -wasm-enable-sjlj'
+  bool HasWasmEnableSjlj = false;
+  for (const Arg *A : DriverArgs.filtered(options::OPT_mllvm)) {
+if (StringRef(A->getValue(0)) == "-wasm-enable-sjlj")
+  HasWasmEnableSjlj = true;
+  }
+  if (!HasWasmEnableSjlj)
+getDriver().Diag(diag::err_drv_argument_only_allowed_with)
+<< "-mllvm -experimental-wasm-enable-alt-sjlj"
+<< "-mllvm -wasm-enable-sjlj";
+}
   }
 }
 
diff --git 
a/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.cpp 
b/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.cpp
index e8f58a19d25e3b..7f15742367be09 100644
--- a/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.cpp
+++ b/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.cpp
@@ -54,6 +54,9 @@ cl::opt
 // setjmp/longjmp handling using wasm EH instrutions
 cl::opt WebAssembly::WasmEnableSjLj(
 "wasm-enable-sjlj", cl::desc("WebAssembly setjmp/longjmp handling"));
+cl::opt WebAssembly::WasmEnableAltSjLj(
+"experimental-wasm-enable-alt-sjlj",
+cl::desc("Use experimental alternate ABI for --wasm-enable-sjlj"));
 
 static MCAsmInfo *createMCAsmInfo(const MCRegisterInfo & /*MRI*/,
   const Triple ,
diff --git a/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h 
b/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
index 15aeaaeb8c4a4e..d23de9d407d894 100644
--- a/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
+++ b/llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
@@ -44,6 +44,7 @@ extern cl::opt WasmEnableEmEH;   // asm.js-style EH
 extern cl::opt WasmEnableEmSjLj; // asm.js-style SjLJ
 extern cl::opt WasmEnableEH; // EH using Wasm EH instructions
 extern cl::opt WasmEnableSjLj;   // SjLj using Wasm EH instructions
+extern cl::opt WasmEnableAltSjLj; // Alt ABI for WasmEnableSjLj
 
 enum OperandType {
   /// Basic block label in a branch construct.
diff --git a/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp 
b/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
index 77e6640d5a8224..fc76757011f5d8 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
@@ -300,6 +300,7 @@ class WebAssemblyLowerEmscriptenEHSjLj final : public 
ModulePass {
   bool EnableEmEH; // Enable Emscripten exception handling
   bool EnableEmSjLj;   // Enable Emscripten setjmp/longjmp handling
   bool EnableWasmSjLj; // Enable Wasm setjmp/longjmp handling
+  bool EnableWasmAltSjLj; // Alt ABI for EnableWasmSjLj
   bool DoSjLj; // Whether we actually perform setjmp/longjmp handling
 
   GlobalVariable *ThrewGV = nullptr;  // __THREW__ (Emscripten)
@@ -368,7 +369,8 @@ class 

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

2024-03-12 Thread Garvit Gupta via cfe-commits

quic-garvgupt wrote:

Thanks for the prompt reply and latest patchset.

1. Do we need to add documentation in RISCVUsage.rst file for xsfcease?
2. Also, as we are adding cease instruction in this PR, can we rename the PR to 
include the cease instruction as well?

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


[clang] [clang] Add reference to documentation of SysVABI (PR #85022)

2024-03-12 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Zepp (ZeppLu)


Changes

The documentation has already been there in `AttrDocs.td`, just lacks proper 
reference

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


1 Files Affected:

- (modified) clang/include/clang/Basic/Attr.td (+1-1) 


``diff
diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 63efd85dcd4e58..67d87eca16ede8 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2934,7 +2934,7 @@ def Suppress : DeclOrStmtAttr {
 def SysVABI : DeclOrTypeAttr {
   let Spellings = [GCC<"sysv_abi">];
 //  let Subjects = [Function, ObjCMethod];
-  let Documentation = [Undocumented];
+  let Documentation = [SysVABIDocs];
 }
 
 def ThisCall : DeclOrTypeAttr {

``




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


[clang] [clang] Add reference to documentation of SysVABI (PR #85022)

2024-03-12 Thread via cfe-commits

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

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


[clang] [clang] Add reference to documentation of SysVABI (PR #85022)

2024-03-12 Thread via cfe-commits

https://github.com/ZeppLu created 
https://github.com/llvm/llvm-project/pull/85022

The documentation has already been there in `AttrDocs.td`, just lacks proper 
reference

>From 814db124d1f9bba3fe5878b93bc4cad520160005 Mon Sep 17 00:00:00 2001
From: Zepp 
Date: Wed, 13 Mar 2024 13:25:43 +0800
Subject: [PATCH] [clang] Add reference to documentation of SysVABI

---
 clang/include/clang/Basic/Attr.td | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 63efd85dcd4e58..67d87eca16ede8 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2934,7 +2934,7 @@ def Suppress : DeclOrStmtAttr {
 def SysVABI : DeclOrTypeAttr {
   let Spellings = [GCC<"sysv_abi">];
 //  let Subjects = [Function, ObjCMethod];
-  let Documentation = [Undocumented];
+  let Documentation = [SysVABIDocs];
 }
 
 def ThisCall : DeclOrTypeAttr {

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


[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

2024-03-12 Thread Craig Topper via cfe-commits

https://github.com/topperc updated 
https://github.com/llvm/llvm-project/pull/83896

>From f22a5cd30f77b2043f9c1f7f4482fad87fb79250 Mon Sep 17 00:00:00 2001
From: Craig Topper 
Date: Mon, 4 Mar 2024 11:24:34 -0800
Subject: [PATCH 1/8] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1
 instructions.

These were in LLVM 17 but removed from LLVM 18 due to an incorrect
extension name being used.

This restores them with new extension names that match SiFive's
downstream compiler. The extension name has been used internally
for some time. It uses XSiFive instead of XSf like the newer extensions.

The spec for the instructions is here 
https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
though the extension name is not listed.

Column width in the extension printing had to be changed to accomodate
a longer extension name.
---
 .../test/Preprocessor/riscv-target-features.c |  18 +
 llvm/docs/RISCVUsage.rst  |   6 +
 llvm/lib/Support/RISCVISAInfo.cpp |   4 +-
 .../RISCV/Disassembler/RISCVDisassembler.cpp  |   6 +
 llvm/lib/Target/RISCV/RISCVFeatures.td|  16 +
 llvm/lib/Target/RISCV/RISCVInstrInfoXSf.td|  22 ++
 llvm/unittests/Support/RISCVISAInfoTest.cpp   | 326 +-
 7 files changed, 235 insertions(+), 163 deletions(-)

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 1a15be1c6e4dc1..b8ea4fd738fdf7 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -61,6 +61,8 @@
 // CHECK-NOT: __riscv_xsfvfwmaccqqq {{.*$}}
 // CHECK-NOT: __riscv_xsfqmaccdod {{.*$}}
 // CHECK-NOT: __riscv_xsfvqmaccqoq {{.*$}}
+// CHECK-NOT: __riscv_sifivecdiscarddlone {{.*$}}
+// CHECK-NOT: __riscv_sifivecflushdlone {{.*$}}
 // CHECK-NOT: __riscv_xtheadba {{.*$}}
 // CHECK-NOT: __riscv_xtheadbb {{.*$}}
 // CHECK-NOT: __riscv_xtheadbs {{.*$}}
@@ -557,6 +559,22 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-XSFVQMACCQOQ-EXT %s
 // CHECK-XSFVQMACCQOQ-EXT: __riscv_xsfvqmaccqoq 100{{$}}
 
+// RUN: %clang --target=riscv32-unknown-linux-gnu \
+// RUN:   -march=rv32ixsifivecdiscarddlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECDISCARDDLONE-EXT %s
+// RUN: %clang --target=riscv64-unknown-linux-gnu \
+// RUN:   -march=rv64ixsifivecdiscarddlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECDISCARDDLONE-EXT %s
+// CHECK-XSIFIVECDISCARDDLONE-EXT: __riscv_xsifivecdiscarddlone 100{{$}}
+
+// RUN: %clang --target=riscv32-unknown-linux-gnu \
+// RUN:   -march=rv32ixsifivecflushdlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECFLUSHDLONE-EXT %s
+// RUN: %clang --target=riscv64-unknown-linux-gnu \
+// RUN:   -march=rv64ixsifivecflushdlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECFLUSHDLONE-EXT %s
+// CHECK-XSIFIVECFLUSHDLONE-EXT: __riscv_xsifivecflushdlone 100{{$}}
+
 // RUN: %clang --target=riscv32-unknown-linux-gnu \
 // RUN:   -march=rv32ixtheadba -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-XTHEADBA-EXT %s
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index a1de8596480da9..69e823eac25fc6 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -362,6 +362,12 @@ The current vendor extensions supported are:
 ``XCVbi``
   LLVM implements `version 1.0.0 of the CORE-V immediate branching custom 
instructions specification 
`__
 by OpenHW Group.  All instructions are prefixed with `cv.` as described in the 
specification. These instructions are only available for riscv32 at this time.
 
+``XSiFivecdiscarddlone``
+  LLVM implements `the SiFive cdiscard.d.l1 instruction specified in 
`_
 by SiFive.
+
+``XSiFivecflushdlone``
+  LLVM implements `the SiFive cflush.d.l1 instruction specified in 
`_
 by SiFive.
+
 Experimental C Intrinsics
 =
 
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6eec03fd6f7082..17f39223b99bac 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -95,6 +95,8 @@ static const RISCVSupportedExtension SupportedExtensions[] = {
 {"xsfvfwmaccqqq", {1, 0}},
 {"xsfvqmaccdod", {1, 0}},
 {"xsfvqmaccqoq", {1, 0}},
+{"xsifivecdiscarddlone", {1, 0}},
+{"xsifivecflushdlone", {1, 0}},
 {"xtheadba", {1, 0}},
 {"xtheadbb", {1, 0}},
 {"xtheadbs", {1, 0}},
@@ -258,7 +260,7 @@ static void PrintExtension(StringRef Name, StringRef 
Version,
StringRef Description) {
   

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

2024-03-12 Thread Craig Topper via cfe-commits

topperc wrote:

> Thanks for clearing the confusion around whether rs1 would be optional or 
> not. Can we also add lit tests for the aliases?

I already addded tests 
https://github.com/llvm/llvm-project/pull/83896/commits/f6f43e9f8ffa8b58d63178d28c826d0009de2f3b

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


[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

2024-03-12 Thread Garvit Gupta via cfe-commits

quic-garvgupt wrote:

Thanks for clearing the confusion around whether rs1 would be optional or not. 
Can we also add lit tests for the aliases? 

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread Yingchi Long via cfe-commits

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


https://github.com/llvm/llvm-project/pull/84874
___
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)

2024-03-12 Thread Younan Zhang via cfe-commits

zyn0217 wrote:

> I think some `static_assert` statements are required to demonstrate it does 
> deduce the type of template parameters correctly.

Added. Although the patch doesn't touch that type deduction part and thus they 
are theoretically not affected.


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)

2024-03-12 Thread Younan Zhang via cfe-commits

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

>From 25f493da55e5cd7d46dda6fca6062aa56b6a3fd0 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/7] 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 690fc7ed271a3db..f5dc956cf5fc4aa 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -344,6 +344,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 9cebaff63bb0dbe..7aed4d5cbc002e2 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 cfc1c3b34947880..a5520e19a14327d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10145,6 +10145,8 @@ class Sema final {
 
   /// We are building deduction guides for a class.
   BuildingDeductionGuides,
+
+  TypeAliasTemplateInstantiation,
 } Kind;
 
 /// Was the enclosing context a non-instantiation SFINAE context?
@@ -10234,6 +10236,12 @@ class Sema final {
   FunctionDecl *Entity, ExceptionSpecification,
   SourceRange InstantiationRange = SourceRange());
 
+/// Note that we are instantiating a type alias template declaration.
+InstantiatingTemplate(Sema , SourceLocation PointOfInstantiation,
+  TypeAliasTemplateDecl *Template,
+  ArrayRef TemplateArgs,
+  SourceRange InstantiationRange = SourceRange());
+
 /// Note that we are instantiating a default argument in a
 /// template-id.
 InstantiatingTemplate(Sema , SourceLocation PointOfInstantiation,
diff --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index 50338bfa670f830..5f0299dfa32e24b 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -452,6 +452,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 a8e387e35fb4c90..0b84d83b4fb4b81 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -615,14 +615,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 = 

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

2024-03-12 Thread Younan Zhang via cfe-commits

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

>From 25f493da55e5cd7d46dda6fca6062aa56b6a3fd0 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 20 Feb 2024 14:54:14 +0800
Subject: [PATCH 1/7] 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 690fc7ed271a3db..f5dc956cf5fc4aa 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -344,6 +344,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 9cebaff63bb0dbe..7aed4d5cbc002e2 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 cfc1c3b34947880..a5520e19a14327d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10145,6 +10145,8 @@ class Sema final {
 
   /// We are building deduction guides for a class.
   BuildingDeductionGuides,
+
+  TypeAliasTemplateInstantiation,
 } Kind;
 
 /// Was the enclosing context a non-instantiation SFINAE context?
@@ -10234,6 +10236,12 @@ class Sema final {
   FunctionDecl *Entity, ExceptionSpecification,
   SourceRange InstantiationRange = SourceRange());
 
+/// Note that we are instantiating a type alias template declaration.
+InstantiatingTemplate(Sema , SourceLocation PointOfInstantiation,
+  TypeAliasTemplateDecl *Template,
+  ArrayRef TemplateArgs,
+  SourceRange InstantiationRange = SourceRange());
+
 /// Note that we are instantiating a default argument in a
 /// template-id.
 InstantiatingTemplate(Sema , SourceLocation PointOfInstantiation,
diff --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index 50338bfa670f830..5f0299dfa32e24b 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -452,6 +452,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 a8e387e35fb4c90..0b84d83b4fb4b81 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -615,14 +615,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 = 

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

2024-03-12 Thread Qizhi Hu via cfe-commits

jcsxky wrote:

Probably I haven't understand these code deeply and I have some confusions on 
this patch. I wonder has this patch solved essential issue, or it just fixed 
the crash. I think some `static_assert` statements are required to demonstrate 
it does deduce the type of template parameters correctly.

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] [llvm] [clang][HLSL][SPRI-V] Add convergence intrinsics (PR #80680)

2024-03-12 Thread Sameer Sahasrabuddhe via cfe-commits
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= ,
Nathan =?utf-8?q?Gauër?= 
Message-ID:
In-Reply-To: 



@@ -1130,8 +1130,96 @@ struct BitTest {
 
   static BitTest decodeBitTestBuiltin(unsigned BuiltinID);
 };
+
+// Returns the first convergence entry/loop/anchor instruction found in |BB|.
+// std::nullopt otherwise.
+std::optional getConvergenceToken(llvm::BasicBlock *BB) 
{
+  for (auto  : *BB) {

ssahasra wrote:

This kind of map will be needed in more places as we continue to introduces 
uses of these convergence tokens. I have a simple Analysis in my upstreaming 
pipeline that produces such a map, but it's really very simple. You can wait 
for that, or just feel free to start your own.

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


[clang] 5d7796e - [NFC] [C++20] [Modules] Refactor ReducedBMIGenerator

2024-03-12 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-13T11:22:32+08:00
New Revision: 5d7796e674224be54c48a8db981f4134845bcc7c

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

LOG: [NFC] [C++20] [Modules] Refactor ReducedBMIGenerator

Changes:
- Don't lookup the emitting module from HeaderSearch. We will use the
  module from the ASTContext directly.
- Remove some useless arguments. Let's addback in the future if
  required.

Added: 


Modified: 
clang/include/clang/Serialization/ASTWriter.h
clang/lib/Frontend/FrontendActions.cpp
clang/lib/Serialization/GeneratePCH.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index e5db486a71a490..3ed9803fa3745b 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -868,6 +868,8 @@ class PCHGenerator : public SemaConsumer {
 return SemaPtr->getDiagnostics();
   }
 
+  virtual Module *getEmittingModule(ASTContext );
+
 public:
   PCHGenerator(const Preprocessor , InMemoryModuleCache ,
StringRef OutputFile, StringRef isysroot,
@@ -887,10 +889,12 @@ class PCHGenerator : public SemaConsumer {
 };
 
 class ReducedBMIGenerator : public PCHGenerator {
+protected:
+  virtual Module *getEmittingModule(ASTContext ) override;
+
 public:
   ReducedBMIGenerator(const Preprocessor , InMemoryModuleCache ,
-  StringRef OutputFile, std::shared_ptr Buffer,
-  bool IncludeTimestamps);
+  StringRef OutputFile);
 
   void HandleTranslationUnit(ASTContext ) override;
 };

diff  --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index 50338bfa670f83..81fcd8d5ae9bd3 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -293,11 +293,9 @@ 
GenerateModuleInterfaceAction::CreateOutputFile(CompilerInstance ,
 std::unique_ptr
 GenerateReducedModuleInterfaceAction::CreateASTConsumer(CompilerInstance ,
 StringRef InFile) {
-  auto Buffer = std::make_shared();
-  return std::make_unique(
-  CI.getPreprocessor(), CI.getModuleCache(),
-  CI.getFrontendOpts().OutputFile, Buffer,
-  /*IncludeTimestamps=*/+CI.getFrontendOpts().IncludeTimestamps);
+  return std::make_unique(CI.getPreprocessor(),
+   CI.getModuleCache(),
+   
CI.getFrontendOpts().OutputFile);
 }
 
 bool GenerateHeaderUnitAction::BeginSourceFileAction(CompilerInstance ) {

diff  --git a/clang/lib/Serialization/GeneratePCH.cpp 
b/clang/lib/Serialization/GeneratePCH.cpp
index 2b511b2d5a90a2..f54db36d4a0199 100644
--- a/clang/lib/Serialization/GeneratePCH.cpp
+++ b/clang/lib/Serialization/GeneratePCH.cpp
@@ -41,6 +41,21 @@ PCHGenerator::PCHGenerator(
 PCHGenerator::~PCHGenerator() {
 }
 
+Module *PCHGenerator::getEmittingModule(ASTContext &) {
+  Module *M = nullptr;
+
+  if (PP.getLangOpts().isCompilingModule()) {
+M = PP.getHeaderSearchInfo().lookupModule(PP.getLangOpts().CurrentModule,
+  SourceLocation(),
+  /*AllowSearch*/ false);
+if (!M)
+  assert(PP.getDiagnostics().hasErrorOccurred() &&
+ "emitting module but current module doesn't exist");
+  }
+
+  return M;
+}
+
 void PCHGenerator::HandleTranslationUnit(ASTContext ) {
   // Don't create a PCH if there were fatal failures during module loading.
   if (PP.getModuleLoader().HadFatalFailure)
@@ -50,16 +65,7 @@ void PCHGenerator::HandleTranslationUnit(ASTContext ) {
   if (hasErrors && !AllowASTWithErrors)
 return;
 
-  Module *Module = nullptr;
-  if (PP.getLangOpts().isCompilingModule()) {
-Module = PP.getHeaderSearchInfo().lookupModule(
-PP.getLangOpts().CurrentModule, SourceLocation(),
-/*AllowSearch*/ false);
-if (!Module) {
-  assert(hasErrors && "emitting module but current module doesn't exist");
-  return;
-}
-  }
+  Module *Module = getEmittingModule(Ctx);
 
   // Errors that do not prevent the PCH from being written should not cause the
   // overall compilation to fail either.
@@ -84,16 +90,22 @@ ASTDeserializationListener 
*PCHGenerator::GetASTDeserializationListener() {
 
 ReducedBMIGenerator::ReducedBMIGenerator(const Preprocessor ,
  InMemoryModuleCache ,
- StringRef OutputFile,
- std::shared_ptr Buffer,
- bool IncludeTimestamps)
+ StringRef OutputFile)
 : 

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-12 Thread Ian Anderson via cfe-commits

ian-twilightcoder wrote:

> I'm not excited by the complexity we are moving toward with the builtin 
> headers. But I don't have any alternatives.
> 
> Given the situation we are in, I think the change is ok. But I'd like someone 
> else to look at it as it is tricky to reason about it. No blockers from me 
> but want more people to review the change.

It's not my favorite. Hopefully Apple will be able to move off of 
`-fbuiltin-headers-in-system-modules` in a few years, including the Linux and 
Windows module maps in Swift. There may not be any other users, I haven't heard 
any other feedback about the new modules behavior yet. When 
`-fbuiltin-headers-in-system-modules` goes away, things become simpler than 
they were since modules were introduced.

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


[clang] [Clang][Comments] Add argument parsing for @throw @throws @exception (PR #84726)

2024-03-12 Thread via cfe-commits

https://github.com/hdoc updated https://github.com/llvm/llvm-project/pull/84726

>From ec3f444913d9162de4494cdb09b336b1b00380fa Mon Sep 17 00:00:00 2001
From: hdoc 
Date: Mon, 11 Mar 2024 01:13:25 -0700
Subject: [PATCH 1/3] Comment parsing: add argument parsing for @throw @throws
 @exception

Doxygen allows for the @throw, @throws, and @exception commands to
have an attached argument indicating the type being thrown. Currently,
Clang's AST parsing doesn't support parsing out this argument from doc
comments. The result is missing compatibility with Doxygen.

We would find it helpful if the AST exposed these thrown types as
BlockCommandComment arguments so that we could generate better
documentation.

This PR implements parsing of arguments for the @throw, @throws, and
@exception commands. Each command can only have one argument, matching
the semantics of Doxygen. We have also added unit tests to validate
the functionality.
---
 clang/include/clang/AST/CommentCommands.td |   6 +-
 clang/include/clang/AST/CommentParser.h|   3 +
 clang/lib/AST/CommentParser.cpp| 133 
 clang/unittests/AST/CommentParser.cpp  | 235 -
 4 files changed, 373 insertions(+), 4 deletions(-)

diff --git a/clang/include/clang/AST/CommentCommands.td 
b/clang/include/clang/AST/CommentCommands.td
index e839031752cdd8..06b2fa9b5531c6 100644
--- a/clang/include/clang/AST/CommentCommands.td
+++ b/clang/include/clang/AST/CommentCommands.td
@@ -132,9 +132,9 @@ def Tparam : BlockCommand<"tparam"> { let IsTParamCommand = 
1; }
 // HeaderDoc command for template parameter documentation.
 def Templatefield : BlockCommand<"templatefield"> { let IsTParamCommand = 1; }
 
-def Throws: BlockCommand<"throws"> { let IsThrowsCommand = 1; }
-def Throw : BlockCommand<"throw"> { let IsThrowsCommand = 1; }
-def Exception : BlockCommand<"exception"> { let IsThrowsCommand = 1; }
+def Throws: BlockCommand<"throws"> { let IsThrowsCommand = 1; let NumArgs 
= 1; }
+def Throw : BlockCommand<"throw"> { let IsThrowsCommand = 1; let NumArgs = 
1; }
+def Exception : BlockCommand<"exception"> { let IsThrowsCommand = 1; let 
NumArgs = 1;}
 
 def Deprecated : BlockCommand<"deprecated"> {
   let IsEmptyParagraphAllowed = 1;
diff --git a/clang/include/clang/AST/CommentParser.h 
b/clang/include/clang/AST/CommentParser.h
index e11e818b1af0a1..5884a25d007851 100644
--- a/clang/include/clang/AST/CommentParser.h
+++ b/clang/include/clang/AST/CommentParser.h
@@ -100,6 +100,9 @@ class Parser {
   ArrayRef
   parseCommandArgs(TextTokenRetokenizer , unsigned NumArgs);
 
+  ArrayRef
+  parseThrowCommandArgs(TextTokenRetokenizer , unsigned NumArgs);
+
   BlockCommandComment *parseBlockCommand();
   InlineCommandComment *parseInlineCommand();
 
diff --git a/clang/lib/AST/CommentParser.cpp b/clang/lib/AST/CommentParser.cpp
index 8adfd85d0160c3..c70fa1b05cb241 100644
--- a/clang/lib/AST/CommentParser.cpp
+++ b/clang/lib/AST/CommentParser.cpp
@@ -75,6 +75,25 @@ class TextTokenRetokenizer {
 return *Pos.BufferPtr;
   }
 
+  char peekNext(unsigned offset) const {
+assert(!isEnd());
+assert(Pos.BufferPtr != Pos.BufferEnd);
+if (Pos.BufferPtr + offset <= Pos.BufferEnd) {
+  return *(Pos.BufferPtr + offset);
+} else {
+  return '\0';
+}
+  }
+
+  void peekNextToken(SmallString<32> ) const {
+unsigned offset = 1;
+char C = peekNext(offset++);
+while (!isWhitespace(C) && C != '\0') {
+  WordText.push_back(C);
+  C = peekNext(offset++);
+}
+  }
+
   void consumeChar() {
 assert(!isEnd());
 assert(Pos.BufferPtr != Pos.BufferEnd);
@@ -89,6 +108,29 @@ class TextTokenRetokenizer {
 }
   }
 
+  /// Extract a template type
+  bool lexTemplateType(SmallString<32> ) {
+unsigned IncrementCounter = 0;
+while (!isEnd()) {
+  const char C = peek();
+  WordText.push_back(C);
+  consumeChar();
+  switch (C) {
+  default:
+break;
+  case '<': {
+IncrementCounter++;
+  } break;
+  case '>': {
+IncrementCounter--;
+if (!IncrementCounter)
+  return true;
+  } break;
+  }
+}
+return false;
+  }
+
   /// Add a token.
   /// Returns true on success, false if there are no interesting tokens to
   /// fetch from lexer.
@@ -149,6 +191,76 @@ class TextTokenRetokenizer {
 addToken();
   }
 
+  /// Extract a type argument
+  bool lexDataType(Token ) {
+if (isEnd())
+  return false;
+Position SavedPos = Pos;
+consumeWhitespace();
+SmallString<32> NextToken;
+SmallString<32> WordText;
+const char *WordBegin = Pos.BufferPtr;
+SourceLocation Loc = getSourceLocation();
+StringRef ConstVal = StringRef("const");
+bool ConstPointer = false;
+
+while (!isEnd()) {
+  const char C = peek();
+  if (!isWhitespace(C)) {
+if (C == '<') {
+  if (!lexTemplateType(WordText))
+return false;
+} else {
+  

[clang] [Concepts] Add Decls from the outer scope of the current lambda for conversion function constraints (PR #83420)

2024-03-12 Thread Younan Zhang via cfe-commits

zyn0217 wrote:

@cor3ntin WDYT?

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


[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-12 Thread Volodymyr Sapsai via cfe-commits

vsapsai wrote:

I'm not excited by the complexity we are moving toward with the builtin 
headers. But I don't have any alternatives.

Given the situation we are in, I think the change is ok. But I'd like someone 
else to look at it as it is tricky to reason about it. No blockers from me but 
want more people to review the change.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;

dougsonos wrote:

Another way to put it: when one reads through the ~100 lines of diagnostics in 
DiagnosticSemaKinds.td, I find it helpful that %0 is always the name of the 
effect and %1 is always a function (or block) name.

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


[clang] [clang] Stub out gcc_struct attribute (PR #71148)

2024-03-12 Thread John McCall via cfe-commits

rjmccall wrote:

> @rjmccall Re asking GCC developers about gcc_struct on non-x86: 
> https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs 
> aren't really worried about this or I can't properly write emails (what's 
> totally possible).

Alright, well, we tried.  I think rolling forward with what your proposal on 
non-x86 platforms is reasonable.

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


[clang] [clang] Stub out gcc_struct attribute (PR #71148)

2024-03-12 Thread Dan Klishch via cfe-commits

DanShaders wrote:

@rjmccall Re asking GCC developers about gcc_struct on non-x86: 
https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs 
aren't really worried about this or I can't properly write emails (what's 
totally possible). 

@MaskRay Any chance you can look at this PR again? Will you be more happy if 
instead of `-fms-layout-compatibility` there will be a copy of  
`TargetInfo::defaultsToMsStruct` in the driver?

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


[clang] Diagnose misuse of the cleanup attribute (PR #80040)

2024-03-12 Thread Shafik Yaghmour via cfe-commits

shafik wrote:

It looks like it passed on your last commit but you have a conflict now which 
you need to resolve.

Can you merge or do you need help with that?

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


[clang] [clang] Stub out gcc_struct attribute (PR #71148)

2024-03-12 Thread Dan Klishch via cfe-commits

https://github.com/DanShaders updated 
https://github.com/llvm/llvm-project/pull/71148

>From d0484b032b13109a226c088f18cf0ccd6026bceb Mon Sep 17 00:00:00 2001
From: Dan Klishch 
Date: Fri, 3 Nov 2023 21:18:06 -0400
Subject: [PATCH] [clang] Stub out gcc_struct attribute

This commit implements gcc_struct attribute with the behavior similar to
one in GCC. Current behavior is as follows:

When C++ ABI is not "Microsoft" (i. e. when
ItaniumRecordLayoutBuilder is used), [[gcc_struct]] will locally cancel
the effect of -mms-bitfields on a record. If -mms-bitfields is not
supplied and is not a default behavior on a target, [[gcc_struct]] will
be a no-op. This should provide enough compatibility with GCC.

If C++ ABI is "Microsoft", [[gcc_struct]] will currently always produce
a diagnostic, since support for it is not yet implemented in
MicrosoftRecordLayoutBuilder. Note, however, that all the infrastructure
is ready for the future implementation.

In particular, check for default value of -mms-bitfields is moved from a
driver to TargetInfo, since it now non-trivially depends on other
supplied flags. Also this, unfortunately, makes it impossible to use
usual argument parsing for `-m{no-,}ms-bitfields`.

The patch doesn't introduce any backwards-incompatible changes, except
for situations when cc1 is called directly with `-mms-bitfields` option.
---
 clang/docs/ReleaseNotes.rst   |  6 
 clang/include/clang/Basic/Attr.td |  9 +-
 clang/include/clang/Basic/AttrDocs.td | 16 +++
 .../include/clang/Basic/DiagnosticASTKinds.td |  3 ++
 clang/include/clang/Basic/LangOptions.def |  3 +-
 clang/include/clang/Basic/LangOptions.h   | 10 +++
 clang/include/clang/Basic/TargetInfo.h|  4 +++
 clang/include/clang/Driver/Options.td | 10 +--
 clang/lib/AST/Decl.cpp|  9 +-
 clang/lib/AST/RecordLayoutBuilder.cpp |  7 +
 clang/lib/Driver/ToolChains/Clang.cpp | 10 +--
 clang/lib/Sema/SemaDecl.cpp   |  4 +--
 clang/lib/Sema/SemaDeclCXX.cpp| 28 ---
 clang/test/CodeGen/mingw-long-double.c|  2 +-
 clang/test/CodeGen/mms-bitfields.c|  2 +-
 clang/test/Driver/ms-bitfields.c  | 19 +
 clang/test/Layout/itanium-union-bitfield.cpp  |  2 +-
 ...a-attribute-supported-attributes-list.test |  1 +
 clang/test/Sema/mms-bitfields.c   |  2 +-
 clang/test/SemaCXX/ms_struct.cpp  |  2 +-
 clang/test/SemaCXX/ms_wide_bitfield.cpp   |  2 +-
 21 files changed, 117 insertions(+), 34 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 64a9fe0d8bcc48e..241afec03ad8335 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -201,6 +201,12 @@ Attribute Changes in Clang
   and each must be a positive integer when provided. The parameter ``x`` is 
required, while ``y`` and
   ``z`` are optional with default value of 1.
 
+- On targets with Itanium C++ ABI, Clang now supports ``[[gnu:gcc_struct]]``
+  with the behavior similar to one existing in GCC. In particular, whenever
+  ``-mms-bitfields`` command line option is provided (or if 
Microsoft-compatible
+  structure layout is default on the target), ``[[gnu::gcc_struct]]`` requests
+  the compiler to follow Itanium rules for the layout of an annotated 
structure.
+
 Improvements to Clang's diagnostics
 ---
 - Clang now applies syntax highlighting to the code snippets it
diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 63efd85dcd4e58e..ce10409b2e2c05d 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3824,7 +3824,14 @@ def CFGuard : InheritableAttr, 
TargetSpecificAttr {
 def MSStruct : InheritableAttr {
   let Spellings = [GCC<"ms_struct">];
   let Subjects = SubjectList<[Record]>;
-  let Documentation = [Undocumented];
+  let Documentation = [MSStructDocs];
+  let SimpleHandler = 1;
+}
+
+def GCCStruct : InheritableAttr {
+  let Spellings = [GCC<"gcc_struct">];
+  let Subjects = SubjectList<[Record]>;
+  let Documentation = [MSStructDocs]; // Covers this attribute too.
   let SimpleHandler = 1;
 }
 
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index d61f96ade557d54..b28d2144bdb2195 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -8000,3 +8000,19 @@ requirement:
   }
   }];
 }
+
+def MSStructDocs : Documentation {
+  let Category = DocCatDecl;
+  let Content = [{
+The ``ms_struct`` and ``gcc_struct`` attributes request the compiler to enter a
+special record layout compatibility mode which mimics the layout of Microsoft 
or
+Itanium C++ ABI respectively. Obviously, if the current C++ ABI matches the
+requested ABI, the attribute does nothing. However, if it does not, annotated
+structure or class 

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;

dougsonos wrote:

I decided I preferred inconsistency in DiagnosticSemaKinds.td than in the code 
that emits the diags:

```
S.Diag(Diag.Loc, diag::warn_func_effect_allocates)
<< effectName << TopFuncName;
...
S.Diag(Diag2.Loc, diag::note_func_effect_allocates)
<< effectName << CalleeName;
```

But maybe that's just a bit precious. As I was trying to word the diagnostics, 
there were times when they didn't always come out in consistent orders and I 
had bugs in passing the parameters in the right order.

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


[clang] [Clang][Sema] Fix a bug on type constraint checking (PR #84671)

2024-03-12 Thread Qizhi Hu via cfe-commits


@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++23 -verify %s
+// expected-no-diagnostics
+
+template concept IsOk = requires() { typename T::Float; };
+
+template struct Thing;
+
+template struct Foobar {

jcsxky wrote:

Fixed.

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


[clang] [clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (PR #83997)

2024-03-12 Thread Younan Zhang via cfe-commits

zyn0217 wrote:

> I'm reducing the test case. In the meantime, should this be reverted?

I think this depends on the case. Note the issues addressed by this patch may 
not only cause some crashes in debug build, but probably lead to incorrect 
constraint evaluation in release build, which means there's possibility that 
your case was an accept-invalid before.

(Sorry for making confusion earlier; my office hour just begins and I'm sitting 
here for your case. If there is really something wrong caused by this PR, I'll 
revert it in time. Don't worry.)

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}

dougsonos wrote:

Since `nolock(true)` needs to be part of a type, it becomes a `FunctionEffect` 
in a `FunctionEffectSet` attached to a `FunctionProtoType`. I looked at ways to 
defer `nolock(false)` off of the type and onto the `Decl`, but this violates a 
hard rule about placement of square-bracket attributes. So `nolock(false)` is 
implemented as type sugar, via `AttributedType`, even though it's ignored on 
types and only has meaning when attached to Decls.

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


[clang] [Clang][Sema] Fix a bug on type constraint checking (PR #84671)

2024-03-12 Thread Qizhi Hu via cfe-commits

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

>From fd1711b61478866ca1cd890a3dcfe3d1a8e1c211 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sun, 10 Mar 2024 16:11:18 +0800
Subject: [PATCH] [Clang][Sema] Fix a bug on type constraint checking

---
 clang/docs/ReleaseNotes.rst|  2 ++
 clang/lib/Sema/SemaTemplateInstantiateDecl.cpp |  1 +
 clang/test/Sema/PR84368.cpp| 16 
 3 files changed, 19 insertions(+)
 create mode 100644 clang/test/Sema/PR84368.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 88e552d5c46113..12b867330efff1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -351,6 +351,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Fix an issue where missing set friend declaration in template class 
instantiation.
+  Fixes (#GH84368).
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp 
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 20c2c93ac9c7b4..765c5bc689ae1e 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1698,6 +1698,7 @@ Decl 
*TemplateDeclInstantiator::VisitClassTemplateDecl(ClassTemplateDecl *D) {
 assert(!Owner->isDependentContext());
 Inst->setLexicalDeclContext(Owner);
 RecordInst->setLexicalDeclContext(Owner);
+Inst->setObjectOfFriendDecl();
 
 if (PrevClassTemplate) {
   Inst->setCommonPtr(PrevClassTemplate->getCommonPtr());
diff --git a/clang/test/Sema/PR84368.cpp b/clang/test/Sema/PR84368.cpp
new file mode 100644
index 00..6551df29358920
--- /dev/null
+++ b/clang/test/Sema/PR84368.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++23 -verify %s
+// expected-no-diagnostics
+
+template concept IsOk = requires() { typename T::Float; };
+
+template struct Thing;
+
+template struct Foobar {
+  template struct Inner {
+template friend struct Thing;
+  };
+};
+
+struct MyType { using Float=float; };
+Foobar::Inner<0> foobar;

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


[clang] Turn 'counted_by' into a type attribute and parse it into 'CountAttributedType' (PR #78000)

2024-03-12 Thread Yinying Li via cfe-commits

https://github.com/yinying-lisa-li updated 
https://github.com/llvm/llvm-project/pull/78000

>From 3d2716ad6088f600c14d6ff724aa90453130a1f7 Mon Sep 17 00:00:00 2001
From: Yeoul Na 
Date: Mon, 18 Dec 2023 10:58:16 +0900
Subject: [PATCH 01/13] [BoundsSafety] Introduce CountAttributedType

CountAttributedType is a sugar type to represent a type with
a 'counted_by' attribute and the likes, which provides bounds
information to the underlying type. The type contains an
the argument of attribute as an expression. Additionally, the type
holds metadata about declarations referenced by the expression in
order to make it easier for Sema to access declarations on which
the type depends.

This also adjusts the CountedBy attribute definition and implements
parsing CountAttributedType.

__bdos and array-checks sanitizer use CountAttributedType instead
of hasAttr.

Implements special lookup for counted_by argument in structs.

Adjust test/Sema/attr-counted-by.c to match the default diags
generated by the expression parser.
---
 clang/include/clang/AST/ASTContext.h  |   7 +
 clang/include/clang/AST/PropertiesBase.td |   1 +
 clang/include/clang/AST/RecursiveASTVisitor.h |   9 +
 clang/include/clang/AST/Type.h| 152 +++
 clang/include/clang/AST/TypeLoc.h |  26 +++
 clang/include/clang/AST/TypeProperties.td |  19 ++
 clang/include/clang/Basic/Attr.td |   7 +-
 .../clang/Basic/DiagnosticSemaKinds.td|  14 +-
 clang/include/clang/Basic/TypeNodes.td|   2 +
 clang/include/clang/Parse/Parser.h|   5 +
 .../clang/Serialization/ASTRecordReader.h |   2 +
 .../clang/Serialization/ASTRecordWriter.h |   5 +
 .../clang/Serialization/TypeBitCodes.def  |   2 +-
 clang/lib/AST/ASTContext.cpp  |  55 ++
 clang/lib/AST/ASTImporter.cpp |  22 +++
 clang/lib/AST/ASTStructuralEquivalence.cpp|   7 +
 clang/lib/AST/ItaniumMangle.cpp   |   1 +
 clang/lib/AST/Type.cpp|  65 +++
 clang/lib/AST/TypeLoc.cpp |   4 +
 clang/lib/AST/TypePrinter.cpp |  30 +++
 clang/lib/CodeGen/CGBuiltin.cpp   |   6 +-
 clang/lib/CodeGen/CGDebugInfo.cpp |   1 +
 clang/lib/CodeGen/CGExpr.cpp  |  37 +---
 clang/lib/CodeGen/CodeGenFunction.cpp |   1 +
 clang/lib/Parse/ParseDecl.cpp |  90 +
 clang/lib/Sema/SemaDecl.cpp   |   6 -
 clang/lib/Sema/SemaDeclAttr.cpp   | 183 --
 clang/lib/Sema/SemaExpr.cpp   |  25 ++-
 clang/lib/Sema/SemaType.cpp   |  12 ++
 clang/lib/Sema/TreeTransform.h|   7 +
 clang/lib/Serialization/ASTReader.cpp |   8 +
 clang/lib/Serialization/ASTWriter.cpp |   4 +
 clang/test/Sema/attr-counted-by.c |  20 +-
 clang/tools/libclang/CIndex.cpp   |   4 +
 34 files changed, 679 insertions(+), 160 deletions(-)

diff --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index ff6b64c7f72d57..002f36ecbbaa3f 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -250,6 +250,8 @@ class ASTContext : public RefCountedBase {
   DependentBitIntTypes;
   llvm::FoldingSet BTFTagAttributedTypes;
 
+  mutable llvm::FoldingSet CountAttributedTypes;
+
   mutable llvm::FoldingSet QualifiedTemplateNames;
   mutable llvm::FoldingSet DependentTemplateNames;
   mutable llvm::FoldingSet
@@ -1341,6 +1343,11 @@ class ASTContext : public RefCountedBase {
 return CanQualType::CreateUnsafe(getPointerType((QualType) T));
   }
 
+  QualType
+  getCountAttributedType(QualType T, Expr *CountExpr, bool CountInBytes,
+ bool OrNull,
+ ArrayRef DependentDecls) 
const;
+
   /// Return the uniqued reference to a type adjusted from the original
   /// type to a new type.
   QualType getAdjustedType(QualType Orig, QualType New) const;
diff --git a/clang/include/clang/AST/PropertiesBase.td 
b/clang/include/clang/AST/PropertiesBase.td
index 0270c086d06b6a..6df1d93a7ba2eb 100644
--- a/clang/include/clang/AST/PropertiesBase.td
+++ b/clang/include/clang/AST/PropertiesBase.td
@@ -143,6 +143,7 @@ def UInt32 : CountPropertyType<"uint32_t">;
 def UInt64 : CountPropertyType<"uint64_t">;
 def UnaryTypeTransformKind : EnumPropertyType<"UnaryTransformType::UTTKind">;
 def VectorKind : EnumPropertyType<"VectorKind">;
+def TypeCoupledDeclRefInfo : PropertyType;
 
 def ExceptionSpecInfo : PropertyType<"FunctionProtoType::ExceptionSpecInfo"> {
   let BufferElementTypes = [ QualType ];
diff --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 5080551ada4fc6..4a1ff222ecadcd 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -1110,6 +1110,12 @@ 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-12 Thread Chuanqi Xu via cfe-commits

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


[clang] 9d6c43b - [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (#84285)

2024-03-12 Thread via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-13T09:26:53+08:00
New Revision: 9d6c43b4aed117f53167e72749b31a943941345d

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

LOG: [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 
per file mode (#84285)

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689 per
file mode, it simply wastes times and resources.

This patch itself should be a NFC patch. It simply moves codes.

Added: 


Modified: 
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..eaa76dd43e41dd 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -867,13 +867,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +886,114 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
+  auto ScanningTask = [&](DependencyScanningService ) {
+DependencyScanningTool WorkerTool(Service);
+
+llvm::DenseSet AlreadySeenModules;
+while (auto MaybeInputIndex = GetNextInputIndex()) {
+  size_t LocalIndex = *MaybeInputIndex;
+  const tooling::CompileCommand *Input = [LocalIndex];
+  std::string Filename = std::move(Input->Filename);
+  std::string CWD = std::move(Input->Directory);
+
+  std::optional MaybeModuleName;
+  if (!ModuleName.empty())
+MaybeModuleName = ModuleName;
+
+  std::string OutputDir(ModuleFilesDir);
+  if (OutputDir.empty())
+OutputDir = getModuleCachePath(Input->CommandLine);
+  auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
+return ::lookupModuleOutput(MID, MOK, OutputDir);
+  };
+
+  // Run the tool on it.
+  if (Format == ScanningOutputFormat::Make) {
+auto MaybeFile = WorkerTool.getDependencyFile(Input->CommandLine, CWD);
+if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
+   Errs))
+  HadErrors = true;
+  } else if (Format == ScanningOutputFormat::P1689) {
+// It is useful to generate the make-format dependency output during
+// the scanning for P1689. Otherwise the users need to scan again for
+// it. We will generate the make-format dependency output if we find
+// `-MF` in the command lines.
+std::string MakeformatOutputPath;
+std::string MakeformatOutput;
+
+auto MaybeRule = WorkerTool.getP1689ModuleDependencyFile(
+*Input, CWD, MakeformatOutput, MakeformatOutputPath);
+
+if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
+  HadErrors = true;
+
+if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
+!HadErrors) {
+  static std::mutex Lock;
+  // With compilation database, we may open 
diff erent files
+  // concurrently or we may write the same file concurrently. So we
+  // use a map here to allow multiple compile commands to write to the
+  // same file. Also we need a lock here to avoid data race.
+  static llvm::StringMap OSs;
+  std::unique_lock LockGuard(Lock);
+
+  auto OSIter = OSs.find(MakeformatOutputPath);
+  if (OSIter == OSs.end()) {
+std::error_code EC;
+OSIter =
+OSs.try_emplace(MakeformatOutputPath, MakeformatOutputPath, EC)
+.first;
+if (EC)
+  llvm::errs() << "Failed to open P1689 make format output file \""
+   << MakeformatOutputPath << "\" for " << EC.message()
+   << "\n";
+  }
+
+  SharedStream MakeformatOS(OSIter->second);
+  llvm::Expected 

[clang] [Clang][Sema] Fix a bug on type constraint checking (PR #84671)

2024-03-12 Thread Petr Hosek via cfe-commits

https://github.com/petrhosek updated 
https://github.com/llvm/llvm-project/pull/84671

>From 1b71ce0ece77060591edaf69794e184d58ad9b15 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sun, 10 Mar 2024 16:11:18 +0800
Subject: [PATCH] [Clang][Sema] Fix a bug on type constraint checking

---
 clang/docs/ReleaseNotes.rst|  2 ++
 clang/lib/Sema/SemaTemplateInstantiateDecl.cpp |  1 +
 clang/test/Sema/PR84368.cpp| 16 
 3 files changed, 19 insertions(+)
 create mode 100644 clang/test/Sema/PR84368.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 88e552d5c46113..12b867330efff1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -351,6 +351,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Fix an issue where missing set friend declaration in template class 
instantiation.
+  Fixes (#GH84368).
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp 
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 20c2c93ac9c7b4..765c5bc689ae1e 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1698,6 +1698,7 @@ Decl 
*TemplateDeclInstantiator::VisitClassTemplateDecl(ClassTemplateDecl *D) {
 assert(!Owner->isDependentContext());
 Inst->setLexicalDeclContext(Owner);
 RecordInst->setLexicalDeclContext(Owner);
+Inst->setObjectOfFriendDecl();
 
 if (PrevClassTemplate) {
   Inst->setCommonPtr(PrevClassTemplate->getCommonPtr());
diff --git a/clang/test/Sema/PR84368.cpp b/clang/test/Sema/PR84368.cpp
new file mode 100644
index 00..073530ffd8abea
--- /dev/null
+++ b/clang/test/Sema/PR84368.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++23 -verify %s
+// expected-no-diagnostics
+
+template concept IsOk = requires() { typename T::Float; };
+
+template struct Thing;
+
+template struct Foobar {
+   template struct Inner {
+   template friend struct Thing;
+   };
+};
+
+struct MyType { using Float=float; };
+Foobar::Inner<0> foobar;

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


[clang] [llvm] [HLSL] Add -HV option translation to clang-dxc.exe (PR #83938)

2024-03-12 Thread Joshua Batista via cfe-commits

https://github.com/bob80905 updated 
https://github.com/llvm/llvm-project/pull/83938

>From 7453ffdea39c624221c9696394bbd47be7eec662 Mon Sep 17 00:00:00 2001
From: Joshua Batista 
Date: Mon, 4 Mar 2024 13:42:02 -0800
Subject: [PATCH 1/7] first try

---
 clang/include/clang/Driver/Options.td | 4 
 clang/lib/Driver/ToolChains/HLSL.cpp  | 8 
 2 files changed, 12 insertions(+)

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index bef38738fde82e..6fe3dea1655b24 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -8545,6 +8545,10 @@ def dxc_entrypoint : Option<["--", "/", "-"], "E", 
KIND_JOINED_OR_SEPARATE>,
  Group,
  Visibility<[DXCOption]>,
  HelpText<"Entry point name">;
+def dxc_HlslVersion : Option<["--", "/", "-"], "HV", KIND_JOINED_OR_SEPARATE>,
+ Group,
+ Visibility<[DXCOption]>,
+ HelpText<"HLSL Version">;
 def dxc_validator_path_EQ : Joined<["--"], "dxv-path=">, Group,
   HelpText<"DXIL validator installation path">;
 def dxc_disable_validation : DXCFlag<"Vd">,
diff --git a/clang/lib/Driver/ToolChains/HLSL.cpp 
b/clang/lib/Driver/ToolChains/HLSL.cpp
index c6ad862b229420..0ffc15155e4db3 100644
--- a/clang/lib/Driver/ToolChains/HLSL.cpp
+++ b/clang/lib/Driver/ToolChains/HLSL.cpp
@@ -226,6 +226,14 @@ HLSLToolChain::TranslateArgs(const DerivedArgList , 
StringRef BoundArch,
   A->claim();
   continue;
 }
+if (A->getOption().getID() == options::OPT_HLSL_Version) {
+  // Translate -HV into -std for llvm
+  DAL->AddSeparateArg(nullptr,
+  Opts.getOption(options::OPT_stdlibxx_isystem),
+  A->getValue());
+  A->claim();
+  continue;
+}
 DAL->append(A);
   }
 

>From 69953d737b842f2144ebe0519d810c57b5c031b9 Mon Sep 17 00:00:00 2001
From: Joshua Batista 
Date: Mon, 4 Mar 2024 17:11:37 -0800
Subject: [PATCH 2/7] add HV option, and translation test

---
 clang/include/clang/Driver/Options.td |  2 +-
 clang/lib/Driver/ToolChains/HLSL.cpp  | 22 ++
 clang/test/Options/HV.hlsl| 13 +
 3 files changed, 32 insertions(+), 5 deletions(-)
 create mode 100644 clang/test/Options/HV.hlsl

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 6fe3dea1655b24..c4caf232887b56 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -8545,7 +8545,7 @@ def dxc_entrypoint : Option<["--", "/", "-"], "E", 
KIND_JOINED_OR_SEPARATE>,
  Group,
  Visibility<[DXCOption]>,
  HelpText<"Entry point name">;
-def dxc_HlslVersion : Option<["--", "/", "-"], "HV", KIND_JOINED_OR_SEPARATE>,
+def dxc_hlsl_version : Option<["--", "/", "-"], "HV", KIND_JOINED_OR_SEPARATE>,
  Group,
  Visibility<[DXCOption]>,
  HelpText<"HLSL Version">;
diff --git a/clang/lib/Driver/ToolChains/HLSL.cpp 
b/clang/lib/Driver/ToolChains/HLSL.cpp
index 0ffc15155e4db3..fe258919dedf3e 100644
--- a/clang/lib/Driver/ToolChains/HLSL.cpp
+++ b/clang/lib/Driver/ToolChains/HLSL.cpp
@@ -226,11 +226,25 @@ HLSLToolChain::TranslateArgs(const DerivedArgList , 
StringRef BoundArch,
   A->claim();
   continue;
 }
-if (A->getOption().getID() == options::OPT_HLSL_Version) {
+if (A->getOption().getID() == options::OPT_dxc_hlsl_version) {
   // Translate -HV into -std for llvm
-  DAL->AddSeparateArg(nullptr,
-  Opts.getOption(options::OPT_stdlibxx_isystem),
-  A->getValue());
+  // depending on the value given, assign std to:
+  // c++14,c++17,c++20,c++latest,c11,c17
+  const char *value = A->getValue();
+  if (strcmp(value, "2016") == 0) {
+DAL->AddSeparateArg(nullptr, Opts.getOption(options::OPT_std_EQ),
+"hlsl2016");
+  } else if (strcmp(value, "2017") == 0) {
+DAL->AddSeparateArg(nullptr, Opts.getOption(options::OPT_std_EQ),
+"hlsl2017");
+  } else if (strcmp(value, "2018") == 0) {
+DAL->AddSeparateArg(nullptr, Opts.getOption(options::OPT_std_EQ),
+"hlsl2018");
+  } else if (strcmp(value, "2021") == 0) {
+DAL->AddSeparateArg(nullptr, Opts.getOption(options::OPT_std_EQ),
+"hlsl2021");
+  }
+
   A->claim();
   continue;
 }
diff --git a/clang/test/Options/HV.hlsl b/clang/test/Options/HV.hlsl
new file mode 100644
index 00..59158ff2f001ed
--- /dev/null
+++ b/clang/test/Options/HV.hlsl
@@ -0,0 +1,13 @@
+// RUN: %clang_dxc -T lib_6_4 -HV 2016 %s 2>&1 -###   | FileCheck 
-check-prefix=2016 %s
+// RUN: %clang_dxc -T lib_6_4 -HV 2017 %s 2>&1 -###   | FileCheck 

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

2024-03-12 Thread Peter Rong via cfe-commits

https://github.com/DataCorrupted updated 
https://github.com/llvm/llvm-project/pull/83896

>From f22a5cd30f77b2043f9c1f7f4482fad87fb79250 Mon Sep 17 00:00:00 2001
From: Craig Topper 
Date: Mon, 4 Mar 2024 11:24:34 -0800
Subject: [PATCH 1/7] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1
 instructions.

These were in LLVM 17 but removed from LLVM 18 due to an incorrect
extension name being used.

This restores them with new extension names that match SiFive's
downstream compiler. The extension name has been used internally
for some time. It uses XSiFive instead of XSf like the newer extensions.

The spec for the instructions is here 
https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
though the extension name is not listed.

Column width in the extension printing had to be changed to accomodate
a longer extension name.
---
 .../test/Preprocessor/riscv-target-features.c |  18 +
 llvm/docs/RISCVUsage.rst  |   6 +
 llvm/lib/Support/RISCVISAInfo.cpp |   4 +-
 .../RISCV/Disassembler/RISCVDisassembler.cpp  |   6 +
 llvm/lib/Target/RISCV/RISCVFeatures.td|  16 +
 llvm/lib/Target/RISCV/RISCVInstrInfoXSf.td|  22 ++
 llvm/unittests/Support/RISCVISAInfoTest.cpp   | 326 +-
 7 files changed, 235 insertions(+), 163 deletions(-)

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 1a15be1c6e4dc1..b8ea4fd738fdf7 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -61,6 +61,8 @@
 // CHECK-NOT: __riscv_xsfvfwmaccqqq {{.*$}}
 // CHECK-NOT: __riscv_xsfqmaccdod {{.*$}}
 // CHECK-NOT: __riscv_xsfvqmaccqoq {{.*$}}
+// CHECK-NOT: __riscv_sifivecdiscarddlone {{.*$}}
+// CHECK-NOT: __riscv_sifivecflushdlone {{.*$}}
 // CHECK-NOT: __riscv_xtheadba {{.*$}}
 // CHECK-NOT: __riscv_xtheadbb {{.*$}}
 // CHECK-NOT: __riscv_xtheadbs {{.*$}}
@@ -557,6 +559,22 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-XSFVQMACCQOQ-EXT %s
 // CHECK-XSFVQMACCQOQ-EXT: __riscv_xsfvqmaccqoq 100{{$}}
 
+// RUN: %clang --target=riscv32-unknown-linux-gnu \
+// RUN:   -march=rv32ixsifivecdiscarddlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECDISCARDDLONE-EXT %s
+// RUN: %clang --target=riscv64-unknown-linux-gnu \
+// RUN:   -march=rv64ixsifivecdiscarddlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECDISCARDDLONE-EXT %s
+// CHECK-XSIFIVECDISCARDDLONE-EXT: __riscv_xsifivecdiscarddlone 100{{$}}
+
+// RUN: %clang --target=riscv32-unknown-linux-gnu \
+// RUN:   -march=rv32ixsifivecflushdlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECFLUSHDLONE-EXT %s
+// RUN: %clang --target=riscv64-unknown-linux-gnu \
+// RUN:   -march=rv64ixsifivecflushdlone -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-XSIFIVECFLUSHDLONE-EXT %s
+// CHECK-XSIFIVECFLUSHDLONE-EXT: __riscv_xsifivecflushdlone 100{{$}}
+
 // RUN: %clang --target=riscv32-unknown-linux-gnu \
 // RUN:   -march=rv32ixtheadba -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-XTHEADBA-EXT %s
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index a1de8596480da9..69e823eac25fc6 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -362,6 +362,12 @@ The current vendor extensions supported are:
 ``XCVbi``
   LLVM implements `version 1.0.0 of the CORE-V immediate branching custom 
instructions specification 
`__
 by OpenHW Group.  All instructions are prefixed with `cv.` as described in the 
specification. These instructions are only available for riscv32 at this time.
 
+``XSiFivecdiscarddlone``
+  LLVM implements `the SiFive cdiscard.d.l1 instruction specified in 
`_
 by SiFive.
+
+``XSiFivecflushdlone``
+  LLVM implements `the SiFive cflush.d.l1 instruction specified in 
`_
 by SiFive.
+
 Experimental C Intrinsics
 =
 
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 6eec03fd6f7082..17f39223b99bac 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -95,6 +95,8 @@ static const RISCVSupportedExtension SupportedExtensions[] = {
 {"xsfvfwmaccqqq", {1, 0}},
 {"xsfvqmaccdod", {1, 0}},
 {"xsfvqmaccqoq", {1, 0}},
+{"xsifivecdiscarddlone", {1, 0}},
+{"xsifivecflushdlone", {1, 0}},
 {"xtheadba", {1, 0}},
 {"xtheadbb", {1, 0}},
 {"xtheadbs", {1, 0}},
@@ -258,7 +260,7 @@ static void PrintExtension(StringRef Name, StringRef 
Version,
StringRef 

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// R UN: %clang_cc1 -fsyntax-only -fblocks -verify -x c -std=c23 %s
+
+#if !__has_attribute(clang_nolock)
+#error "the 'nolock' attribute is not available"
+#endif
+
+void unannotated(void);
+void nolock(void) [[clang::nolock]];

Sirraide wrote:

It took us 50 years, but we got there eventually haha.

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


[clang] [Clang] [CodeGen] Fix codegen bug in constant initialisation in C23 mode (PR #84981)

2024-03-12 Thread via cfe-commits

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/84981

>From b60ff0c29f367306beb5ea0965dfaf5b7f361654 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Tue, 12 Mar 2024 13:53:34 +0100
Subject: [PATCH 1/4] [Clang] [CodeGen] Fix codegen bug in constant
 initialisation in C23 mode

---
 clang/docs/ReleaseNotes.rst | 3 +++
 clang/lib/AST/Decl.cpp  | 4 +++-
 clang/test/CodeGen/const-init.c | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f61dca9bbc8467..c773991b43f47c 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -259,6 +259,9 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
+- Clang no longer fails to codegen static ``const`` variables whose 
initialiser performs
+  a floating-point division by 0 in C23.
+
 Bug Fixes to Compiler Builtins
 ^^
 
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index d681791d3920c3..38317dea6d22fe 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -2581,7 +2581,9 @@ APValue 
*VarDecl::evaluateValueImpl(SmallVectorImpl ,
   // case, we can't keep the result, because it may only be correct under the
   // assumption that the initializer is a constant context.
   if (IsConstantInitialization &&
-  (Ctx.getLangOpts().CPlusPlus || Ctx.getLangOpts().C23) && !Notes.empty())
+  (Ctx.getLangOpts().CPlusPlus ||
+   (isConstexpr() && Ctx.getLangOpts().C23)) &&
+  !Notes.empty())
 Result = false;
 
   // Ensure the computed APValue is cleaned up later if evaluation succeeded,
diff --git a/clang/test/CodeGen/const-init.c b/clang/test/CodeGen/const-init.c
index 0e4fc4ad48af8d..ad3e9551199ac2 100644
--- a/clang/test/CodeGen/const-init.c
+++ b/clang/test/CodeGen/const-init.c
@@ -216,3 +216,6 @@ int PR4517_x2 = PR4517_arrc[PR4517_idx];
 // CHECK: @PR4517_x = global i32 42, align 4
 // CHECK: @PR4517_idx = constant i32 1, align 4
 // CHECK: @PR4517_x2 = global i32 42, align 4
+
+// CHECK: @GH84784_inf = constant i8 1
+_Bool const GH84784_inf = (1.0/0.0);

>From 9eea6ffa1f4ebe41420bc922181653c75bf7bf19 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Tue, 12 Mar 2024 21:51:06 +0100
Subject: [PATCH 2/4] [NFC] Update comment

---
 clang/lib/AST/Decl.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 38317dea6d22fe..acd6191b6a1e2d 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -2577,9 +2577,10 @@ APValue 
*VarDecl::evaluateValueImpl(SmallVectorImpl ,
   bool Result = Init->EvaluateAsInitializer(Eval->Evaluated, Ctx, this, Notes,
 IsConstantInitialization);
 
-  // In C++/C23, this isn't a constant initializer if we produced notes. In 
that
-  // case, we can't keep the result, because it may only be correct under the
-  // assumption that the initializer is a constant context.
+  // In C++, or in C23 if we're initialising a 'constexpr' variable, this isn't
+  // a constant initializer if we produced notes. In that case, we can't keep
+  // the result, because it may only be correct under the assumption that the
+  // initializer is a constant context.
   if (IsConstantInitialization &&
   (Ctx.getLangOpts().CPlusPlus ||
(isConstexpr() && Ctx.getLangOpts().C23)) &&

>From 2391ea4cb2422345e59a5e4dfe326215d6e10813 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Tue, 12 Mar 2024 21:52:22 +0100
Subject: [PATCH 3/4] [NFC] Reference issue in release notes

---
 clang/docs/ReleaseNotes.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index c773991b43f47c..c70cc72e55af58 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -261,6 +261,7 @@ Bug Fixes in This Version
 
 - Clang no longer fails to codegen static ``const`` variables whose 
initialiser performs
   a floating-point division by 0 in C23.
+  Fixes (#GH84784).
 
 Bug Fixes to Compiler Builtins
 ^^

>From d04cb7c35d1484d0c03b16323d20fe8dc37dcbde Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Wed, 13 Mar 2024 02:05:01 +0100
Subject: [PATCH 4/4] [NFC] Remove release note

---
 clang/docs/ReleaseNotes.rst | 4 
 1 file changed, 4 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index c70cc72e55af58..f61dca9bbc8467 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -259,10 +259,6 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
-- Clang no longer fails to codegen static ``const`` variables whose 
initialiser performs
-  a floating-point division by 0 in C23.
-  Fixes (#GH84784).
-
 Bug Fixes to Compiler Builtins
 ^^
 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -0,0 +1,84 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s

dougsonos wrote:

Thanks, yes, I will merge them (other than the one that is checking the AST 
dump).

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


[clang] [Clang] [CodeGen] Fix codegen bug in constant initialisation in C23 mode (PR #84981)

2024-03-12 Thread via cfe-commits


@@ -259,6 +259,10 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
+- Clang no longer fails to codegen static ``const`` variables whose 
initialiser performs
+  a floating-point division by 0 in C23.
+  Fixes (#GH84784).

Sirraide wrote:

Oh, I thought it was, my bad. Yeah, we don’t need a release note then ofc.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// R UN: %clang_cc1 -fsyntax-only -fblocks -verify -x c -std=c23 %s
+
+#if !__has_attribute(clang_nolock)
+#error "the 'nolock' attribute is not available"
+#endif
+
+void unannotated(void);
+void nolock(void) [[clang::nolock]];

dougsonos wrote:

Wow, I never thought I'd see this day!

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -395,6 +395,33 @@ bool Sema::checkStringLiteralArgumentAttr(const ParsedAttr 
, unsigned ArgNum,
   return checkStringLiteralArgumentAttr(AL, ArgExpr, Str, ArgLocation);
 }
 
+/// Check if the argument \p ArgNum of \p Attr is a compile-time constant
+/// integer (boolean) expression. If not, emit an error and return false.
+bool Sema::checkBoolExprArgumentAttr(const ParsedAttr , unsigned ArgNum,
+ bool ) {
+  if (AL.isInvalid()) {
+return false;
+  }
+  Expr *ArgExpr = AL.getArgAsExpr(ArgNum);
+  SourceLocation ErrorLoc(AL.getLoc());
+
+  if (AL.isArgIdent(ArgNum)) {
+IdentifierLoc *IL = AL.getArgAsIdent(ArgNum);
+ErrorLoc = IL->Loc;
+  } else if (ArgExpr != nullptr) {
+if (const std::optional MaybeVal =
+ArgExpr->getIntegerConstantExpr(Context, )) {
+  Value = MaybeVal->getBoolValue();
+  return true;
+}
+  }

Sirraide wrote:

> how would we represent nolock(expression) before we can evaluate the 
> expression?

You just store the dependent expression in the attribute. If it’s dependent, 
then you only check whether it’s convertible (and whether it’s `true`) when you 
instantiate this attribute by running Sema on it again. As I already mentioned, 
you can take a look at how `CXXAssumeAttr` is handled (I implemented that one 
recently; it has to deal w/ almost all of that as well, so you should be able 
to get an idea as to what you need to do; you can ignore all the custom parsing 
code for it, though), to get an idea as to what you need to do.

> And when would it be collapsed back into a concretely true or false form?

The expression in the attribute itself? Never, pretty much. I’ll just stay as 
an expression, and you can evaluate it to figure out whether it’s `true` or 
`false` (afaik you can wrap the expression in a `ConstantExpr` after evaluating 
it to avoid having to re-evaluate it over and over again).

Feel free to ask if you have any more questions about this; I recall this 
having been quite confusing for me as well when I had to figure out how all of 
this actually works...

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


[clang] [clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (PR #83997)

2024-03-12 Thread via cfe-commits

alexfh wrote:

I'm reducing the test case. In the meantime, should this be reverted?

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


[clang] [Clang] [CodeGen] Fix codegen bug in constant initialisation in C23 mode (PR #84981)

2024-03-12 Thread Eli Friedman via cfe-commits


@@ -259,6 +259,10 @@ Bug Fixes in This Version
   operator.
   Fixes (#GH83267).
 
+- Clang no longer fails to codegen static ``const`` variables whose 
initialiser performs
+  a floating-point division by 0 in C23.
+  Fixes (#GH84784).

efriedma-quic wrote:

We usually only add release notes for things that are fixed between releases.  
This wasn't broken in 18, so I don't think we need a release note.

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


[clang] [llvm] [ASan][Driver] Add sanitize-target flag to support enabling ASan in device or host compilation (PR #76127)

2024-03-12 Thread via cfe-commits

jinge90 wrote:

Using general option to pass device specific flags to device compilation should 
be better approach, so this pr is not needed any more, thanks very much!

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -339,6 +349,11 @@ namespace {
 
 bool didParseNoDeref() const { return parsedNoDeref; }
 
+void setParsedNolock(unsigned char v) { parsedNolock = v; }
+unsigned char getParsedNolock() const { return parsedNolock; }
+void setParsedNoalloc(unsigned char v) { parsedNoalloc = v; }
+unsigned char getParsedNoalloc() const { return parsedNoalloc; }

dougsonos wrote:

Yeah I thought I was trying to hide implementation details but this struct is 
local to the (giant) source file and it would definitely be better to just use 
the enum everywhere.

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread via cfe-commits

yonghong-song wrote:

For this one:
> A kernel function will expect the uint to be sign-extended, not zero-extended.
I suspect riscv bpf jit will do sign-extension. @pulehui can confirm.

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


[clang] [llvm] [ASan][Driver] Add sanitize-target flag to support enabling ASan in device or host compilation (PR #76127)

2024-03-12 Thread via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -395,6 +395,33 @@ bool Sema::checkStringLiteralArgumentAttr(const ParsedAttr 
, unsigned ArgNum,
   return checkStringLiteralArgumentAttr(AL, ArgExpr, Str, ArgLocation);
 }
 
+/// Check if the argument \p ArgNum of \p Attr is a compile-time constant
+/// integer (boolean) expression. If not, emit an error and return false.
+bool Sema::checkBoolExprArgumentAttr(const ParsedAttr , unsigned ArgNum,
+ bool ) {
+  if (AL.isInvalid()) {
+return false;
+  }
+  Expr *ArgExpr = AL.getArgAsExpr(ArgNum);
+  SourceLocation ErrorLoc(AL.getLoc());
+
+  if (AL.isArgIdent(ArgNum)) {
+IdentifierLoc *IL = AL.getArgAsIdent(ArgNum);
+ErrorLoc = IL->Loc;
+  } else if (ArgExpr != nullptr) {
+if (const std::optional MaybeVal =
+ArgExpr->getIntegerConstantExpr(Context, )) {
+  Value = MaybeVal->getBoolValue();
+  return true;
+}
+  }

dougsonos wrote:

Thank you! I was looking for precedents for this and couldn't find it on any 
attributes. It bugged me that I was writing something like this.

Yes, the parameter can be an arbitrary expression.

But if it is dependent: then how would we represent `nolock(expression)` before 
we can evaluate the expression? And when would it be collapsed back into a 
concretely true or false form?

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


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

2024-03-12 Thread via cfe-commits

Author: Qizhi Hu
Date: 2024-03-13T08:42:22+08:00
New Revision: 8bda5657332c7a94900d3eb2891d2b86e60b0e68

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

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

This patch attempts to fix
https://github.com/llvm/llvm-project/issues/25708
Current access check missed qualifier(`NestedNameSpecifier`) in friend
class checking. Add it to `Records` of `EffectiveContext` by changing
the `DeclContext` makes `MatchesFriend` work.

Co-authored-by: huqizhi <836744...@qq.com>

Added: 
clang/test/SemaTemplate/PR25708.cpp

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

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e14c92eae0afe1..64a9fe0d8bcc48 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -360,6 +360,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Allow access to a public template alias declaration that refers to friend's
+  private nested type. (#GH25708).
 
 Bug Fixes to AST Handling
 ^

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index d62095558d0ffb..d8c9a5c09944c4 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -4343,9 +4343,13 @@ QualType Sema::CheckTemplateIdType(TemplateName Name,
 if (Inst.isInvalid())
   return QualType();
 
-CanonType = SubstType(Pattern->getUnderlyingType(),
-  TemplateArgLists, AliasTemplate->getLocation(),
-  AliasTemplate->getDeclName());
+std::optional SavedContext;
+if (!AliasTemplate->getDeclContext()->isFileContext())
+  SavedContext.emplace(*this, AliasTemplate->getDeclContext());
+
+CanonType =
+SubstType(Pattern->getUnderlyingType(), TemplateArgLists,
+  AliasTemplate->getLocation(), AliasTemplate->getDeclName());
 if (CanonType.isNull()) {
   // If this was enable_if and we failed to find the nested type
   // within enable_if in a SFINAE context, dig out the specific

diff  --git a/clang/test/SemaTemplate/PR25708.cpp 
b/clang/test/SemaTemplate/PR25708.cpp
new file mode 100644
index 00..6a214fc6b43bc1
--- /dev/null
+++ b/clang/test/SemaTemplate/PR25708.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -std=c++11 -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] 8bda565 - [Clang][Sema] Allow access to a public template alias declaration that refers to friend's private nested type (#83847)

2024-03-12 Thread via cfe-commits

Author: Qizhi Hu
Date: 2024-03-13T08:42:22+08:00
New Revision: 8bda5657332c7a94900d3eb2891d2b86e60b0e68

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

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

This patch attempts to fix
https://github.com/llvm/llvm-project/issues/25708
Current access check missed qualifier(`NestedNameSpecifier`) in friend
class checking. Add it to `Records` of `EffectiveContext` by changing
the `DeclContext` makes `MatchesFriend` work.

Co-authored-by: huqizhi <836744...@qq.com>

Added: 
clang/test/SemaTemplate/PR25708.cpp

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

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e14c92eae0afe1..64a9fe0d8bcc48 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -360,6 +360,8 @@ Bug Fixes to C++ Support
   when one of the function had more specialized templates.
   Fixes (`#82509 `_)
   and (`#74494 `_)
+- Allow access to a public template alias declaration that refers to friend's
+  private nested type. (#GH25708).
 
 Bug Fixes to AST Handling
 ^

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index d62095558d0ffb..d8c9a5c09944c4 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -4343,9 +4343,13 @@ QualType Sema::CheckTemplateIdType(TemplateName Name,
 if (Inst.isInvalid())
   return QualType();
 
-CanonType = SubstType(Pattern->getUnderlyingType(),
-  TemplateArgLists, AliasTemplate->getLocation(),
-  AliasTemplate->getDeclName());
+std::optional SavedContext;
+if (!AliasTemplate->getDeclContext()->isFileContext())
+  SavedContext.emplace(*this, AliasTemplate->getDeclContext());
+
+CanonType =
+SubstType(Pattern->getUnderlyingType(), TemplateArgLists,
+  AliasTemplate->getLocation(), AliasTemplate->getDeclName());
 if (CanonType.isNull()) {
   // If this was enable_if and we failed to find the nested type
   // within enable_if in a SFINAE context, dig out the specific

diff  --git a/clang/test/SemaTemplate/PR25708.cpp 
b/clang/test/SemaTemplate/PR25708.cpp
new file mode 100644
index 00..6a214fc6b43bc1
--- /dev/null
+++ b/clang/test/SemaTemplate/PR25708.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -std=c++11 -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] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}
+
+const NoLockNoAllocEffect ::noalloc_instance() {
+  static NoLockNoAllocEffect global(kNoAllocTrue, "noalloc");
+  return global;
+}
+
+// TODO: Separate flags for noalloc
+NoLockNoAllocEffect::NoLockNoAllocEffect(EffectType Ty, const char *Name)
+: FunctionEffect(Ty,
+ kRequiresVerification | kVerifyCalls |
+ kInferrableOnCallees | kExcludeThrow | kExcludeCatch |
+ kExcludeObjCMessageSend | kExcludeStaticLocalVars |
+ kExcludeThreadLocalVars,
+ Name) {}
+
+NoLockNoAllocEffect::~NoLockNoAllocEffect() = default;
+
+std::string NoLockNoAllocEffect::attribute() const {
+  return std::string{"__attribute__((clang_"} + name().str() + "))";
+}

Sirraide wrote:

To clarify, the `__attribute__` spelling is fine imo if it’s just for type/AST 
printing. That part of the code base doesn’t have to be ‘perfect’ if you will, 
just good enough to where you can tell what’s going on by looking at the 
printout. Attributes are already being printed inconsistently, so if you run 
into any weirdness there, that’s just quirks of how the AST printer works.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -2380,6 +2382,1239 @@ class UnsafeBufferUsageReporter : public 
UnsafeBufferUsageHandler {
 };
 } // namespace
 
+// 
=
+
+// Temporary debugging option
+#define FX_ANALYZER_VERIFY_DECL_LIST 1
+
+namespace FXAnalysis {
+
+enum class DiagnosticID : uint8_t {
+  None = 0, // sentinel for an empty Diagnostic
+  Throws,
+  Catches,
+  CallsObjC,
+  AllocatesMemory,
+  HasStaticLocal,
+  AccessesThreadLocal,
+
+  // These only apply to callees, where the analysis stops at the Decl
+  DeclWithoutConstraintOrInference,
+
+  CallsUnsafeDecl,
+  CallsDisallowedExpr,
+};
+
+struct Diagnostic {
+  const FunctionEffect *Effect = nullptr;
+  const Decl *Callee = nullptr; // only valid for Calls*
+  SourceLocation Loc;
+  DiagnosticID ID = DiagnosticID::None;
+
+  Diagnostic() = default;
+
+  Diagnostic(const FunctionEffect *Effect, DiagnosticID ID, SourceLocation Loc,
+ const Decl *Callee = nullptr)
+  : Effect(Effect), Callee(Callee), Loc(Loc), ID(ID) {}
+};
+
+enum class SpecialFuncType : uint8_t { None, OperatorNew, OperatorDelete };
+enum class CallType {
+  Unknown,
+  Function,
+  Virtual,
+  Block
+  // unknown: probably function pointer
+};
+
+// Return whether the function CAN be verified.
+// The question of whether it SHOULD be verified is independent.
+static bool functionIsVerifiable(const FunctionDecl *FD) {
+  if (!(FD->hasBody() || FD->isInlined())) {
+// externally defined; we couldn't verify if we wanted to.
+return false;
+  }
+  if (FD->isTrivial()) {
+// Otherwise `struct x { int a; };` would have an unverifiable default
+// constructor.
+return true;
+  }
+  return true;
+}
+
+// Transitory, more extended information about a callable, which can be a
+// function, block, function pointer...
+struct CallableInfo {
+  const Decl *CDecl;
+  mutable std::optional
+  MaybeName; // mutable because built on demand in const method
+  SpecialFuncType FuncType = SpecialFuncType::None;
+  FunctionEffectSet Effects;
+  CallType CType = CallType::Unknown;
+
+  CallableInfo(const Decl , SpecialFuncType FT = SpecialFuncType::None)
+  : CDecl(), FuncType(FT) {
+// llvm::errs() << "CallableInfo " << name() << "\n";
+
+if (auto *FD = dyn_cast(CDecl)) {
+  assert(FD->getCanonicalDecl() == FD);
+  // Use the function's definition, if any.
+  if (auto *Def = FD->getDefinition()) {
+CDecl = FD = Def;
+  }
+  CType = CallType::Function;
+  if (auto *Method = dyn_cast(FD)) {
+if (Method->isVirtual()) {
+  CType = CallType::Virtual;
+}
+  }
+  Effects = FD->getFunctionEffects();
+} else if (auto *BD = dyn_cast(CDecl)) {
+  CType = CallType::Block;
+  Effects = BD->getFunctionEffects();
+} else if (auto *VD = dyn_cast(CDecl)) {
+  // ValueDecl is function, enum, or variable, so just look at the type.
+  Effects = FunctionEffectSet::get(*VD->getType());
+}
+  }
+
+  bool isDirectCall() const {
+return CType == CallType::Function || CType == CallType::Block;
+  }
+
+  bool isVerifiable() const {
+switch (CType) {
+case CallType::Unknown:
+case CallType::Virtual:
+  break;
+case CallType::Block:
+  return true;
+case CallType::Function:
+  return functionIsVerifiable(dyn_cast(CDecl));
+}
+return false;
+  }
+
+  /// Generate a name for logging and diagnostics.
+  std::string name(Sema ) const {
+if (!MaybeName) {
+  std::string Name;
+  llvm::raw_string_ostream OS(Name);
+
+  if (auto *FD = dyn_cast(CDecl)) {
+FD->getNameForDiagnostic(OS, Sem.getPrintingPolicy(),
+ /*Qualified=*/true);
+  } else if (auto *BD = dyn_cast(CDecl)) {
+OS << "(block " << BD->getBlockManglingNumber() << ")";
+  } else if (auto *VD = dyn_cast(CDecl)) {
+VD->printQualifiedName(OS);
+  }
+  MaybeName = Name;
+}
+return *MaybeName;
+  }
+};
+
+// --
+// Map effects to single diagnostics.
+class EffectToDiagnosticMap {
+  // Since we currently only have a tiny number of effects (typically no more
+  // than 1), use a sorted SmallVector.
+  using Element = std::pair;
+  using ImplVec = llvm::SmallVector;
+  std::unique_ptr Impl;
+
+public:
+  Diagnostic (const FunctionEffect *Key) {
+if (Impl == nullptr) {
+  Impl = std::make_unique>();
+  auto  = Impl->emplace_back();
+  Item.first = Key;
+  return Item.second;
+}
+Element Elem(Key, {});
+auto Iter = _find(Elem);
+if (Iter != Impl->end() && Iter->first == Key) {
+  return Iter->second;
+}
+Iter = Impl->insert(Iter, Elem);
+return Iter->second;
+  }
+
+  const Diagnostic *lookup(const FunctionEffect *key) {
+if (Impl == nullptr) {
+  return nullptr;
+}
+Element elem(key, {});
+auto iter = _find(elem);
+if (iter != Impl->end() && iter->first == key) 

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

2024-03-12 Thread via cfe-commits

craigflores wrote:

Test from "craig.flo...@sony.com".

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] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread Eli Friedman via cfe-commits

efriedma-quic wrote:

> My understanding is that you refer to the following part of the 
> [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):

Yes.  For example, on RISC-V, the function `long f(unsigned g) { return (int)g; 
}` compiles to just a "ret".

> clang would now guarantee sign or zero extension for all integral function 
> parameters.

clang would guarantee sign-extension for signed parameters, and zero-extension 
for unsigned parameters. Which is not the same as the RISCV ABI rules.

> That is, we will do zero extension for uint argument here. This will 
> guarantee correct value if 'foo' is a kernel function.

A kernel function will expect the uint to be sign-extended, not zero-extended.

https://github.com/llvm/llvm-project/pull/84874
___
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)

2024-03-12 Thread Qizhi Hu via cfe-commits

https://github.com/jcsxky closed https://github.com/llvm/llvm-project/pull/83847
___
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)

2024-03-12 Thread Vitaly Buka via cfe-commits

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


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] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread via cfe-commits

yonghong-song wrote:

@pulehui Could you check whether with -mcpu=v2 (no-alu32 mode) we have 
'unsigned int' related issue or not? Specifically, given a 'unsigned int' does 
riscv use subregister to access 32-bit value, or use 64-bit register to access 
the value without zero-extension of 32-bit value?

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


[clang] [clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (PR #83997)

2024-03-12 Thread Younan Zhang via cfe-commits

zyn0217 wrote:

> Was this sort of a behavior change expected?

I don't think so; a reproducer would be really appreciated.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}
+
+const NoLockNoAllocEffect ::noalloc_instance() {
+  static NoLockNoAllocEffect global(kNoAllocTrue, "noalloc");
+  return global;
+}
+
+// TODO: Separate flags for noalloc
+NoLockNoAllocEffect::NoLockNoAllocEffect(EffectType Ty, const char *Name)
+: FunctionEffect(Ty,
+ kRequiresVerification | kVerifyCalls |
+ kInferrableOnCallees | kExcludeThrow | kExcludeCatch |
+ kExcludeObjCMessageSend | kExcludeStaticLocalVars |
+ kExcludeThreadLocalVars,
+ Name) {}
+
+NoLockNoAllocEffect::~NoLockNoAllocEffect() = default;
+
+std::string NoLockNoAllocEffect::attribute() const {
+  return std::string{"__attribute__((clang_"} + name().str() + "))";
+}

Sirraide wrote:

Ah, I see; looking at `printFunctionProtoAfter`, it really does just print 
`__attribute__` there; I would maybe consider either inlining it in that file 
or moving it there as a helper, because, while it makes sense to do something 
like this there, it just seems really weird out of context.

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread via cfe-commits

yonghong-song wrote:

The following is an example to show 'unsigned int' case. The current behavior 
(i.e., without this patch):
```
$ cat u.c
void foo(unsigned);
void bar(unsigned a, unsigned b) {
  foo(a + b);
}
$ clang --target=bpf -O2 -c u.c && llvm-objdump -d u.o

u.o:file format elf64-bpf

Disassembly of section .text:

 :
   0:   0f 12 00 00 00 00 00 00 r2 += r1
   1:   bf 21 00 00 00 00 00 00 r1 = r2
   2:   85 10 00 00 ff ff ff ff call -0x1
   3:   95 00 00 00 00 00 00 00 exit
```
Basically, we didn't do zero extension for 'uint' argument in the above. We 
expect the callee 'foo' to do proper zero extension. If both 'foo' and 'far' 
are functions written in bpf programs, we should be okay. But if 'foo' is a 
kfunc (e.g., a kernel function for a specific arch e.g. riscv) and the arch 
will just use the full register 'r1' to do operation without zero extension of 
32-bit value, the wrong results could happen.

With this patch, we will have the following asm code,
```
$ clang --target=bpf -O2 -c u.c && llvm-objdump -d u.o

u.o:file format elf64-bpf

Disassembly of section .text:

 :
   0:   0f 12 00 00 00 00 00 00 r2 += r1
   1:   67 02 00 00 20 00 00 00 r2 <<= 0x20
   2:   77 02 00 00 20 00 00 00 r2 >>= 0x20
   3:   bf 21 00 00 00 00 00 00 r1 = r2
   4:   85 10 00 00 ff ff ff ff call -0x1
   5:   95 00 00 00 00 00 00 00 exit
```
That is, we will do zero extension for uint argument here. This will guarantee 
correct value if 'foo' is a kernel function. If 'foo' is not a kernel function, 
the 'foo' will be able to use r2 directly as a 32-bit value without doing 
shifting, one example like below
```
long g1, g2;
__attribute__((noinline)) void foo(unsigned a) {
  if (a == g1) g2 = 1;
  else g2 = 2;  
}


 :
   0:   18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0x0 ll
   2:   79 23 00 00 00 00 00 00 r3 = *(u64 *)(r2 + 0x0)
   3:   b7 02 00 00 01 00 00 00 r2 = 0x1
   4:   1d 13 01 00 00 00 00 00 if r3 == r1 goto +0x1 
   5:   b7 02 00 00 02 00 00 00 r2 = 0x2

0030 :
   6:   18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0x0 ll
   8:   7b 21 00 00 00 00 00 00 *(u64 *)(r1 + 0x0) = r2
   9:   95 00 00 00 00 00 00 00 exit
```


https://github.com/llvm/llvm-project/pull/84874
___
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)

2024-03-12 Thread Vitaly Buka via cfe-commits


@@ -1094,6 +1114,27 @@ void ScalarExprEmitter::EmitIntegerTruncationCheck(Value 
*Src, QualType SrcType,
 {Src, Dst});
 }
 
+static llvm::Value *EmitIsNegativeTestHelper(Value *V, QualType VType,

vitalybuka wrote:

I still see it here, does it needs rebase, or that patch needs to be landed?

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] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}

Sirraide wrote:

> detect that a function is declared nolock(false) or noalloc(false) (by 
> examining the function's type sugar) and short-circuit any attempt to infer 
> the attribute.

Well, is that only *functions* or *function types* as well, though? Because 
functions would still have the `nolock` *attribute*, which then would store 
that data and could be used for inference. If it’s function types as well, then 
one option would be to store two bits instead of one, but I agree that that 
sounds a bit messy and we might want to think a bit more about it in that case. 
(I’d also have to double-check how/where attributes are stored on types)

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


[clang] [clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (PR #83997)

2024-03-12 Thread via cfe-commits

alexfh wrote:

Hi folks, we've started seeing "implicit instantiation of undefined template" 
compilation errors after this commit. In all cases code used to compile fine 
before this commit. I haven't spotted any particular issues in the code (though 
the examples are looked at are rather convoluted, thus, I'm not 100% sure). 
I'll try to prepare a self-sufficient test case.

Was this sort of a behavior change expected?

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}
+
+const NoLockNoAllocEffect ::noalloc_instance() {
+  static NoLockNoAllocEffect global(kNoAllocTrue, "noalloc");
+  return global;
+}
+
+// TODO: Separate flags for noalloc
+NoLockNoAllocEffect::NoLockNoAllocEffect(EffectType Ty, const char *Name)
+: FunctionEffect(Ty,
+ kRequiresVerification | kVerifyCalls |
+ kInferrableOnCallees | kExcludeThrow | kExcludeCatch |
+ kExcludeObjCMessageSend | kExcludeStaticLocalVars |
+ kExcludeThreadLocalVars,
+ Name) {}
+
+NoLockNoAllocEffect::~NoLockNoAllocEffect() = default;
+
+std::string NoLockNoAllocEffect::attribute() const {
+  return std::string{"__attribute__((clang_"} + name().str() + "))";
+}
+
+bool NoLockNoAllocEffect::diagnoseConversion(bool Adding, QualType OldType,
+ FunctionEffectSet OldFX,
+ QualType NewType,
+ FunctionEffectSet NewFX) const {
+  // noalloc can't be added (spoofed) during a conversion, unless we have 
nolock
+  if (Adding) {
+if (!isNoLock()) {
+  for (const auto *Effect : OldFX) {
+if (Effect->type() == kNoLockTrue)
+  return false;
+  }
+}
+// nolock can't be added (spoofed) during a conversion.
+return true;
+  }
+  return false;
+}
+
+bool NoLockNoAllocEffect::diagnoseRedeclaration(bool Adding,
+const FunctionDecl 
,
+FunctionEffectSet OldFX,
+const FunctionDecl 
,
+FunctionEffectSet NewFX) const 
{
+  // nolock/noalloc can't be removed in a redeclaration
+  // adding -> false, removing -> true (diagnose)
+  return !Adding;
+}
+
+bool NoLockNoAllocEffect::diagnoseMethodOverride(
+bool Adding, const CXXMethodDecl , FunctionEffectSet OldFX,
+const CXXMethodDecl , FunctionEffectSet NewFX) const {
+  // nolock/noalloc can't be removed from an override
+  return !Adding;
+}
+
+bool NoLockNoAllocEffect::canInferOnDecl(const Decl *Caller,
+ FunctionEffectSet CallerFX) const {
+  // Does the Decl have nolock(false) / noalloc(false) ?
+  QualType QT;
+  if (isa(Caller)) {
+const auto *TSI = cast(Caller)->getSignatureAsWritten();
+QT = TSI->getType();
+  } else if (isa(Caller)) {
+QT = cast(Caller)->getType();
+  } else {
+return false;
+  }
+  if (QT->hasAttr(isNoLock() ? attr::Kind::NoLock : attr::Kind::NoAlloc)) {
+return false;
+  }
+
+  return true;
+}
+
+// TODO: Notice that we don't care about some of the parameters. Is the
+// interface overly general?
+bool NoLockNoAllocEffect::diagnoseFunctionCall(
+bool Direct, const Decl *Caller, FunctionEffectSet CallerFX,
+CalleeDeclOrType Callee, FunctionEffectSet CalleeFX) const {
+  const EffectType CallerType = type();
+  for (const auto *Effect : CalleeFX) {
+  

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}
+
+const NoLockNoAllocEffect ::noalloc_instance() {
+  static NoLockNoAllocEffect global(kNoAllocTrue, "noalloc");
+  return global;
+}
+
+// TODO: Separate flags for noalloc
+NoLockNoAllocEffect::NoLockNoAllocEffect(EffectType Ty, const char *Name)
+: FunctionEffect(Ty,
+ kRequiresVerification | kVerifyCalls |
+ kInferrableOnCallees | kExcludeThrow | kExcludeCatch |
+ kExcludeObjCMessageSend | kExcludeStaticLocalVars |
+ kExcludeThreadLocalVars,
+ Name) {}
+
+NoLockNoAllocEffect::~NoLockNoAllocEffect() = default;
+
+std::string NoLockNoAllocEffect::attribute() const {
+  return std::string{"__attribute__((clang_"} + name().str() + "))";
+}

dougsonos wrote:

TypePrinter.cpp
I thought about using the square bracket spelling but two (admittedly dumb) 
things discouraged me:
- in the Clang branch where I originally did the work, square bracket spellings 
weren't enabled in the default C dialect
- matching square brackets (in the test that checks an AST dump) requires extra 
backslashes

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID , 
const ASTContext ) {
   Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
   getTypeConstraintConcept(), getTypeConstraintArguments());
 }
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+FunctionEffectSet OldFX,
+QualType NewType,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+   const FunctionDecl ,
+   FunctionEffectSet OldFX,
+   const FunctionDecl ,
+   FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+const CXXMethodDecl ,
+FunctionEffectSet OldFX,
+const CXXMethodDecl ,
+FunctionEffectSet NewFX) const {
+  return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+FunctionEffectSet CallerFX) const {
+  return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+  FunctionEffectSet CallerFX,
+  CalleeDeclOrType Callee,
+  FunctionEffectSet CalleeFX) const {
+  return false;
+}
+
+const NoLockNoAllocEffect ::nolock_instance() {
+  static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+  return global;
+}

dougsonos wrote:

I would like it to be this simple, though of the current behaviors of 
noalloc/nolock, the one that seems extra-special is to detect that a function 
is declared `nolock(false)` or `noalloc(false)` (by examining the function's 
type sugar) and short-circuit any attempt to infer the attribute.

Of course that could just be one more bit of behavior, with the identity of the 
sugar attribute a hardcoded function of the effect type.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -3666,11 +3673,14 @@ void FunctionProtoType::Profile(llvm::FoldingSetNodeID 
, QualType Result,
   // Finally we have a trailing return type flag (bool)
   // combined with AArch64 SME Attributes, to save space:
   //  int
+  // Then add the FunctionEffects
   //
   // There is no ambiguity between the consumed arguments and an empty EH
   // spec because of the leading 'bool' which unambiguously indicates
   // whether the following bool is the EH spec or part of the arguments.
 
+  ID.AddPointer(epi.FunctionEffects.getOpaqueValue()); // TODO: Where???

Sirraide wrote:

Yeah, you’re putting the effects first, which seems fine so long as you always 
add the effects (you’re right in that there seem to be some optional fields, so 
I’d be wary about moving it further down); updating the comment to reflect 
where the effects are encoded is a good idea—I didn’t notice that at first 
because the diff didn’t include that part of the comment.

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


[clang] [llvm] [ASan][Driver] Add sanitize-target flag to support enabling ASan in device or host compilation (PR #76127)

2024-03-12 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka requested changes to this pull request.

Removing from my pending reviews

https://github.com/llvm/llvm-project/pull/76127
___
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)

2024-03-12 Thread via cfe-commits

https://github.com/eddyz87 closed 
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] 2aacb56 - BPF address space insn (#84410)

2024-03-12 Thread via cfe-commits

Author: 4ast
Date: 2024-03-13T02:27:25+02:00
New Revision: 2aacb56e8361213c1bd69c2ceafdea3aa0ca9125

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

LOG: BPF address space insn (#84410)

This commit aims to support BPF arena kernel side
[feature](https://lore.kernel.org/bpf/20240209040608.98927-1-alexei.starovoi...@gmail.com/):
- arena is a memory region accessible from both BPF program and
userspace;
- base pointers for this memory region differ between kernel and user
spaces;
- `dst_reg = addr_space_cast(src_reg, dst_addr_space, src_addr_space)`
translates src_reg, a pointer in src_addr_space to dst_reg, equivalent
pointer in dst_addr_space, {src,dst}_addr_space are immediate constants;
- number 0 is assigned to kernel address space;
- number 1 is assigned to user address space.

On the LLVM side, the goal is to make load and store operations on arena
pointers "transparent" for BPF programs:
- assume that pointers with non-zero address space are pointers to
  arena memory;
- assume that arena is identified by address space number;
- assume that address space zero corresponds to kernel address space;
- assume that every BPF-side load or store from arena is done via
pointer in user address space, thus convert base pointers using
`addr_space_cast(src_reg, 0, 1)`;

Only load, store, cmpxchg and atomicrmw IR instructions are handled by
this transformation.

For example, the following C code:

```c
   #define __as __attribute__((address_space(1)))
   void copy(int __as *from, int __as *to) { *to = *from; }
```

Compiled to the following IR:

```llvm
define void @copy(ptr addrspace(1) %from, ptr addrspace(1) %to) {
entry:
  %0 = load i32, ptr addrspace(1) %from, align 4
  store i32 %0, ptr addrspace(1) %to, align 4
  ret void
}
```

Is transformed to:

```llvm
%to2 = addrspacecast ptr addrspace(1) %to to ptr ;; !
%from1 = addrspacecast ptr addrspace(1) %from to ptr ;; !
%0 = load i32, ptr %from1, align 4, !tbaa !3
store i32 %0, ptr %to2, align 4, !tbaa !3
ret void
```

And compiled as:

```asm
r2 = addr_space_cast(r2, 0, 1)
r1 = addr_space_cast(r1, 0, 1)
r1 = *(u32 *)(r1 + 0)
*(u32 *)(r2 + 0) = r1
exit
```

Co-authored-by: Eduard Zingerman 

Added: 
llvm/lib/Target/BPF/BPFASpaceCastSimplifyPass.cpp
llvm/test/CodeGen/BPF/addr-space-auto-casts.ll
llvm/test/CodeGen/BPF/addr-space-cast.ll
llvm/test/CodeGen/BPF/addr-space-gep-chain.ll
llvm/test/CodeGen/BPF/addr-space-globals.ll
llvm/test/CodeGen/BPF/addr-space-globals2.ll
llvm/test/CodeGen/BPF/addr-space-phi.ll
llvm/test/CodeGen/BPF/addr-space-simplify-1.ll
llvm/test/CodeGen/BPF/addr-space-simplify-2.ll
llvm/test/CodeGen/BPF/addr-space-simplify-3.ll
llvm/test/CodeGen/BPF/addr-space-simplify-4.ll
llvm/test/CodeGen/BPF/addr-space-simplify-5.ll

Modified: 
clang/lib/Basic/Targets/BPF.cpp
clang/test/Preprocessor/bpf-predefined-macros.c
llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp
llvm/lib/Target/BPF/BPF.h
llvm/lib/Target/BPF/BPFCheckAndAdjustIR.cpp
llvm/lib/Target/BPF/BPFInstrInfo.td
llvm/lib/Target/BPF/BPFTargetMachine.cpp
llvm/lib/Target/BPF/CMakeLists.txt
llvm/test/CodeGen/BPF/assembler-disassembler.s

Removed: 




diff  --git a/clang/lib/Basic/Targets/BPF.cpp b/clang/lib/Basic/Targets/BPF.cpp
index e3fbbb720d0694..26a54f631fcfc4 100644
--- a/clang/lib/Basic/Targets/BPF.cpp
+++ b/clang/lib/Basic/Targets/BPF.cpp
@@ -35,6 +35,9 @@ void BPFTargetInfo::getTargetDefines(const LangOptions ,
 Builder.defineMacro("__BPF_CPU_VERSION__", "0");
 return;
   }
+
+  Builder.defineMacro("__BPF_FEATURE_ARENA_CAST");
+
   if (CPU.empty() || CPU == "generic" || CPU == "v1") {
 Builder.defineMacro("__BPF_CPU_VERSION__", "1");
 return;

diff  --git a/clang/test/Preprocessor/bpf-predefined-macros.c 
b/clang/test/Preprocessor/bpf-predefined-macros.c
index ff4d00ac3bcfcc..fea24d1ea0ff7b 100644
--- a/clang/test/Preprocessor/bpf-predefined-macros.c
+++ b/clang/test/Preprocessor/bpf-predefined-macros.c
@@ -61,6 +61,9 @@ int r;
 #ifdef __BPF_FEATURE_ST
 int s;
 #endif
+#ifdef __BPF_FEATURE_ARENA_CAST
+int t;
+#endif
 
 // CHECK: int b;
 // CHECK: int c;
@@ -90,6 +93,11 @@ int s;
 // CPU_V4: int r;
 // CPU_V4: int s;
 
+// CPU_V1: int t;
+// CPU_V2: int t;
+// CPU_V3: int t;
+// CPU_V4: int t;
+
 // CPU_GENERIC: int g;
 
 // CPU_PROBE: int f;

diff  --git a/llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp 
b/llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp
index 0d1eef60c3b550..3145bc3d19f5dc 100644
--- a/llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp
+++ b/llvm/lib/Target/BPF/AsmParser/BPFAsmParser.cpp
@@ -271,6 +271,7 @@ struct BPFOperand : public MCParsedAsmOperand {
 .Case("xchg32_32", true)
 

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;
+
+def warn_func_effect_throws_or_catches : Warning<
+  "'%0' function '%1' must not throw or catch exceptions">,
+  InGroup;
+
+def note_func_effect_throws_or_catches : Note<
+  "'%1' cannot be inferred '%0' because it throws or catches exceptions">;
+
+def warn_func_effect_has_static_local : Warning<
+  "'%0' function '%1' must not have static locals">,
+  InGroup;
+
+def note_func_effect_has_static_local : Note<
+  "'%1' cannot be inferred '%0' because it has a static local">;
+
+def warn_func_effect_uses_thread_local : Warning<
+  "'%0' function '%1' must not use thread-local variables">,
+  InGroup;
+
+def note_func_effect_uses_thread_local : Note<
+  "'%1' cannot be inferred '%0' because it uses a thread-local variable">;
+
+def warn_func_effect_calls_objc : Warning<
+  "'%0' function '%1' must not access an ObjC method or property">,
+  InGroup;
+
+def note_func_effect_calls_objc : Note<
+  "'%1' cannot be inferred '%0' because it accesses an ObjC method or 
property">;
+
+def warn_func_effect_calls_disallowed_func : Warning<
+  "'%0' function '%1' must not call non-'%0' function '%2'">,
+  InGroup;
+
+// UNTESTED
+def warn_func_effect_calls_disallowed_expr : Warning<
+  "'%0' function '%1' must not call non-'%0' expression">,
+  InGroup;
+
+def note_func_effect_calls_disallowed_func : Note<
+  "'%1' cannot be inferred '%0' because it calls non-'%0' function '%2'">;
+
+def note_func_effect_call_extern : Note<
+  "'%1' cannot be inferred '%0' because it has no definition in this 
translation unit">;
+
+def note_func_effect_call_not_inferrable : Note<
+  "'%1' does not permit inference of '%0'">;
+
+def note_func_effect_call_virtual : Note<
+  "'%1' cannot be inferred '%0' because it is virtual">;
+
+def note_func_effect_call_func_ptr : Note<
+  "'%1' cannot be inferred '%0' because it is a function pointer">;
+
+// TODO: Not currently being generated
+// def warn_perf_annotation_implies_noexcept : Warning<
+//  "'%0' function should be declared noexcept">,
+//  InGroup;
+
+// TODO: Not currently being generated
+def warn_func_effect_false_on_type : Warning<
+  "only functions/methods/blocks may be declared %0(false)">,
+  InGroup;
+
+// TODO: can the usual template expansion notes be used?
+def note_func_effect_from_template : Note<
+  "in template expansion here">;

Sirraide wrote:

Iirc you should get those notes automatically if you issue a diagnostic while 
performing template instantiation. I’m not sure you can easily access where a 
template is being instantiated from while you’re instantiating it.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;

Sirraide wrote:

Hmm, I’m not sure I follow; `%0` is the first thing you pass to the diagnostic, 
`%1` the second, so swapping `%0` and `%1` in the note and swapping the order 
in which you pass the args to the diagnostic should work, or am I missing 
something?

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -3666,11 +3673,14 @@ void FunctionProtoType::Profile(llvm::FoldingSetNodeID 
, QualType Result,
   // Finally we have a trailing return type flag (bool)
   // combined with AArch64 SME Attributes, to save space:
   //  int
+  // Then add the FunctionEffects
   //
   // There is no ambiguity between the consumed arguments and an empty EH
   // spec because of the leading 'bool' which unambiguously indicates
   // whether the following bool is the EH spec or part of the arguments.
 
+  ID.AddPointer(epi.FunctionEffects.getOpaqueValue()); // TODO: Where???

dougsonos wrote:

Thanks; this call seems to be taking a lot of care about this but it does seem 
to relate to how various parts are optional.

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;
+
+def warn_func_effect_throws_or_catches : Warning<
+  "'%0' function '%1' must not throw or catch exceptions">,
+  InGroup;
+
+def note_func_effect_throws_or_catches : Note<
+  "'%1' cannot be inferred '%0' because it throws or catches exceptions">;
+
+def warn_func_effect_has_static_local : Warning<
+  "'%0' function '%1' must not have static locals">,
+  InGroup;
+
+def note_func_effect_has_static_local : Note<
+  "'%1' cannot be inferred '%0' because it has a static local">;
+
+def warn_func_effect_uses_thread_local : Warning<
+  "'%0' function '%1' must not use thread-local variables">,
+  InGroup;
+
+def note_func_effect_uses_thread_local : Note<
+  "'%1' cannot be inferred '%0' because it uses a thread-local variable">;
+
+def warn_func_effect_calls_objc : Warning<
+  "'%0' function '%1' must not access an ObjC method or property">,
+  InGroup;
+
+def note_func_effect_calls_objc : Note<
+  "'%1' cannot be inferred '%0' because it accesses an ObjC method or 
property">;
+
+def warn_func_effect_calls_disallowed_func : Warning<
+  "'%0' function '%1' must not call non-'%0' function '%2'">,
+  InGroup;
+
+// UNTESTED
+def warn_func_effect_calls_disallowed_expr : Warning<
+  "'%0' function '%1' must not call non-'%0' expression">,
+  InGroup;
+
+def note_func_effect_calls_disallowed_func : Note<
+  "'%1' cannot be inferred '%0' because it calls non-'%0' function '%2'">;
+
+def note_func_effect_call_extern : Note<
+  "'%1' cannot be inferred '%0' because it has no definition in this 
translation unit">;
+
+def note_func_effect_call_not_inferrable : Note<
+  "'%1' does not permit inference of '%0'">;
+
+def note_func_effect_call_virtual : Note<
+  "'%1' cannot be inferred '%0' because it is virtual">;
+
+def note_func_effect_call_func_ptr : Note<
+  "'%1' cannot be inferred '%0' because it is a function pointer">;
+
+// TODO: Not currently being generated
+// def warn_perf_annotation_implies_noexcept : Warning<
+//  "'%0' function should be declared noexcept">,
+//  InGroup;
+
+// TODO: Not currently being generated
+def warn_func_effect_false_on_type : Warning<
+  "only functions/methods/blocks may be declared %0(false)">,
+  InGroup;
+
+// TODO: can the usual template expansion notes be used?
+def note_func_effect_from_template : Note<
+  "in template expansion here">;

dougsonos wrote:

I do want to use those existing notes, but I couldn't figure out how to get the 
instantiation location (from the late stage of Sema where the diagnostics are 
being generated).

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits


@@ -1402,6 +1402,29 @@ def CXX11NoReturn : InheritableAttr {
   let Documentation = [CXX11NoReturnDocs];
 }
 
+def NoLock : DeclOrTypeAttr {
+  let Spellings = [CXX11<"clang", "nolock">,
+   C23<"clang", "nolock">,
+   GNU<"clang_nolock">];
+
+  // Subjects - not needed?
+  //let Subjects = SubjectList<[FunctionLike, Block, TypedefName], ErrorDiag>;

Sirraide wrote:

I’m pretty sure `AnnotateType` is a rather unusual attribute.

> that type attributes have some built-in defense.

Hmm, you’re right, my bad, it’s a `DeclOrTypeAttr`, and a lot of those don’t 
have a `Subjects` list, so in that case if it works without one, then that’s 
fine I’d say. And yes, tests for appertainment are a good idea.


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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -10778,6 +10778,101 @@ def warn_imp_cast_drops_unaligned : Warning<
   "implicit cast from type %0 to type %1 drops __unaligned qualifier">,
   InGroup>;
 
+def warn_func_effect_allocates : Warning<
+  "'%0' function '%1' must not allocate or deallocate memory">,
+  InGroup;
+
+def note_func_effect_allocates : Note<
+  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;

dougsonos wrote:

Yeah, the code generating warnings/notes always puts the effect before the 
function name, so there's consistency there and inconsistency here:
```
def warn_func_effect_allocates : Warning<
  "'%0' function '%1' must not allocate or deallocate memory">,
  InGroup;

def note_func_effect_allocates : Note<
  "'%1' cannot be inferred '%0' because it allocates/deallocates memory">;
```

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


[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-12 Thread Ian Anderson via cfe-commits

ian-twilightcoder wrote:

> > Sometimes it does confuse clang, at least I saw problems with a `typedef 
> > enum` when I made an include-once header `textual`.
> 
> Ok, I see. I would just consider it a bug, not a design decision.
> 
> > That's correct. `#import` is an external source - often it comes from the 
> > users of the header and not the author, and the users might not be 
> > consistent with each other. `textual` comes from the author and a much 
> > stronger indicator of intent.
> 
> Hmm, I need to think more about it. Usually I prefer for modular builds to 
> act like non-modular as it minimizes the surprises and allows to have a 
> portable code. But I haven't really considered the implications of such 
> preference.

Yes generally, but modules build more headers than non-modular builds, nothing 
we can do about that.

> I see why you prefer to give more priority to `textual`. To give a different 
> perspective, what if a developer wants to use a newer library, for example, 
> ncurses. The rest of SDK expects an older version and the developer might 
> need to do some header gymnastics to make it work. So there are cases when 
> developers need to go against library author's intent. I'm thinking that 
> library authors aren't able to predict all the ways their library is used, so 
> it is useful to have some flexibility around that, even at the cost of 
> misusing the library. But this is a general opinion, I don't have specific 
> data about the needs to tweak libraries or the risks of a library misuse. So 
> the opinion isn't particularly strong.

That one seems like an edge case, and using `#import` wouldn't necessarily help 
you because the SDK module could build first before your `#import` is seen.

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread via cfe-commits

eddyz87 wrote:

Hi @efriedma-quic,

> That said, this isn't handling "unsigned int" correctly. "unsigned int" is 
> supposed to be sign-extended on RISC-V targets. (How you resolve the conflict 
> with PowerPC, where "unsigned int" is supposed to be zero-extended, I'm not 
> sure.)

Could you please elaborate a bit?
My understanding is that you refer to the following part of the 
[specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):

> In RV64, 32-bit types, such as int, are stored in integer registers as proper 
> sign extensions of their
> 32-bit values; that is, bits 63..31 are all equal. This restriction holds 
> even for unsigned 32-bit types.

I assume that sign extension operations for RV64 take care of this detail.
The way I understand this pull request -- clang would now guarantee sign or 
zero extension for all integral function parameters. Given that extension would 
be done according to the platform rules, why do you think this could be an 
issue?

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits


@@ -1402,6 +1402,29 @@ def CXX11NoReturn : InheritableAttr {
   let Documentation = [CXX11NoReturnDocs];
 }
 
+def NoLock : DeclOrTypeAttr {
+  let Spellings = [CXX11<"clang", "nolock">,
+   C23<"clang", "nolock">,
+   GNU<"clang_nolock">];
+
+  // Subjects - not needed?
+  //let Subjects = SubjectList<[FunctionLike, Block, TypedefName], ErrorDiag>;

dougsonos wrote:

I was cribbing from AnnotateType which also has no Subjects. I added these 
tests, which seem to indicate that type attributes have some built-in defense.
```
int nl_var [[clang::nolock]]; // expected-warning {{ 'nolock' only applies to 
function types; type here is 'int' }}
struct nl_struct {} [[clang::nolock]]; // expected-warning {{ attribute 
'nolock' is ignored, place it after "struct" to apply attribute to type 
declaration }}
struct [[clang::nolock]] nl_struct2 {}; // expected-error {{ 'nolock' attribute 
cannot be applied to a declaration }}
```

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread via cfe-commits

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


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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

dougsonos wrote:

> > * Does the FunctionEffect / FunctionEffectSet abstraction make sense 
> > (Type.h)? The idea is that an abstract effect system for functions could 
> > easily support things like "TCB with types" or adding "nowait" to the 
> > "nolock/noalloc" group of effects.
> 
> Hmm, this is a difficult question. Generally, I would probably prefer to just 
> hard-code whatever effects we need right now, perhaps as something like a 
> bitmask; from what I recall, none of the effects take arguments or anything 
> like that, so that would be possible in that case (these are just my personal 
> observations, though; I don’t have every last detail of this feature 
> memorised, so if I’m missing something obvious, please let me know); my main 
> concern is that the current implementation might be a bit too general. In 
> particular, this seems like a lot of—if not too much—machinery for 
> implementing a grand total of two function attributes.
> 
> Because, sure, making it extensible doesn’t sound like a bad idea on paper, 
> but adding any effects would likely require significant modifications to 
> other parts of the compiler as well, so if a situation should arise where we 
> do need to handle more complex effects, we should be able to refactor it 
> whenever that comes up. For the time being, a simpler effect system may serve 
> us better (and should also be more straight-forward to refactor if need be).
> 
> Perhaps, let’s say that, unless it’s likely that we may end up adding effects 
> that require more storage than a single bit or two in the foreseeable future, 
> then I’d rather just have it be a bitmask. The way this is implemented 
> currently does remind me at least in part of attributes, but attributes are 
> very varied and _do_ take arguments, so I’m not sure the two systems are 
> really comparable.
> 
> @AaronBallman I recall you having some opinions on adding data to 
> `FunctionProtoType`s the other day, wdyt about this?



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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Doug Wyatt via cfe-commits

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


[clang] Add support for builtin_verbose_trap (PR #79230)

2024-03-12 Thread Peiming Liu via cfe-commits

https://github.com/PeimingLiu updated 
https://github.com/llvm/llvm-project/pull/79230

>From 678cd8ea37f1d02c70fd09b7107542c8301c3bd2 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka 
Date: Tue, 16 Jan 2024 13:18:09 -0800
Subject: [PATCH 01/10] Add support for builtin_verbose_trap

The builtin causes the program to stop its execution abnormally and shows a
human-readable description of the reason for the termination when a debugger is
attached or in a symbolicated crash log.

The motivation for the builtin is explained in the following RFC:

https://discourse.llvm.org/t/rfc-adding-builtin-verbose-trap-string-literal/75845
---
 clang/docs/LanguageExtensions.rst | 48 ++
 clang/include/clang/AST/Expr.h|  5 ++
 clang/include/clang/Basic/Builtins.td |  6 +++
 .../clang/Basic/DiagnosticSemaKinds.td|  2 +
 clang/lib/AST/ExprConstant.cpp| 18 +--
 clang/lib/CodeGen/CGBuiltin.cpp   | 12 +
 clang/lib/CodeGen/CGDebugInfo.cpp | 42 
 clang/lib/CodeGen/CGDebugInfo.h   | 20 
 clang/lib/Sema/SemaChecking.cpp   | 22 +
 .../CodeGenCXX/debug-info-verbose-trap.cpp| 49 +++
 clang/test/SemaCXX/verbose-trap.cpp   | 28 +++
 11 files changed, 249 insertions(+), 3 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/debug-info-verbose-trap.cpp
 create mode 100644 clang/test/SemaCXX/verbose-trap.cpp

diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c1420079f75118..4526bc2df53e42 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3379,6 +3379,54 @@ Query for this feature with 
``__has_builtin(__builtin_debugtrap)``.
 
 Query for this feature with ``__has_builtin(__builtin_trap)``.
 
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its execution abnormally
+and shows a human-readable description of the reason for the termination when a
+debugger is attached or in a symbolicated crash log.
+
+**Syntax**:
+
+.. code-block:: c++
+
+__builtin_verbose_trap(const char *reason)
+
+**Description**
+
+``__builtin_verbose_trap`` is lowered to the ` ``llvm.trap`` 
`_ builtin.
+Additionally, clang emits debug metadata that represents an artificial inline
+frame whose name encodes the string passed to the builtin, prefixed by a 
"magic"
+prefix.
+
+For example, consider the following code:
+
+.. code-block:: c++
+
+void foo(int* p) {
+  if (p == nullptr)
+__builtin_verbose_trap("Argument_must_not_be_null");
+}
+
+The debug metadata would look as if it were produced for the following code:
+
+.. code-block:: c++
+
+__attribute__((always_inline))
+inline void "__llvm_verbose_trap: Argument_must_not_be_null"() {
+  __builtin_trap();
+}
+
+void foo(int* p) {
+  if (p == nullptr)
+"__llvm_verbose_trap: Argument_must_not_be_null"();
+}
+
+However, the LLVM IR would not actually contain a call to the artificial
+function — it only exists in the debug metadata.
+
+Query for this feature with ``__has_builtin(__builtin_verbose_trap)``.
+
 ``__builtin_nondeterministic_value``
 
 
diff --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
index 59f0aee2c0cedd..68447b19a4a107 100644
--- a/clang/include/clang/AST/Expr.h
+++ b/clang/include/clang/AST/Expr.h
@@ -775,6 +775,11 @@ class Expr : public ValueStmt {
  const Expr *PtrExpression, ASTContext ,
  EvalResult ) const;
 
+  /// If the current Expr can be evaluated to a pointer to a null-terminated
+  /// constant string, return the constant string (without the terminating 
null)
+  /// in Result. Return true if it succeeds.
+  bool tryEvaluateString(std::string , ASTContext ) const;
+
   /// Enumeration used to describe the kind of Null pointer constant
   /// returned from \c isNullPointerConstant().
   enum NullPointerConstantKind {
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index 22e616e6cde599..217c09e85a55cc 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1096,6 +1096,12 @@ def Trap : Builtin {
   let Prototype = "void()";
 }
 
+def VerboseTrap : Builtin {
+  let Spellings = ["__builtin_verbose_trap"];
+  let Attributes = [NoThrow, NoReturn];
+  let Prototype = "void(char const*)";
+}
+
 def Debugtrap : Builtin {
   let Spellings = ["__builtin_debugtrap"];
   let Attributes = [NoThrow];
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index a1c32abb4dcd88..40482a964b39d5 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ 

[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits

Sirraide wrote:

> * Conversions between functions / function pointers with and without the 
> attribute work in C++ but not in C and I'm a bit lost (there's a bunch of 
> debug logging around this e.g. Sema::IsFunctionConversion and 
> Sema::ImpCastExprToType)

Er, I’ll see if I can find some time to take a look at this, but I’m not sure 
what the problem is off the top of my head.

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


[clang] [clang][RISCV] Enable RVV with function attribute __attribute__((target("arch=+v"))) (PR #83674)

2024-03-12 Thread Craig Topper via cfe-commits

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


[clang] [clang][RISCV] Enable RVV with function attribute __attribute__((target("arch=+v"))) (PR #83674)

2024-03-12 Thread Craig Topper via cfe-commits

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


[clang] [clang][RISCV] Enable RVV with function attribute __attribute__((target("arch=+v"))) (PR #83674)

2024-03-12 Thread Craig Topper via cfe-commits


@@ -8927,8 +8927,13 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
 }
   }
 
-  if (T->isRVVSizelessBuiltinType())
-checkRVVTypeSupport(T, NewVD->getLocation(), cast(CurContext));
+  if (T->isRVVSizelessBuiltinType() && isa(CurContext)) {
+const FunctionDecl *FD = cast(CurContext);
+llvm::StringMap CallerFeatureMap;
+Context.getFunctionFeatureMap(CallerFeatureMap, FD);

topperc wrote:

Does this impact compile time if the RVV types are used many times in a 
function as they would be for intrinsic code?

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits

Sirraide wrote:

> - Does the FunctionEffect / FunctionEffectSet abstraction make sense 
> (Type.h)? The idea is that an abstract effect system for functions could 
> easily support things like "TCB with types" or adding "nowait" to the 
> "nolock/noalloc" group of effects.

Hmm, this is a difficult question. Generally, I would probably prefer to just 
hard-code whatever effects we need right now, perhaps as something like a 
bitmask; from what I recall, none of the effects take arguments or anything 
like that, so that would be possible in that case (these are just my personal 
observations, though; I don’t have every last detail of this feature memorised, 
so if I’m missing something obvious, please let me know); my main concern is 
that the current implementation might be a bit too general. In particular, this 
seems like a lot of—if not too much—machinery for implementing a grand total of 
two function attributes.

Because, sure, making it extensible doesn’t sound like a bad idea on paper, but 
adding any effects would likely require significant modifications to other 
parts of the compiler as well, so if a situation should arise where we do need 
to handle more complex effects, we should be able to refactor it whenever that 
comes up. For the time being, a simpler effect system may serve us better (and 
should also be more straight-forward to refactor if need be).

Perhaps, let’s say that, unless it’s likely that we may end up adding effects 
that require more storage than a single bit or two in the foreseeable future, 
then I’d rather just have it be a bitmask. The way this is implemented 
currently does remind me at least in part of attributes, but attributes are 
very varied and *do* take arguments, so I’m not sure the two systems are really 
comparable.

@AaronBallman I recall you having some opinions on adding data to 
`FunctionProtoType`s the other day, wdyt about this?

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


[clang] [llvm] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

2024-03-12 Thread Anton Korobeynikov via cfe-commits

asl wrote:

> Maybe `emitRawPointerFromAddress` is better. I see a lot of functions 
> starting with `emit` in CodeGen.

Works for me!

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread via cfe-commits

Sirraide wrote:

> * FunctionEffect/FunctionEffectSet need to be serialized as part of 
> FunctionProtoType

That’s in `TypeProperties.td` from what I recall. You might be able to pack 
this into an integer or something similar perhaps.

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


[clang] [HLSL] Implement array temporary support (PR #79382)

2024-03-12 Thread Richard Smith via cfe-commits


@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public 
llvm::FoldingSetNode {
 return T->getTypeClass() == ConstantArray ||
T->getTypeClass() == VariableArray ||
T->getTypeClass() == IncompleteArray ||
-   T->getTypeClass() == DependentSizedArray;
+   T->getTypeClass() == DependentSizedArray ||
+   T->getTypeClass() == ArrayParameter;
   }
 };
 
 /// Represents the canonical version of C arrays with a specified constant 
size.
 /// For example, the canonical type for 'int A[4 + 4*100]' is a
 /// ConstantArrayType where the element type is 'int' and the size is 404.
-class ConstantArrayType final
-: public ArrayType,
-  private llvm::TrailingObjects {

zygoloid wrote:

The size expression is usually not part of a constant array type. Normally, all 
we want as part of the type node is the bound, and the size expression if 
needed can be found on the `ArrayTypeLoc`. The rare special case being handled 
here is that if the array bound is instantiation-dependent but not dependent, 
then we need to preserve the expression in the type (not just in the `TypeLoc`) 
because it affects (for example) whether two template declarations involving 
such a type are considered to declare the same template. Because this is a very 
rare case, and `ConstantArrayType`s can be relatively common (eg, as the types 
of string literals), it seemed preferable to not store the `Expr*` if it's not 
needed, but in absolute terms it's probably a minor difference in memory usage, 
so it's probably fine to remove this optimization.

If we want to keep the optimization, perhaps we could replace the `Size` and 
`SizeExpr` fields with a pointer union that can hold either a <= 63-bit array 
bound (the common case) or a pointer to a slab-allocated pair of `APInt` and 
`const Expr*` (in the case where the bound doesn't fit in 63 bits or the size 
expression is instantiation-dependent).

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


[clang] nolock/noalloc attributes (PR #84983)

2024-03-12 Thread Andrew Pinski via cfe-commits

pinskia wrote:

Does it make sense to have some C testcases too? Likewise some testcases 
testing the __attribute__ style attribute?
I would say more testcases the better really.

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


[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

2024-03-12 Thread Eli Friedman via cfe-commits

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


  1   2   3   4   5   >