[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

[Justin Lebar via Phabricator via cfe-commits]

jlebar added a comment.

Hey, I'm leaving on a vacation tomorrow and didn't have a chance to get to
this review today.

Is that ok?  I'm not bringing my work laptop, but I could look at it on my
personal laptop.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88345/new/

https://reviews.llvm.org/D88345

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

[PATCH] D88771: [PATCH] Fix typo (NFC)

[Jiao Lu via Phabricator via cfe-commits]

jiaolu created this revision.
Herald added subscribers: cfe-commits, luismarques, apazos, sameer.abuasal, 
pzheng, s.egerton, lenary, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb.
Herald added a project: clang.
jiaolu requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88771

Files:
  clang/test/Driver/riscv-cpus.c


Index: clang/test/Driver/riscv-cpus.c
===
--- clang/test/Driver/riscv-cpus.c
+++ clang/test/Driver/riscv-cpus.c
@@ -28,7 +28,7 @@
 // MCPU-ABI-SIFIVE-U54: "-target-feature" "+c" "-target-feature" "+64bit"
 // MCPU-ABI-SIFIVE-U54: "-target-abi" "lp64"
 
-// march overwirte mcpu's default march
+// march overwrite mcpu's default march
 // RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=sifive-e31 -march=rv32imc 
| FileCheck -check-prefix=MCPU-MARCH %s
 // MCPU-MARCH: "-nostdsysteminc" "-target-cpu" "sifive-e31" "-target-feature" 
"+m" "-target-feature" "+c"
 // MCPU-MARCH: "-target-abi" "ilp32"


Index: clang/test/Driver/riscv-cpus.c
===
--- clang/test/Driver/riscv-cpus.c
+++ clang/test/Driver/riscv-cpus.c
@@ -28,7 +28,7 @@
 // MCPU-ABI-SIFIVE-U54: "-target-feature" "+c" "-target-feature" "+64bit"
 // MCPU-ABI-SIFIVE-U54: "-target-abi" "lp64"
 
-// march overwirte mcpu's default march
+// march overwrite mcpu's default march
 // RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=sifive-e31 -march=rv32imc | FileCheck -check-prefix=MCPU-MARCH %s
 // MCPU-MARCH: "-nostdsysteminc" "-target-cpu" "sifive-e31" "-target-feature" "+m" "-target-feature" "+c"
 // MCPU-MARCH: "-target-abi" "ilp32"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu updated this revision to Diff 295950.
jasonliu added a comment.
Herald added subscribers: llvm-commits, nemanjai.
Herald added a project: LLVM.

An update follows up with the idea in D88748 .


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aix-data-sections.c
  clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp
  lld/COFF/LTO.cpp
  lld/Common/TargetOptionsCommandFlags.cpp
  lld/ELF/LTO.cpp
  lld/include/lld/Common/TargetOptionsCommandFlags.h
  lld/wasm/LTO.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/test/CodeGen/PowerPC/aix-alias.ll
  llvm/test/CodeGen/PowerPC/aix-bytestring.ll
  llvm/test/CodeGen/PowerPC/aix-extern-weak.ll
  llvm/test/CodeGen/PowerPC/aix-extern.ll
  llvm/test/CodeGen/PowerPC/aix-overflow-toc.py
  llvm/test/CodeGen/PowerPC/aix-readonly-with-relocation.ll
  llvm/test/CodeGen/PowerPC/aix-reference-func-addr-const.ll
  llvm/test/CodeGen/PowerPC/aix-return55.ll
  llvm/test/CodeGen/PowerPC/aix-weak.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-data-sections.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-data.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-lower-comm.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-mergeable-const.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-mergeable-str.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-rodata.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-symbol-rename.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-used.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-visibility.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llc/llc.cpp
  llvm/tools/lli/lli.cpp
  llvm/tools/llvm-isel-fuzzer/llvm-isel-fuzzer.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
  llvm/tools/lto/lto.cpp
  llvm/tools/opt/opt.cpp

Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -698,7 +698,8 @@
   Triple ModuleTriple(M->getTargetTriple());
   std::string CPUStr, FeaturesStr;
   TargetMachine *Machine = nullptr;
-  const TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  const TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(ModuleTriple);
 
   if (ModuleTriple.getArch()) {
 CPUStr = codegen::getCPUStr();
Index: llvm/tools/lto/lto.cpp
===
--- llvm/tools/lto/lto.cpp
+++ llvm/tools/lto/lto.cpp
@@ -218,7 +218,8 @@
 
 lto_module_t lto_module_create(const char* path) {
   lto_initialize();
-  llvm::TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  llvm::TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple());
   ErrorOr> M =
   LTOModule::createFromFile(*LTOContext, StringRef(path), Options);
   if (!M)
@@ -228,7 +229,8 @@
 
 lto_module_t lto_module_create_from_fd(int fd, const char *path, size_t size) {
   lto_initialize();
-  llvm::TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  llvm::TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple());
   ErrorOr> M = LTOModule::createFromOpenFile(
   *LTOContext, fd, StringRef(path), size, Options);
   if (!M)
@@ -241,7 +243,8 @@
  size_t map_size,
  off_t offset) {
   lto_initialize();
-  llvm::TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  llvm::TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple());
   ErrorOr> M = LTOModule::createFromOpenFileSlice(
   *LTOContext, fd, StringRef(path), map_size, offset, Options);
   if (!M)
@@ -251,7 +254,8 @@
 
 lto_module_t lto_module_create_from_memory(const void* mem, size_t length) {
   lto_initialize();
-  llvm::TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  llvm::TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple());
   ErrorOr> M =
   LTOModule::createFromBuffer(*LTOContext, mem, length, Options);
   if (!M)
@@ -263,7 +267,8 @@
  size_t length,
  const char *path) {
   lto_initialize();
-  llvm::TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags();
+  llvm::TargetOptions Options =
+  codegen::InitTargetOptionsFromCodeGenFlags(Triple());
   ErrorOr> M = LTOModule::createFromBuffer(
   *LTOContext, mem, length, Options, StringRef(path));
   if (!M)
@@ -274,7 +279,8 @@
 lto_module_t lto_module_create_in_local_context(const void *mem, size_t length,
 const char *path) {
   lto_initialize();
-  

[clang] a0a8f83 - [PATCH] Fix typo (NFC)

[Evandro Menezes via cfe-commits]

Author: Evandro Menezes
Date: 2020-10-02T21:19:14-05:00
New Revision: a0a8f83718454186686f9c11db72408cc36482e3

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

LOG: [PATCH] Fix typo (NFC)

Added: 


Modified: 
clang/test/Driver/riscv-cpus.c

Removed: 




diff  --git a/clang/test/Driver/riscv-cpus.c b/clang/test/Driver/riscv-cpus.c
index c22f6cce2cf6..15cd212e4fb4 100644
--- a/clang/test/Driver/riscv-cpus.c
+++ b/clang/test/Driver/riscv-cpus.c
@@ -28,7 +28,7 @@
 // MCPU-ABI-SIFIVE-U54: "-target-feature" "+c" "-target-feature" "+64bit"
 // MCPU-ABI-SIFIVE-U54: "-target-abi" "lp64"
 
-// march overwirte mcpu's default march
+// march overwrite mcpu's default march
 // RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=sifive-e31 -march=rv32imc 
| FileCheck -check-prefix=MCPU-MARCH %s
 // MCPU-MARCH: "-nostdsysteminc" "-target-cpu" "sifive-e31" "-target-feature" 
"+m" "-target-feature" "+c"
 // MCPU-MARCH: "-target-abi" "ilp32"



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

[PATCH] D88594: [OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 reopened this revision.
jhuber6 added a comment.
This revision is now accepted and ready to land.

Reopening for now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88594/new/

https://reviews.llvm.org/D88594

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

[PATCH] D88594: [OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 295949.
jhuber6 added a comment.
Herald added subscribers: llvm-commits, delcypher.
Herald added a project: LLVM.

Adding an extra substitution in lit to solve the problem of automatically 
populating the test files with incompatible architectures.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88594/new/

https://reviews.llvm.org/D88594

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/target_incompatible_architecture_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp
  llvm/docs/TestingGuide.rst
  llvm/utils/lit/lit/llvm/config.py

Index: llvm/utils/lit/lit/llvm/config.py
===
--- llvm/utils/lit/lit/llvm/config.py
+++ llvm/utils/lit/lit/llvm/config.py
@@ -456,6 +456,8 @@
   self.make_itanium_abi_triple(self.config.target_triple)))
 self.config.substitutions.append(('%ms_abi_triple',
   self.make_msabi_triple(self.config.target_triple)))
+self.config.substitutions.append(('%arch_ptr_size',
+  sys.hash_info.width))
 self.config.substitutions.append(
 ('%resource_dir', builtin_include_dir))
 
Index: llvm/docs/TestingGuide.rst
===
--- llvm/docs/TestingGuide.rst
+++ llvm/docs/TestingGuide.rst
@@ -582,6 +582,9 @@
``i686-pc-mingw32``. This allows a test to run with a specific ABI without
constraining it to a specific triple.
 
+``%arch_ptr_size``
+   Substitutes whether or not the architecture is 32-bit or 64-bit
+
 **FileCheck-specific substitutions:**
 
 ``%ProtectFileCheckOutput``
Index: clang/test/OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp
===
--- clang/test/OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp
+++ clang/test/OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp
@@ -1,16 +1,16 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix OMP45
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple %itanium_abi_triple -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix OMP45
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP5 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix OMP50
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple %itanium_abi_triple -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix OMP50
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple %itanium_abi_triple -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=45 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=50 -DOMP5 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -DOMP5 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple %itanium_abi_triple -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -DOMP5 

[clang] e25bf25 - [Driver] Move detectLibcxxIncludePath to ToolChain

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2020-10-02T18:37:20-07:00
New Revision: e25bf2592060e7751f8b14522c97081ce2047175

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

LOG: [Driver] Move detectLibcxxIncludePath to ToolChain

This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.

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

Added: 
clang/test/Driver/Inputs/basic_fuchsia_tree/include/c++/v1/.keep

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index 7495e08fe6e6..db4c4a730232 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -575,6 +575,9 @@ class ToolChain {
   // given compilation arguments.
   virtual UnwindLibType GetUnwindLibType(const llvm::opt::ArgList ) const;
 
+  // Detect the highest available version of libc++ in base path.
+  virtual std::string detectLibcxxIncludePath(StringRef Base) const;
+
   /// AddClangCXXStdlibIncludeArgs - Add the clang -cc1 level arguments to set
   /// the include paths to use for the given C++ standard library type.
   virtual void

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 8991216da676..8e98e3206880 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -924,6 +924,29 @@ void ToolChain::addExternCSystemIncludeIfExists(const 
ArgList ,
   }
 }
 
+std::string ToolChain::detectLibcxxIncludePath(StringRef Base) const {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Base, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  if (!MaxVersion)
+return "";
+  SmallString<128> P(Base);
+  llvm::sys::path::append(P, MaxVersionString);
+  return std::string(P.str());
+}
+
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.

diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 781179be39a3..e5f23ee38555 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -319,8 +319,8 @@ void Fuchsia::AddClangCXXStdlibIncludeArgs(const ArgList 
,
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++", "v1");
-addSystemInclude(DriverArgs, CC1Args, P.str());
+llvm::sys::path::append(P, "..", "include", "c++");
+addSystemInclude(DriverArgs, CC1Args, detectLibcxxIncludePath(P.str()));
 break;
   }
 

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index f3843685a522..3778b6f297ed 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2877,31 +2877,11 @@ void Generic_GCC::AddClangCXXStdlibIncludeArgs(const 
ArgList ,
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
-}
-
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
+std::string IncludePath = detectLibcxxIncludePath(Path);
 if (IncludePath.empty() || !getVFS().exists(IncludePath))
   return 

[PATCH] D88666: DirectoryWatcher: add an implementation for Windows

[Adrian McCarthy via Phabricator via cfe-commits]

amccarth added a comment.

I'm sorry.  I haven't had to time to review the entire change yet, but I 
thought I'd share some early feedback now and take more of a look on Monday.

The high level issues on my mind:

I'm wondering whether this has been overcomplicated with the overlapped IO.  If 
the monitoring thread used `FindFirstChangeNotificationW` to get a waitable 
handle and then used, then you'd be able to call `ReadDirectoryChangesW` 
synchronously.  In order to allow the parent thread signal to quit, they'd just 
need an Event and the monitor thread would use `WaitForMultipleObjects` to wait 
for either handle to become signaled.  Maybe I'm overlooking something, but it 
might be worth a few minutes of consideration.

We'll also have to think about how to test this.

The lower level issues that I've spotted are inlined.




Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:33
 class DirectoryWatcherWindows : public clang::DirectoryWatcher {
+  OVERLAPPED ovlIO;
+

The `ovlIO` name isn't consistent with LLVM style.



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:36
+  alignas(DWORD)
+  CHAR Buffer[4 * (sizeof(FILE_NOTIFY_INFORMATION) + MAX_PATH * 
sizeof(WCHAR))];
+

If it were me, I'd probably make this a `std::vector`.

* If an off-by-one bug causes an overrun of one WCHAR, you could trash a 
crucial member variable.  On the heap, the damage is less likely to be 
catastrophic.
* You wouldn't need `alignas`.
* I don't think these are created in a tight loop, so the overhead doesn't 
concern me.

Also, I'd probably go with a slightly more descriptive name, like 
`Notifications` rather than `Buffer`.



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:82
+DirectoryWatcherCallback Receiver)
+: Callback(Receiver) {
+  // Pre-compute the real location as we will be handing over the directory

There's a lot going on in this constructor.  Is this how the other 
implementations are arranged?

Would it make sense to just initialize the object, and save most of the actual 
work to a `Watch` method?



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:87
+DWORD dwLength = GetFinalPathNameByHandleW(hDirectory, NULL, 0, 0);
+std::unique_ptr buffer{new WCHAR[dwLength + 1]};
+(void)GetFinalPathNameByHandleW(hDirectory, buffer.get(), dwLength + 1, 0);

compnerd wrote:
> aaron.ballman wrote:
> > Is a smart pointer required here or could you use `std::vector` and 
> > reserve the space that way?
> Sure, I can convert this to a `std::vector` instead.
* I guess it's fine to use the array form of `std::unique_ptr` (but then you 
should `#include `).  If it were me, I'd probably just use a 
`std::wstring` or `std::vector`.

* `dwLength` already includes the size of the null terminator.  Your first 
`GetFinalPathNameByHandleW` function "fails" because the buffer is too small.  
The does says that, if it fails because the buffer is too small, then the 
return value is the required size _including_ the null terminator.  (In the 
success case, it's the size w/o the terminator.)

* I know this is the Windows-specific implementation, but it might be best to 
just the Support api ` realPathFromHandle`, which does this and has tests.



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:88
+std::unique_ptr buffer{new WCHAR[dwLength + 1]};
+(void)GetFinalPathNameByHandleW(hDirectory, buffer.get(), dwLength + 1, 0);
+sys::windows::UTF16ToUTF8(buffer.get(), dwLength + 1, Path);

I don't think you want to ignore the return value, since it'll tell you exactly 
how many characters you actually got back (or whether there was an error).  
Again, I recommend using `realPathFromHandle` from Support.



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:94
+  ovlIO.hEvent =
+  CreateEvent(NULL, /*bManualReset=*/TRUE, /*bInitialState=*/FALSE, NULL);
+  assert(ovlIO.hEvent);

No real difference here, but, for consistency, please make this `CreateEventW` 
with the explicit -W suffix.



Comment at: clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp:189
+  HandlerThread.join();
+  WatcherThread.join();
+}

I think this leaks the `ovlIO.hEvent`.  After you've joined both threads, make 
sure to call `::CloseHandle()`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88666/new/

https://reviews.llvm.org/D88666

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

[PATCH] D86021: [IR] Make nosync, nofree and willreturn default for intrinsics.

[Stefan Stipanovic via Phabricator via cfe-commits]

sstefan1 added a comment.

@nikic do you have a preference on any of the suggested names?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86021/new/

https://reviews.llvm.org/D86021

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

[clang] 9a48411 - Revert "[Driver] Move detectLibcxxIncludePath to ToolChain"

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2020-10-02T16:59:28-07:00
New Revision: 9a48411f35a122ac8755a8453887b919c77daf3f

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

LOG: Revert "[Driver] Move detectLibcxxIncludePath to ToolChain"

This reverts commit a594fd28e373cb7cd348cf01f6a90e055bf6cf6d which
is failign on some bots.

Added: 


Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index db4c4a730232..7495e08fe6e6 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -575,9 +575,6 @@ class ToolChain {
   // given compilation arguments.
   virtual UnwindLibType GetUnwindLibType(const llvm::opt::ArgList ) const;
 
-  // Detect the highest available version of libc++ in base path.
-  virtual std::string detectLibcxxIncludePath(StringRef Base) const;
-
   /// AddClangCXXStdlibIncludeArgs - Add the clang -cc1 level arguments to set
   /// the include paths to use for the given C++ standard library type.
   virtual void

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 8e98e3206880..8991216da676 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -924,29 +924,6 @@ void ToolChain::addExternCSystemIncludeIfExists(const 
ArgList ,
   }
 }
 
-std::string ToolChain::detectLibcxxIncludePath(StringRef Base) const {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  if (!MaxVersion)
-return "";
-  SmallString<128> P(Base);
-  llvm::sys::path::append(P, MaxVersionString);
-  return std::string(P.str());
-}
-
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.

diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index e5f23ee38555..781179be39a3 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -319,8 +319,8 @@ void Fuchsia::AddClangCXXStdlibIncludeArgs(const ArgList 
,
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++");
-addSystemInclude(DriverArgs, CC1Args, detectLibcxxIncludePath(P.str()));
+llvm::sys::path::append(P, "..", "include", "c++", "v1");
+addSystemInclude(DriverArgs, CC1Args, P.str());
 break;
   }
 

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 3778b6f297ed..f3843685a522 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2877,11 +2877,31 @@ void Generic_GCC::AddClangCXXStdlibIncludeArgs(const 
ArgList ,
   }
 }
 
+static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
+   StringRef base) {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
+}
+
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = detectLibcxxIncludePath(Path);
+std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
 if (IncludePath.empty() || !getVFS().exists(IncludePath))
   return false;
 addSystemInclude(DriverArgs, CC1Args, IncludePath);



___
cfe-commits mailing list

[PATCH] D88377: Diagnose invalid target ID for AMDGPU toolchain for assembler

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2cd75f738ec6: Diagnose invalid target ID for AMDGPU 
toolchain for assembler (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88377/new/

https://reviews.llvm.org/D88377

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/Driver/amdgpu-invalid-target-id.s

Index: clang/test/Driver/amdgpu-invalid-target-id.s
===
--- /dev/null
+++ clang/test/Driver/amdgpu-invalid-target-id.s
@@ -0,0 +1,45 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx908xnack -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=NOPLUS %s
+
+// NOPLUS: error: Invalid target ID: gfx908xnack
+
+// RUN: not %clang -target amdgcn-amd-amdpal \
+// RUN:   -mcpu=gfx908:xnack+:xnack+ -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=ORDER %s
+
+// ORDER: error: Invalid target ID: gfx908:xnack+:xnack+
+
+// RUN: not %clang -target amdgcn--mesa3d \
+// RUN:   -mcpu=gfx908:unknown+ -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=UNK %s
+
+// UNK: error: Invalid target ID: gfx908:unknown+
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx908:sram-ecc+:unknown+ -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=MIXED %s
+
+// MIXED: error: Invalid target ID: gfx908:sram-ecc+:unknown+
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx900:sram-ecc+ -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=UNSUP %s
+
+// UNSUP: error: Invalid target ID: gfx900:sram-ecc+
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx900:xnack -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=NOSIGN %s
+
+// NOSIGN: error: Invalid target ID: gfx900:xnack
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx900+xnack -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=NOCOLON %s
+
+// NOCOLON: error: Invalid target ID: gfx900+xnack
Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -240,8 +240,7 @@
 Action::OffloadKind DeviceOffloadingKind) const {
   HostTC.addClangTargetOptions(DriverArgs, CC1Args, DeviceOffloadingKind);
 
-  // Allow using target ID in --offload-arch.
-  StringRef GpuArch = translateTargetID(DriverArgs, CC1Args);
+  StringRef GpuArch = getGPUArch(DriverArgs);
   assert(!GpuArch.empty() && "Must have an explicit GPU arch.");
   (void) GpuArch;
   assert(DeviceOffloadingKind == Action::OFK_HIP &&
@@ -353,6 +352,7 @@
   if (!BoundArch.empty()) {
 DAL->eraseArg(options::OPT_mcpu_EQ);
 DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_mcpu_EQ), BoundArch);
+checkTargetID(*DAL);
   }
 
   return DAL;
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -94,11 +94,10 @@
   bool shouldSkipArgument(const llvm::opt::Arg *Arg) const;
 
 protected:
-  /// Translate -mcpu option containing target ID to cc1 options.
-  /// Returns the GPU name.
-  StringRef translateTargetID(const llvm::opt::ArgList ,
-  llvm::opt::ArgStringList ) const;
+  /// Check and diagnose invalid target ID specified by -mcpu.
+  void checkTargetID(const llvm::opt::ArgList ) const;
 
+  /// Get GPU arch from -mcpu without checking.
   StringRef getGPUArch(const llvm::opt::ArgList ) const;
 };
 
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -426,6 +426,8 @@
   DAL->append(A);
   }
 
+  checkTargetID(*DAL);
+
   if (!Args.getLastArgValue(options::OPT_x).equals("cl"))
 return DAL;
 
@@ -518,8 +520,6 @@
 const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ,
 Action::OffloadKind DeviceOffloadingKind) const {
-  // Allow using target ID in -mcpu.
-  translateTargetID(DriverArgs, CC1Args);
   // Default to "hidden" visibility, as object level linking will not be
   // supported for the foreseeable future.
   if (!DriverArgs.hasArg(options::OPT_fvisibility_EQ,
@@ -536,21 +536,17 @@
   getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
 }
 
-StringRef
-AMDGPUToolChain::translateTargetID(const llvm::opt::ArgList ,
-   llvm::opt::ArgStringList ) const {
+void AMDGPUToolChain::checkTargetID(
+const llvm::opt::ArgList ) const {
   StringRef TargetID = 

[clang] 2cd75f7 - Diagnose invalid target ID for AMDGPU toolchain for assembler

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T19:38:02-04:00
New Revision: 2cd75f738ec6b150719a9468372d77b7064ff340

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

LOG: Diagnose invalid target ID for AMDGPU toolchain for assembler

AMDGPU toolchain currently only diagnose invalid target ID for OpenCL
source compilation. Invalid target ID is not diagnosed for assembler.

This patch fixes that.

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

Added: 
clang/test/Driver/amdgpu-invalid-target-id.s

Modified: 
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/AMDGPU.h
clang/lib/Driver/ToolChains/HIP.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 656de9dd9e1e..c6087156642b 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -426,6 +426,8 @@ AMDGPUToolChain::TranslateArgs(const DerivedArgList , 
StringRef BoundArch,
   DAL->append(A);
   }
 
+  checkTargetID(*DAL);
+
   if (!Args.getLastArgValue(options::OPT_x).equals("cl"))
 return DAL;
 
@@ -518,8 +520,6 @@ void AMDGPUToolChain::addClangTargetOptions(
 const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ,
 Action::OffloadKind DeviceOffloadingKind) const {
-  // Allow using target ID in -mcpu.
-  translateTargetID(DriverArgs, CC1Args);
   // Default to "hidden" visibility, as object level linking will not be
   // supported for the foreseeable future.
   if (!DriverArgs.hasArg(options::OPT_fvisibility_EQ,
@@ -536,21 +536,17 @@ AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList 
) const {
   getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
 }
 
-StringRef
-AMDGPUToolChain::translateTargetID(const llvm::opt::ArgList ,
-   llvm::opt::ArgStringList ) const {
+void AMDGPUToolChain::checkTargetID(
+const llvm::opt::ArgList ) const {
   StringRef TargetID = DriverArgs.getLastArgValue(options::OPT_mcpu_EQ);
   if (TargetID.empty())
-return StringRef();
+return;
 
   llvm::StringMap FeatureMap;
   auto OptionalGpuArch = parseTargetID(getTriple(), TargetID, );
   if (!OptionalGpuArch) {
 getDriver().Diag(clang::diag::err_drv_bad_target_id) << TargetID;
-return StringRef();
   }
-
-  return OptionalGpuArch.getValue();
 }
 
 void ROCMToolChain::addClangTargetOptions(

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.h 
b/clang/lib/Driver/ToolChains/AMDGPU.h
index 0a91499c0cbf..55ef6e01967e 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.h
+++ b/clang/lib/Driver/ToolChains/AMDGPU.h
@@ -94,11 +94,10 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUToolChain : public 
Generic_ELF {
   bool shouldSkipArgument(const llvm::opt::Arg *Arg) const;
 
 protected:
-  /// Translate -mcpu option containing target ID to cc1 options.
-  /// Returns the GPU name.
-  StringRef translateTargetID(const llvm::opt::ArgList ,
-  llvm::opt::ArgStringList ) const;
+  /// Check and diagnose invalid target ID specified by -mcpu.
+  void checkTargetID(const llvm::opt::ArgList ) const;
 
+  /// Get GPU arch from -mcpu without checking.
   StringRef getGPUArch(const llvm::opt::ArgList ) const;
 };
 

diff  --git a/clang/lib/Driver/ToolChains/HIP.cpp 
b/clang/lib/Driver/ToolChains/HIP.cpp
index 25b3ab88bc02..07d72c073b4b 100644
--- a/clang/lib/Driver/ToolChains/HIP.cpp
+++ b/clang/lib/Driver/ToolChains/HIP.cpp
@@ -240,8 +240,7 @@ void HIPToolChain::addClangTargetOptions(
 Action::OffloadKind DeviceOffloadingKind) const {
   HostTC.addClangTargetOptions(DriverArgs, CC1Args, DeviceOffloadingKind);
 
-  // Allow using target ID in --offload-arch.
-  StringRef GpuArch = translateTargetID(DriverArgs, CC1Args);
+  StringRef GpuArch = getGPUArch(DriverArgs);
   assert(!GpuArch.empty() && "Must have an explicit GPU arch.");
   (void) GpuArch;
   assert(DeviceOffloadingKind == Action::OFK_HIP &&
@@ -353,6 +352,7 @@ HIPToolChain::TranslateArgs(const llvm::opt::DerivedArgList 
,
   if (!BoundArch.empty()) {
 DAL->eraseArg(options::OPT_mcpu_EQ);
 DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_mcpu_EQ), 
BoundArch);
+checkTargetID(*DAL);
   }
 
   return DAL;

diff  --git a/clang/test/Driver/amdgpu-invalid-target-id.s 
b/clang/test/Driver/amdgpu-invalid-target-id.s
new file mode 100644
index ..e20f09745d71
--- /dev/null
+++ b/clang/test/Driver/amdgpu-invalid-target-id.s
@@ -0,0 +1,45 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: not %clang -target amdgcn-amd-amdhsa \
+// RUN:   -mcpu=gfx908xnack -nostdlib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=NOPLUS %s
+
+// NOPLUS: error: Invalid target ID: gfx908xnack
+
+// RUN: not 

[PATCH] D88278: [PowerPC] Add builtins for xvtdiv(dp|sp) and xvtsqrt(dp|sp).

[Qing Shan Zhang via Phabricator via cfe-commits]

steven.zhang added a comment.

I think some follow up is needed to optimize the code sequence for

  cr = vec_test_div
  if (rotate_and_mask(cr, 62))
...

For now, we will copy the cr to gpr, and shift it to 61-64 bit,then, extract 
the bit and then compare to 0. the shift is not needed. Please double confirm 
to see if the peephole handle it well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88278/new/

https://reviews.llvm.org/D88278

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

[clang] cbd420c - [CUDA][HIP] Fix bound arch for offload action for fat binary

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T19:05:51-04:00
New Revision: cbd420c5ed8568774ace3ad8385b2346288e152c

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

LOG: [CUDA][HIP] Fix bound arch for offload action for fat binary

Currently CUDA/HIP toolchain uses "unknown" as bound arch
for offload action for fat binary. This causes -mcpu or -march
with "unknown" added in HIPToolChain::TranslateArgs or
CUDAToolChain::TranslateArgs.

This causes issue for https://reviews.llvm.org/D88377 since
HIP toolchain needs to check -mcpu in HIPToolChain::TranslateArgs.

The bound arch of offload action for fat binary is not really
used, therefore set it to CudaArch::UNUSED.

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

Added: 
clang/test/Driver/hip-toolchain-device-only.hip

Modified: 
clang/include/clang/Basic/Cuda.h
clang/lib/Basic/Cuda.cpp
clang/lib/Basic/Targets/NVPTX.cpp
clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
clang/lib/Driver/Driver.cpp
clang/test/Driver/hip-phases.hip

Removed: 




diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 19301e825bcf..93394f31abdc 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -37,6 +37,7 @@ const char *CudaVersionToString(CudaVersion V);
 CudaVersion CudaStringToVersion(const llvm::Twine );
 
 enum class CudaArch {
+  UNUSED,
   UNKNOWN,
   SM_20,
   SM_21,

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index 2abbe3e81e0a..7de42c1b90e5 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -64,6 +64,7 @@ struct CudaArchToStringMap {
   { CudaArch::GFX##gpu, "gfx" #gpu, "compute_amdgcn" }
 CudaArchToStringMap arch_names[] = {
 // clang-format off
+{CudaArch::UNUSED, "", ""},
 SM2(20, "compute_20"), SM2(21, "compute_20"), // Fermi
 SM(30), SM(32), SM(35), SM(37),  // Kepler
 SM(50), SM(52), SM(53),  // Maxwell

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index ef61b8f78946..aae89477e97d 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -204,6 +204,7 @@ void NVPTXTargetInfo::getTargetDefines(const LangOptions 
,
   case CudaArch::GFX1031:
   case CudaArch::LAST:
 break;
+  case CudaArch::UNUSED:
   case CudaArch::UNKNOWN:
 assert(false && "No GPU arch when compiling CUDA device code.");
 return "";

diff  --git a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
index d9ef6c2a1078..433256313c12 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -5034,6 +5034,7 @@ void CGOpenMPRuntimeGPU::processRequiresDirective(
   case CudaArch::GFX1012:
   case CudaArch::GFX1030:
   case CudaArch::GFX1031:
+  case CudaArch::UNUSED:
   case CudaArch::UNKNOWN:
 break;
   case CudaArch::LAST:
@@ -5095,6 +5096,7 @@ static std::pair 
getSMsBlocksPerSM(CodeGenModule ) {
   case CudaArch::GFX1012:
   case CudaArch::GFX1030:
   case CudaArch::GFX1031:
+  case CudaArch::UNUSED:
   case CudaArch::UNKNOWN:
 break;
   case CudaArch::LAST:

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 9cc4b8212981..96798b3d0adb 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2517,7 +2517,7 @@ class OffloadingActionBuilder final {
 
   // If we have a fat binary, add it to the list.
   if (CudaFatBinary) {
-AddTopLevel(CudaFatBinary, CudaArch::UNKNOWN);
+AddTopLevel(CudaFatBinary, CudaArch::UNUSED);
 CudaDeviceActions.clear();
 CudaFatBinary = nullptr;
 return;

diff  --git a/clang/test/Driver/hip-phases.hip 
b/clang/test/Driver/hip-phases.hip
index 7c2dc1384ccd..241448dfbd54 100644
--- a/clang/test/Driver/hip-phases.hip
+++ b/clang/test/Driver/hip-phases.hip
@@ -219,6 +219,12 @@
 // DBIN-DAG: [[P0:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T:hip]], 
(device-[[T]], [[ARCH:gfx803]])
 // DBIN-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, 
(device-[[T]], [[ARCH]])
 // DBIN-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-[[T]], 
[[ARCH]])
+// DBIN-DAG: [[P4:[0-9]+]]: assembler, {[[P3]]}, object, (device-[[T]], 
[[ARCH]])
+// DBIN-DAG: [[P5:[0-9]+]]: linker, {[[P4]]}, image, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P6:[0-9]+]]: offload, "device-[[T]] 
(amdgcn-amd-amdhsa:[[ARCH]])" {[[P5]]}, image
+// DBIN-DAG: [[P7:[0-9]+]]: linker, {[[P6]]}, hip-fatbin, (device-hip, )
+// DBIN-DAG: [[P8:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:)" 
{[[P7]]}, hip-fatbin
 // DBIN-NOT: host

[PATCH] D88524: [CUDA][HIP] Fix bound arch for offload action for fat binary

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rGcbd420c5ed85: [CUDA][HIP] Fix bound arch for offload action 
for fat binary (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D88524?vs=295572=295926#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88524/new/

https://reviews.llvm.org/D88524

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-phases.hip
  clang/test/Driver/hip-toolchain-device-only.hip

Index: clang/test/Driver/hip-toolchain-device-only.hip
===
--- /dev/null
+++ clang/test/Driver/hip-toolchain-device-only.hip
@@ -0,0 +1,29 @@
+// REQUIRES: clang-driver, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu \
+// RUN:   --offload-arch=gfx803 --offload-arch=gfx900 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib -c \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=CHECK,LINK %s
+
+// CHECK-NOT: error:
+
+// CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
+// CHECK-SAME: "-fcuda-is-device"
+// CHECK-SAME: "-target-cpu" "gfx803"
+// CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_803:".*o"]] "-x" "hip"
+
+// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK-SAME: "-o" "[[IMG_DEV_A_803:.*out]]" [[OBJ_DEV_A_803]]
+
+// CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
+// CHECK-SAME: "-emit-obj"
+// CHECK-SAME: "-fcuda-is-device"
+// CHECK-SAME: "-target-cpu" "gfx900"
+// CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_900:".*o"]] "-x" "hip"
+
+// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK-SAME: "-o" "[[IMG_DEV_A_900:.*out]]" [[OBJ_DEV_A_900]]
+
+// CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
+// CHECK-SAME: "-inputs={{.*}},[[IMG_DEV_A_803]],[[IMG_DEV_A_900]]" "-outputs=[[BUNDLE_A:.*hipfb]]"
Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -219,6 +219,12 @@
 // DBIN-DAG: [[P0:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T:hip]], (device-[[T]], [[ARCH:gfx803]])
 // DBIN-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, (device-[[T]], [[ARCH]])
 // DBIN-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P4:[0-9]+]]: assembler, {[[P3]]}, object, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P5:[0-9]+]]: linker, {[[P4]]}, image, (device-[[T]], [[ARCH]])
+// DBIN-DAG: [[P6:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:[[ARCH]])" {[[P5]]}, image
+// DBIN-DAG: [[P7:[0-9]+]]: linker, {[[P6]]}, hip-fatbin, (device-hip, )
+// DBIN-DAG: [[P8:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:)" {[[P7]]}, hip-fatbin
 // DBIN-NOT: host
 //
 // Test single gpu architecture up to the assemble phase in device-only
@@ -230,6 +236,8 @@
 // DASM-DAG: [[P0:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T:hip]], (device-[[T]], [[ARCH:gfx803]])
 // DASM-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, (device-[[T]], [[ARCH]])
 // DASM-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-[[T]], [[ARCH]])
+// DASM-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-[[T]], [[ARCH]])
+// DASM-DAG: [[P4:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:[[ARCH]])" {[[P3]]}, assembler
 // DASM-NOT: host
 
 //
@@ -242,9 +250,19 @@
 // DBIN2-DAG: [[P0:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T:hip]], (device-[[T]], [[ARCH:gfx803]])
 // DBIN2-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, (device-[[T]], [[ARCH]])
 // DBIN2-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-[[T]], [[ARCH]])
-// DBIN2-DAG: [[P6:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T]], (device-[[T]], [[ARCH2:gfx900]])
-// DBIN2-DAG: [[P7:[0-9]+]]: preprocessor, {[[P6]]}, [[T]]-cpp-output, (device-[[T]], [[ARCH2]])
-// DBIN2-DAG: [[P8:[0-9]+]]: compiler, {[[P7]]}, ir, (device-[[T]], [[ARCH2]])
+// DBIN2-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-[[T]], [[ARCH]])
+// DBIN2-DAG: [[P4:[0-9]+]]: assembler, {[[P3]]}, object, (device-[[T]], [[ARCH]])
+// DBIN2-DAG: [[P5:[0-9]+]]: linker, {[[P4]]}, image, (device-[[T]], [[ARCH]])
+// DBIN2-DAG: [[P6:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:[[ARCH]])" {[[P5]]}, image
+// DBIN2-DAG: [[P7:[0-9]+]]: input, "{{.*}}hip-phases.hip", [[T]], (device-[[T]], [[ARCH2:gfx900]])
+// DBIN2-DAG: [[P8:[0-9]+]]: preprocessor, {[[P7]]}, [[T]]-cpp-output, (device-[[T]], [[ARCH2]])
+// DBIN2-DAG: [[P9:[0-9]+]]: compiler, {[[P8]]}, 

[PATCH] D88278: [PowerPC] Add builtins for xvtdiv(dp|sp) and xvtsqrt(dp|sp).

[Qing Shan Zhang via Phabricator via cfe-commits]

steven.zhang accepted this revision.
steven.zhang added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88278/new/

https://reviews.llvm.org/D88278

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

[PATCH] D88446: docs: add documentation describing API Notes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.

Thanks, looks good to me.




Comment at: clang/docs/APINotes.rst:250-252
+  Note that the type is *not* parsed in the context where it will be used,
+  which means that macros are not available and nullability must be applied
+  explicitly (even in an ``NS_ASSUME_NONNULL_BEGIN`` section).

Please update this text similarly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

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

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd updated this revision to Diff 295924.
compnerd marked an inline comment as done.
compnerd added a comment.

Address feedback from @rsmith


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

Files:
  clang/docs/APINotes.rst
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
  clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes

Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
@@ -0,0 +1,15 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector: "privateTransform:input:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+Properties:
+  - Name: internalProperty
+Nullability: N
+Protocols:
+  - Name: InternalProtocol
+Availability: none
+AvailabilityMsg: "not for you"
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
@@ -0,0 +1,4 @@
+@interface A(ExplicitNullabilityProperties)
+@property (nonatomic, readwrite, retain, nonnull) A *explicitNonnullInstance;
+@property (nonatomic, readwrite, retain, nullable) A *explicitNullableInstance;
+@end
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
@@ -0,0 +1,60 @@
+#ifndef SOMEKIT_H
+#define SOMEKIT_H
+
+__attribute__((objc_root_class))
+@interface A
+-(A*)transform:(A*)input;
+-(A*)transform:(A*)input integer:(int)integer;
+
+@property (nonatomic, readonly, retain) A* someA;
+@property (nonatomic, retain) A* someOtherA;
+
+@property (nonatomic) int intValue;
+@end
+
+@interface B : A
+@end
+
+@interface C : A
+- (instancetype)init;
+- (instancetype)initWithA:(A*)a;
+@end
+
+@interface ProcessInfo : A
++(instancetype)processInfo;
+@end
+
+@interface A(NonNullProperties)
+@property (nonatomic, readwrite, retain) A *nonnullAInstance;
+@property (class, nonatomic, readwrite, retain) A *nonnullAInstance;
+
+@property (nonatomic, readwrite, retain) A *nonnullAClass;
+@property (class, nonatomic, readwrite, retain) A *nonnullAClass;
+
+@property (nonatomic, readwrite, retain) A *nonnullABoth;
+@property (class, nonatomic, readwrite, retain) A *nonnullABoth;
+@end
+
+#import 
+
+extern int *global_int_ptr;
+
+int *global_int_fun(int *ptr, int *ptr2);
+
+#define SOMEKIT_DOUBLE double
+
+__attribute__((objc_root_class))
+@interface OverriddenTypes
+-(int *)methodToMangle:(int *)ptr1 second:(int *)ptr2;
+@property int *intPropertyToMangle;
+@end
+
+@interface A(ImplicitGetterSetters)
+@property (nonatomic, readonly, retain) A *implicitGetOnlyInstance;
+@property (class, nonatomic, readonly, retain) A *implicitGetOnlyClass;
+
+@property (nonatomic, readwrite, retain) A *implicitGetSetInstance;
+@property (class, nonatomic, readwrite, retain) A *implicitGetSetClass;
+@end
+
+#endif
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
@@ -0,0 +1,98 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector:"transform:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "anything but this"
+  - Selector: "transform:integer:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+  - Selector: "implicitGetOnlyInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetOnlyClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "setImplicitGetSetInstance:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "setter gone"
+  - 

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd marked 2 inline comments as done.
compnerd added inline comments.



Comment at: clang/docs/APINotes.rst:233-235
+  Note that the type is *not* parsed in the context where it will be used,
+  which means that macros are not available and nullability must be applied
+  explicitly (even in an ``NS_ASSUME_NONNULL_BEGIN`` section).

rsmith wrote:
> compnerd wrote:
> > rsmith wrote:
> > > So what context is it parsed in? Below you have an `NSArray *` example; 
> > > how do we do the lookup for `NSArray`?
> > A separate buffer is constructed where the annotations are processed.  
> > During semantic analysis, the requested APINotes are processed and the 
> > attributes specified are applied to the declaration.
> I've not been able to work out what the rule is, based on this documentation. 
> The name `NSArray` isn't predeclared, so how is it found? How can a user 
> ensure their types are visible to this parsing process? Are these things 
> parsed as if they appear at the global scope in a translation unit in which 
> the corresponding framework has been imported? (And if so, why wouldn't 
> macros be available there too?) Whatever the rule is, I'd like to see it 
> documented.
Discussed offline, this has been updated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

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

[PATCH] D88518: Recognize setjmp and friends as builtins even if jmp_buf is not declared yet.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D88518#2308085 , @mstorsjo wrote:

> This broke use of setjmp for mingw on x86_64.

Thanks, should be fixed in rG8fb2a235b0f22dedba72b8b559ba33171a8dcd09 
. Now that 
we properly recognize `_setjmp` even if it has a weird signature, the 
MSVC-specific check for exactly one argument was breaking the MinGW case. I've 
removed that check and instead we only apply the custom MSVC-specific codegen 
rule if the declaration happens to be of the right form (but we apply the 
`returns_twice` attribute regardless).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88518/new/

https://reviews.llvm.org/D88518

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

[clang] 8fb2a23 - Don't reject calls to MinGW's unusual _setjmp declaration.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-10-02T15:12:15-07:00
New Revision: 8fb2a235b0f22dedba72b8b559ba33171a8dcd09

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

LOG: Don't reject calls to MinGW's unusual _setjmp declaration.

We now recognize this function as a builtin despite it having an
unexpected number of parameters; make sure we don't enforce that it has
only 1 argument for its 2 parameters.

Added: 


Modified: 
clang/include/clang/Basic/Builtins.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/builtin-setjmp.c

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index d001b0bea9e6..b2876ed6cbed 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -1028,6 +1028,7 @@ LIBBUILTIN(pthread_create, "",  "fC<2,3>", "pthread.h", 
ALL_GNU_LANGUAGES)
 
 // POSIX setjmp.h
 
+// FIXME: MinGW _setjmp has an additional void* parameter.
 LIBBUILTIN(_setjmp, "iJ", "fjT",   "setjmp.h", ALL_LANGUAGES)
 LIBBUILTIN(__sigsetjmp, "iSJi",   "fjT",   "setjmp.h", ALL_LANGUAGES)
 LIBBUILTIN(sigsetjmp, "iSJi", "fjT",   "setjmp.h", ALL_LANGUAGES)

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index bb1c1d1aef33..e5f6ee138a21 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3764,11 +3764,13 @@ RValue CodeGenFunction::EmitBuiltinExpr(const 
GlobalDecl GD, unsigned BuiltinID,
   case Builtin::BI_abnormal_termination:
 return RValue::get(EmitSEHAbnormalTermination());
   case Builtin::BI_setjmpex:
-if (getTarget().getTriple().isOSMSVCRT())
+if (getTarget().getTriple().isOSMSVCRT() && E->getNumArgs() == 1 &&
+E->getArg(0)->getType()->isPointerType())
   return EmitMSVCRTSetJmp(*this, MSVCSetJmpKind::_setjmpex, E);
 break;
   case Builtin::BI_setjmp:
-if (getTarget().getTriple().isOSMSVCRT()) {
+if (getTarget().getTriple().isOSMSVCRT() && E->getNumArgs() == 1 &&
+E->getArg(0)->getType()->isPointerType()) {
   if (getTarget().getTriple().getArch() == llvm::Triple::x86)
 return EmitMSVCRTSetJmp(*this, MSVCSetJmpKind::_setjmp3, E);
   else if (getTarget().getTriple().getArch() == llvm::Triple::aarch64)

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index eeb322262400..951772a08d18 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -1570,11 +1570,6 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
 if (SemaBuiltinSetjmp(TheCall))
   return ExprError();
 break;
-  case Builtin::BI_setjmp:
-  case Builtin::BI_setjmpex:
-if (checkArgCount(*this, TheCall, 1))
-  return true;
-break;
   case Builtin::BI__builtin_classify_type:
 if (checkArgCount(*this, TheCall, 1)) return true;
 TheCall->setType(Context.IntTy);

diff  --git a/clang/test/Sema/builtin-setjmp.c 
b/clang/test/Sema/builtin-setjmp.c
index 6a114fad05d9..604d534eb504 100644
--- a/clang/test/Sema/builtin-setjmp.c
+++ b/clang/test/Sema/builtin-setjmp.c
@@ -1,34 +1,47 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-DNO_JMP_BUF %s -ast-dump | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-DWRONG_JMP_BUF %s -ast-dump | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-DRIGHT_JMP_BUF %s -ast-dump | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-DONLY_JMP_BUF %s -ast-dump | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-DNO_SETJMP %s -ast-dump 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=c,expected -DNO_JMP_BUF %s -ast-dump | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=c,expected -DWRONG_JMP_BUF %s -ast-dump | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=c,expected -DRIGHT_JMP_BUF %s -ast-dump | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=c,expected -DONLY_JMP_BUF %s -ast-dump | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=c,expected -DNO_SETJMP %s -ast-dump 2>&1 | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only 
-verify=cxx,expected -x c++ -DNO_JMP_BUF %s -ast-dump | FileCheck %s 
--check-prefixes=CHECK1,CHECK2
+// RUN: %clang_cc1 -triple 

[clang] dc6a0b0 - [HIP] Align device binary

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T18:10:44-04:00
New Revision: dc6a0b0ec7e3d72a4cc849af4e4aa6c6a29a53d2

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

LOG: [HIP] Align device binary

To facilitate faster loading of device binaries and share them among processes,
HIP runtime favors their alignment being 4096 bytes. HIP runtime can load
unaligned device binaries, however, aligning them at 4096 bytes results in
faster loading and less shared memory usage.

This patch adds an option -bundle-align to clang-offload-bundler which allows
bundles to be aligned at specified alignment. By default it is 1, which is NFC
compared to existing format.

This patch then aligns embedded fat binary and device binary inside fat binary
at 4096 bytes.

It has been verified this change does not cause significant overall file size 
increase
for typical HIP applications (less than 1%).

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

Added: 


Modified: 
clang/lib/CodeGen/CGCUDANV.cpp
clang/lib/Driver/ToolChains/HIP.cpp
clang/test/CodeGenCUDA/device-stub.cu
clang/test/Driver/clang-offload-bundler.c
clang/test/Driver/hip-toolchain-no-rdc.hip
clang/test/Driver/hip-toolchain-rdc.hip
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCUDANV.cpp b/clang/lib/CodeGen/CGCUDANV.cpp
index baf2c79cc2b6..b0b76ffbebde 100644
--- a/clang/lib/CodeGen/CGCUDANV.cpp
+++ b/clang/lib/CodeGen/CGCUDANV.cpp
@@ -597,8 +597,10 @@ llvm::Function *CGNVCUDARuntime::makeModuleCtorFunction() {
 if (CudaGpuBinary) {
   // If fatbin is available from early finalization, create a string
   // literal containing the fat binary loaded from the given file.
-  FatBinStr = makeConstantString(std::string(CudaGpuBinary->getBuffer()),
- "", FatbinConstantName, 8);
+  const unsigned HIPCodeObjectAlign = 4096;
+  FatBinStr =
+  makeConstantString(std::string(CudaGpuBinary->getBuffer()), "",
+ FatbinConstantName, HIPCodeObjectAlign);
 } else {
   // If fatbin is not available, create an external symbol
   // __hip_fatbin in section .hip_fatbin. The external symbol is supposed

diff  --git a/clang/lib/Driver/ToolChains/HIP.cpp 
b/clang/lib/Driver/ToolChains/HIP.cpp
index 78f53204bd8c..25b3ab88bc02 100644
--- a/clang/lib/Driver/ToolChains/HIP.cpp
+++ b/clang/lib/Driver/ToolChains/HIP.cpp
@@ -16,6 +16,7 @@
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
+#include "llvm/Support/Alignment.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/TargetParser.h"
@@ -33,6 +34,7 @@ using namespace llvm::opt;
 #endif
 
 namespace {
+const unsigned HIPCodeObjectAlign = 4096;
 
 static void addBCLib(const Driver , const ArgList ,
  ArgStringList , ArgStringList LibraryPaths,
@@ -108,6 +110,8 @@ void AMDGCN::constructHIPFatbinCommand(Compilation , 
const JobAction ,
   // for 
diff erent GPU archs.
   ArgStringList BundlerArgs;
   BundlerArgs.push_back(Args.MakeArgString("-type=o"));
+  BundlerArgs.push_back(
+  Args.MakeArgString("-bundle-align=" + Twine(HIPCodeObjectAlign)));
 
   // ToDo: Remove the dummy host binary entry which is required by
   // clang-offload-bundler.
@@ -175,7 +179,8 @@ void 
AMDGCN::Linker::constructGenerateObjFileFromHIPFatBinary(
   ObjStream << "  .section .hip_fatbin,\"aMS\",@progbits,1\n";
   ObjStream << "  .data\n";
   ObjStream << "  .globl __hip_fatbin\n";
-  ObjStream << "  .p2align 3\n";
+  ObjStream << "  .p2align " << llvm::Log2(llvm::Align(HIPCodeObjectAlign))
+<< "\n";
   ObjStream << "__hip_fatbin:\n";
   ObjStream << "  .incbin \"" << BundleFile << "\"\n";
   ObjStream.flush();

diff  --git a/clang/test/CodeGenCUDA/device-stub.cu 
b/clang/test/CodeGenCUDA/device-stub.cu
index 0f4a5644fd48..ca21116fc989 100644
--- a/clang/test/CodeGenCUDA/device-stub.cu
+++ b/clang/test/CodeGenCUDA/device-stub.cu
@@ -115,7 +115,7 @@ void use_pointers() {
 // ALL: @4 = private unnamed_addr constant [21 x i8] c"ext_constant_var_def\00"
 // * constant unnamed string with GPU binary
 // CUDA: @[[FATBIN:.*]] = private constant{{.*GPU binary would be here.*}}\00",
-// HIPEF: @[[FATBIN:.*]] = private constant{{.*GPU binary would be 
here.*}}\00",
+// HIPEF: @[[FATBIN:.*]] = private constant{{.*GPU binary would be 
here.*}}\00",{{.*}}align 4096
 // HIPNEF: @[[FATBIN:__hip_fatbin]] = external constant i8, section 
".hip_fatbin"
 // CUDANORDC-SAME: section ".nv_fatbin", align 8
 // CUDARDC-SAME: section "__nv_relfatbin", align 8

diff  --git a/clang/test/Driver/clang-offload-bundler.c 

[PATCH] D88734: [HIP] Align device binary

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rGdc6a0b0ec7e3: [HIP] Align device binary (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88734/new/

https://reviews.llvm.org/D88734

Files:
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/CodeGenCUDA/device-stub.cu
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-rdc.hip
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -94,6 +94,11 @@
  "instead of actually executing them - for testing purposes.\n"),
 cl::init(false), cl::cat(ClangOffloadBundlerCategory));
 
+static cl::opt
+BundleAlignment("bundle-align",
+cl::desc("Alignment of bundle for binary files"),
+cl::init(1), cl::cat(ClangOffloadBundlerCategory));
+
 /// Magic string that marks the existence of offloading data.
 #define OFFLOAD_BUNDLER_MAGIC_STR "__CLANG_OFFLOAD_BUNDLE__"
 
@@ -223,6 +228,9 @@
   StringMap::iterator CurBundleInfo;
   StringMap::iterator NextBundleInfo;
 
+  /// Current bundle target to be written.
+  std::string CurWriteBundleTarget;
+
 public:
   BinaryFileHandler() : FileHandler() {}
 
@@ -337,10 +345,12 @@
 unsigned Idx = 0;
 for (auto  : TargetNames) {
   MemoryBuffer  = *Inputs[Idx++];
+  HeaderSize = alignTo(HeaderSize, BundleAlignment);
   // Bundle offset.
   Write8byteIntegerToBuffer(OS, HeaderSize);
   // Size of the bundle (adds to the next bundle's offset)
   Write8byteIntegerToBuffer(OS, MB.getBufferSize());
+  BundlesInfo[T] = BundleInfo(MB.getBufferSize(), HeaderSize);
   HeaderSize += MB.getBufferSize();
   // Size of the triple
   Write8byteIntegerToBuffer(OS, T.size());
@@ -351,6 +361,7 @@
   }
 
   Error WriteBundleStart(raw_fd_ostream , StringRef TargetTriple) final {
+CurWriteBundleTarget = TargetTriple.str();
 return Error::success();
   }
 
@@ -359,6 +370,8 @@
   }
 
   Error WriteBundle(raw_fd_ostream , MemoryBuffer ) final {
+auto BI = BundlesInfo[CurWriteBundleTarget];
+OS.seek(BI.Offset);
 OS.write(Input.getBufferStart(), Input.getBufferSize());
 return Error::success();
   }
Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -8,10 +8,14 @@
 // RUN:   --hip-device-lib-path=%S/Inputs/hip_multiple_inputs/lib1 \
 // RUN:   --hip-device-lib-path=%S/Inputs/hip_multiple_inputs/lib2 \
 // RUN:   -fuse-ld=lld -fgpu-rdc -nogpuinc \
+// RUN:   -fhip-dump-offload-linker-script \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s
 
+// check code object alignment in dumped llvm-mc input
+// CHECK: .p2align 12
+
 // emit objects for host side path
 // CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-aux-triple" "amdgcn-amd-amdhsa"
@@ -87,6 +91,7 @@
 
 // combine images generated into hip fat binary object
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-bundle-align=4096"
 // CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
 // CHECK-SAME: "-inputs={{.*}},[[IMG_DEV1]],[[IMG_DEV2]]" "-outputs=[[BUNDLE:.*hipfb]]"
 
Index: clang/test/Driver/hip-toolchain-no-rdc.hip
===
--- clang/test/Driver/hip-toolchain-no-rdc.hip
+++ clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -81,6 +81,7 @@
 //
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-bundle-align=4096"
 // CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
 // CHECK-SAME: "-inputs={{.*}},[[IMG_DEV_A_803]],[[IMG_DEV_A_900]]" "-outputs=[[BUNDLE_A:.*hipfb]]"
 
@@ -143,6 +144,7 @@
 //
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-bundle-align=4096"
 // CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
 // CHECK-SAME: "-inputs={{.*}},[[IMG_DEV_B_803]],[[IMG_DEV_B_900]]" "-outputs=[[BUNDLE_A:.*hipfb]]"
 
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -278,6 +278,16 @@
 // RUN: diff %t.empty %t.res.tgt1
 // RUN: diff %t.empty %t.res.tgt2
 
+//
+// 

[clang] 14f6bfc - [clang] Implement objc_non_runtime_protocol to remove protocol metadata

[Nathan Lanza via cfe-commits]

Author: Nathan Lanza
Date: 2020-10-02T17:35:50-04:00
New Revision: 14f6bfcb52e77867a6a84fcfd9e21bb5f1f5795c

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

LOG: [clang] Implement objc_non_runtime_protocol to remove protocol metadata

Summary:
Motivated by the new objc_direct attribute, this change adds a new
attribute that remotes metadata from Protocols that the programmer knows
isn't going to be used at runtime. We simply have the frontend skip
generating any protocol metadata entries (e.g. OBJC_CLASS_NAME,
_OBJC_$_PROTOCOL_INSTANCE_METHDOS, _OBJC_PROTOCOL, etc) for a protocol
marked with `__attribute__((objc_non_runtime_protocol))`.

There are a few APIs used to retrieve a protocol at runtime.
`@protocol(SomeProtocol)` will now error out of the requested protocol
is marked with attribute. `objc_getProtocol` will return `NULL` which
is consistent with the behavior of a non-existing protocol.

Subscribers: cfe-commits

Tags: #clang

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

Added: 
clang/test/CodeGenObjC/non-runtime-protocol.m

Modified: 
clang/include/clang/AST/DeclObjC.h
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/AST/DeclObjC.cpp
clang/lib/CodeGen/CGObjC.cpp
clang/lib/CodeGen/CGObjCGNU.cpp
clang/lib/CodeGen/CGObjCMac.cpp
clang/lib/CodeGen/CGObjCRuntime.h
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaExprObjC.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 




diff  --git a/clang/include/clang/AST/DeclObjC.h 
b/clang/include/clang/AST/DeclObjC.h
index 32e69d7fe1ed..f2c25bceed18 100644
--- a/clang/include/clang/AST/DeclObjC.h
+++ b/clang/include/clang/AST/DeclObjC.h
@@ -2178,6 +2178,14 @@ class ObjCProtocolDecl : public ObjCContainerDecl,
 data().ReferencedProtocols.set(List, Num, Locs, C);
   }
 
+  /// This is true iff the protocol is tagged with the `objc_static_protocol`
+  /// attribute.
+  bool isNonRuntimeProtocol() const;
+
+  /// Get the set of all protocols implied by this protocols inheritance
+  /// hierarchy.
+  void getImpliedProtocols(llvm::DenseSet ) 
const;
+
   ObjCProtocolDecl *lookupProtocolNamed(IdentifierInfo *PName);
 
   // Lookup a method. First, we search locally. If a method isn't

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 4d7a65964887..60e7a9d4303b 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2024,6 +2024,13 @@ def ObjCDirectMembers : Attr {
   let Documentation = [ObjCDirectMembersDocs];
 }
 
+def ObjCNonRuntimeProtocol : Attr {
+  let Spellings = [Clang<"objc_non_runtime_protocol">];
+  let Subjects = SubjectList<[ObjCProtocol], ErrorDiag>;
+  let LangOpts = [ObjC];
+  let Documentation = [ObjCNonRuntimeProtocolDocs];
+}
+
 def ObjCRuntimeName : Attr {
   let Spellings = [Clang<"objc_runtime_name">];
   let Subjects = SubjectList<[ObjCInterface, ObjCProtocol], ErrorDiag>;

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 8c236796546c..bf190829381c 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -4620,6 +4620,22 @@ properties, including auto-synthesized properties.
   }];
 }
 
+def ObjCNonRuntimeProtocolDocs : Documentation {
+  let Category = DocCatDecl;
+  let Content = [{
+The ``objc_non_runtime_protocol`` attribute can be used to mark that an
+Objective-C protocol is only used during static type-checking and doesn't need
+to be represented dynamically. This avoids several small code-size and run-time
+overheads associated with handling the protocol's metadata. A non-runtime
+protocol cannot be used as the operand of a ``@protocol`` expression, and
+dynamic attempts to find it with ``objc_getProtocol`` will fail.
+
+If a non-runtime protocol inherits from any ordinary protocols, classes and
+derived protocols that declare conformance to the non-runtime protocol will
+dynamically list their conformance to those bare protocols.
+  }];
+}
+
 def SelectAnyDocs : Documentation {
   let Category = DocCatDecl;
   let Content = [{

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f29eec316971..b3b3bc723863 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1034,6 +1034,8 @@ def warn_objc_boxing_invalid_utf8_string : Warning<
   "string is ill-formed as UTF-8 and will become a null %0 when boxed">,
   InGroup;
 
+def err_objc_non_runtime_protocol_in_protocol_expr : Error<
+  "cannot use a protocol declared 'objc_non_runtime_protocol' in a 

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG14f6bfcb52e7: [clang] Implement objc_non_runtime_protocol to 
remove protocol metadata (authored by lanza).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75574/new/

https://reviews.llvm.org/D75574

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/DeclObjC.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGObjCGNU.cpp
  clang/lib/CodeGen/CGObjCMac.cpp
  clang/lib/CodeGen/CGObjCRuntime.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/CodeGenObjC/non-runtime-protocol.m
  clang/test/Misc/pragma-attribute-supported-attributes-list.test

Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -118,6 +118,7 @@
 // CHECK-NEXT: ObjCExternallyRetained (SubjectMatchRule_variable_not_is_parameter, SubjectMatchRule_function, SubjectMatchRule_block, SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCMethodFamily (SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCNonLazyClass (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_implementation)
+// CHECK-NEXT: ObjCNonRuntimeProtocol (SubjectMatchRule_objc_protocol)
 // CHECK-NEXT: ObjCPreciseLifetime (SubjectMatchRule_variable)
 // CHECK-NEXT: ObjCRequiresPropertyDefs (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: ObjCRequiresSuper (SubjectMatchRule_objc_method)
Index: clang/test/CodeGenObjC/non-runtime-protocol.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/non-runtime-protocol.m
@@ -0,0 +1,142 @@
+// RUN: not %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DPROTOEXPR -o - 2>&1 \
+// RUN: | FileCheck -check-prefix=PROTOEXPR %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY1 %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY2 %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=NONFRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=INHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILEINHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNUINHERITANCE %s
+//
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU2 %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNU2INHERITANCE %s
+
+__attribute__((objc_root_class))
+@interface Root
+@end
+@implementation Root
+@end
+
+#ifdef REDUNDANCY
+// REDUNDANCY1-NOT: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_B
+// REDUNDANCY2: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_C{{.*}}_OBJC_PROTOCOL_$_A
+@protocol C
+@end
+@protocol B 
+@end
+@protocol A 
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Alpha
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Beta
+@end
+@interface Implementer : Root 
+@end
+@implementation Implementer
+@end
+#endif
+
+#ifdef BASE
+// Confirm that we're not emitting protocol information for the
+// NONFRAGILE-NOT: OBJC_CLASS_NAME{{.*}}NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_INSTANCE_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_CLASS_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_LABEL_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_CLASS_PROTOCOLS_$_NonRuntimeImplementer
+// FRAGILE-NOT: OBJC_CLASS_NAME_.{{.*}}"Runtime\00"
+// FRAGILE-NOT: OBJC_PROTOCOL_NonRuntime
+// FRAGILE_NOT: OBJC_PROTOCOLS_NonRuntimeImplementer
+// 

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

lanza updated this revision to Diff 295911.
lanza added a comment.

Clean clang-tidy warnings before landing


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75574/new/

https://reviews.llvm.org/D75574

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/DeclObjC.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGObjCGNU.cpp
  clang/lib/CodeGen/CGObjCMac.cpp
  clang/lib/CodeGen/CGObjCRuntime.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/CodeGenObjC/non-runtime-protocol.m
  clang/test/Misc/pragma-attribute-supported-attributes-list.test

Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -118,6 +118,7 @@
 // CHECK-NEXT: ObjCExternallyRetained (SubjectMatchRule_variable_not_is_parameter, SubjectMatchRule_function, SubjectMatchRule_block, SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCMethodFamily (SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCNonLazyClass (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_implementation)
+// CHECK-NEXT: ObjCNonRuntimeProtocol (SubjectMatchRule_objc_protocol)
 // CHECK-NEXT: ObjCPreciseLifetime (SubjectMatchRule_variable)
 // CHECK-NEXT: ObjCRequiresPropertyDefs (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: ObjCRequiresSuper (SubjectMatchRule_objc_method)
Index: clang/test/CodeGenObjC/non-runtime-protocol.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/non-runtime-protocol.m
@@ -0,0 +1,142 @@
+// RUN: not %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DPROTOEXPR -o - 2>&1 \
+// RUN: | FileCheck -check-prefix=PROTOEXPR %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY1 %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY2 %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=NONFRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=INHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILEINHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNUINHERITANCE %s
+//
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU2 %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNU2INHERITANCE %s
+
+__attribute__((objc_root_class))
+@interface Root
+@end
+@implementation Root
+@end
+
+#ifdef REDUNDANCY
+// REDUNDANCY1-NOT: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_B
+// REDUNDANCY2: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_C{{.*}}_OBJC_PROTOCOL_$_A
+@protocol C
+@end
+@protocol B 
+@end
+@protocol A 
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Alpha
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Beta
+@end
+@interface Implementer : Root 
+@end
+@implementation Implementer
+@end
+#endif
+
+#ifdef BASE
+// Confirm that we're not emitting protocol information for the
+// NONFRAGILE-NOT: OBJC_CLASS_NAME{{.*}}NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_INSTANCE_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_CLASS_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_LABEL_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_CLASS_PROTOCOLS_$_NonRuntimeImplementer
+// FRAGILE-NOT: OBJC_CLASS_NAME_.{{.*}}"Runtime\00"
+// FRAGILE-NOT: OBJC_PROTOCOL_NonRuntime
+// FRAGILE_NOT: OBJC_PROTOCOLS_NonRuntimeImplementer
+// GNU-NOT: private unnamed_addr constant {{.*}} c"NonRuntimeProtocol\00"
+// GNU-NOT: @.objc_protocol {{.*}}
+// GNU2-NOT: private unnamed_addr constant {{.*}} c"NonRuntimeProtocol\00"
+// GNU2-NOT: @.objc_protocol {{.*}}

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGace644030e67: [clang-tidy] Implement 
readability-function-cognitive-complexity check (authored by lebedev.ri).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
@@ -0,0 +1,1015 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- -config='{CheckOptions: [{key: readability-function-cognitive-complexity.Threshold, value: 0}]}' -- -std=c++11 -fblocks -w
+
+// any function should be checked.
+
+extern int ext_func(int x = 0);
+
+int some_func(int x = 0);
+
+static int some_other_func(int x = 0) {}
+
+template void some_templ_func(T x = 0) {}
+
+class SomeClass {
+public:
+  int *begin(int x = 0);
+  int *end(int x = 0);
+  static int func(int x = 0);
+  template void some_templ_func(T x = 0) {}
+  SomeClass() = default;
+  SomeClass(SomeClass&) = delete;
+};
+
+// nothing ever decreases cognitive complexity, so we can check all the things
+// in one go. none of the following should increase cognitive complexity:
+void unittest_false() {
+  {};
+  ext_func();
+  some_func();
+  some_other_func();
+  some_templ_func();
+  some_templ_func();
+  SomeClass::func();
+  SomeClass C;
+  C.some_templ_func();
+  C.some_templ_func();
+  C.func();
+  C.end();
+  int i = some_func();
+  i = i;
+  i++;
+  --i;
+  i < 0;
+  int j = 0 ?: 1;
+  auto k = new int;
+  delete k;
+  throw i;
+  {
+throw i;
+  }
+end:
+  return;
+}
+
+#if 1
+#define CC100
+#else
+// this macro has cognitive complexity of 100.
+// it is needed to be able to compare the testcases with the
+// reference Sonar implementation. please place it right after the first
+// CHECK-NOTES in each function
+#define CC100 if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){}if(1){}
+#endif
+
+////
+//-- B1. Increments --//
+////
+// Check that every thing listed in B1 of the specification does indeed   //
+// recieve the base increment, and that not-body does not increase nesting//
+////
+
+// break does not increase cognitive complexity.
+// only  break LABEL  does, but it is unavaliable in C or C++
+
+// continue does not increase cognitive complexity.
+// only  continue LABEL  does, but it is unavaliable in C or C++
+
+void unittest_b1_00() {
+// CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'unittest_b1_00' has cognitive complexity of 33 (threshold 0) [readability-function-cognitive-complexity]
+  CC100;
+
+  if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:3: note: +1, including nesting penalty of 0, nesting level increased to 1{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:9: note: +1, including nesting penalty of 0, nesting level increased to 1{{$}}
+
+if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:5: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:11: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+} else if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:12: note: +1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:18: note: +3, including nesting penalty of 2, nesting level increased to 3{{$}}
+} else {
+// CHECK-NOTES: :[[@LINE-1]]:7: note: +1, nesting level increased to 2{{$}}
+}
+  } else if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:10: note: +1, nesting level increased to 1{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:16: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+
+if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:5: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:11: 

[PATCH] D88446: docs: add documentation describing API Notes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/docs/APINotes.rst:233-235
+  Note that the type is *not* parsed in the context where it will be used,
+  which means that macros are not available and nullability must be applied
+  explicitly (even in an ``NS_ASSUME_NONNULL_BEGIN`` section).

compnerd wrote:
> rsmith wrote:
> > So what context is it parsed in? Below you have an `NSArray *` example; how 
> > do we do the lookup for `NSArray`?
> A separate buffer is constructed where the annotations are processed.  During 
> semantic analysis, the requested APINotes are processed and the attributes 
> specified are applied to the declaration.
I've not been able to work out what the rule is, based on this documentation. 
The name `NSArray` isn't predeclared, so how is it found? How can a user ensure 
their types are visible to this parsing process? Are these things parsed as if 
they appear at the global scope in a translation unit in which the 
corresponding framework has been imported? (And if so, why wouldn't macros be 
available there too?) Whatever the rule is, I'd like to see it documented.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

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

[clang-tools-extra] ace6440 - [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via cfe-commits]

Author: Roman Lebedev
Date: 2020-10-03T00:27:13+03:00
New Revision: ace644030e67506114d3ac9a221cf8eb5d10159c

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

LOG: [clang-tidy] Implement readability-function-cognitive-complexity check

Currently, there is basically just one clang-tidy check to impose
some sanity limits on functions - `clang-tidy-readability-function-size`.
It is nice, allows to limit line count, total number of statements,
number of branches, number of function parameters (not counting
implicit `this`), nesting level.

However, those are simple generic metrics. It is still trivially possible
to write a function, which does not violate any of these metrics,
yet is still rather unreadable.

Thus, some additional, slightly more complicated metric is needed.
There is a well-known [[ https://en.wikipedia.org/wiki/Cyclomatic_complexity | 
Cyclomatic complexity]], but certainly has its downsides.
And there is a [[ https://www.sonarsource.com/docs/CognitiveComplexity.pdf | 
COGNITIVE COMPLEXITY by SonarSource ]], which is available for opensource on 
https://sonarcloud.io/.

This check checks function Cognitive Complexity metric, and flags
the functions with Cognitive Complexity exceeding the configured limit.
The default limit is `25`, same as in 'upstream'.

The metric is implemented as per [[ 
https://www.sonarsource.com/docs/CognitiveComplexity.pdf | COGNITIVE COMPLEXITY 
by SonarSource ]] specification version 1.2 (19 April 2017), with two notable 
exceptions:
   * `preprocessor conditionals` (`#ifdef`, `#if`, `#elif`, `#else`,
 `#endif`) are not accounted for.
  Could be done. Currently, upstream does not account for them either.
   * `each method in a recursion cycle` is not accounted for.
  It can't be fully implemented, because cross-translational-unit
  analysis would be needed, which is not possible in clang-tidy.
  Thus, at least right now, i completely avoided implementing it.

There are some further possible improvements:
* Are GNU statement expressions (`BinaryConditionalOperator`) really free?
  They should probably cause nesting level increase,
  and complexity level increase when they are nested within eachother.
* Microsoft SEH support
* ???

Reviewed By: aaron.ballman, JonasToth, lattner

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

Added: 

clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h

clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst

clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp

Modified: 
clang-tools-extra/clang-tidy/readability/CMakeLists.txt
clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/readability/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/readability/CMakeLists.txt
index 4539ab177ced..ecf37b5b9157 100644
--- a/clang-tools-extra/clang-tidy/readability/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/readability/CMakeLists.txt
@@ -12,6 +12,7 @@ add_clang_library(clangTidyReadabilityModule
   DeleteNullPointerCheck.cpp
   DeletedDefaultCheck.cpp
   ElseAfterReturnCheck.cpp
+  FunctionCognitiveComplexityCheck.cpp
   FunctionSizeCheck.cpp
   IdentifierNamingCheck.cpp
   ImplicitBoolConversionCheck.cpp

diff  --git 
a/clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp 
b/clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
new file mode 100644
index ..548aec7543ac
--- /dev/null
+++ 
b/clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
@@ -0,0 +1,542 @@
+//===--- FunctionCognitiveComplexityCheck.cpp - clang-tidy --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "FunctionCognitiveComplexityCheck.h"
+#include "../ClangTidyDiagnosticConsumer.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclBase.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Stmt.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersInternal.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticIDs.h"
+#include "clang/Basic/LLVM.h"
+#include 

[PATCH] D88452: [Driver] Move detectLibcxxIncludePath to ToolChain

[Petr Hosek via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa594fd28e373: [Driver] Move detectLibcxxIncludePath to 
ToolChain (authored by phosek).

Changed prior to commit:
  https://reviews.llvm.org/D88452?vs=294815=295909#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88452/new/

https://reviews.llvm.org/D88452

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2877,31 +2877,11 @@
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
-}
-
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
+std::string IncludePath = detectLibcxxIncludePath(Path);
 if (IncludePath.empty() || !getVFS().exists(IncludePath))
   return false;
 addSystemInclude(DriverArgs, CC1Args, IncludePath);
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -319,8 +319,8 @@
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++", "v1");
-addSystemInclude(DriverArgs, CC1Args, P.str());
+llvm::sys::path::append(P, "..", "include", "c++");
+addSystemInclude(DriverArgs, CC1Args, detectLibcxxIncludePath(P.str()));
 break;
   }
 
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -924,6 +924,29 @@
   }
 }
 
+std::string ToolChain::detectLibcxxIncludePath(StringRef Base) const {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Base, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  if (!MaxVersion)
+return "";
+  SmallString<128> P(Base);
+  llvm::sys::path::append(P, MaxVersionString);
+  return std::string(P.str());
+}
+
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.
Index: clang/include/clang/Driver/ToolChain.h
===
--- clang/include/clang/Driver/ToolChain.h
+++ clang/include/clang/Driver/ToolChain.h
@@ -575,6 +575,9 @@
   // given compilation arguments.
   virtual UnwindLibType GetUnwindLibType(const llvm::opt::ArgList ) const;
 
+  // Detect the highest available version of libc++ in base path.
+  virtual std::string detectLibcxxIncludePath(StringRef Base) const;
+
   /// AddClangCXXStdlibIncludeArgs - Add the clang -cc1 level arguments to set
   /// the include paths to use for the given C++ standard library type.
   virtual void


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2877,31 +2877,11 @@
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC 

[clang] a594fd2 - [Driver] Move detectLibcxxIncludePath to ToolChain

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2020-10-02T14:23:48-07:00
New Revision: a594fd28e373cb7cd348cf01f6a90e055bf6cf6d

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

LOG: [Driver] Move detectLibcxxIncludePath to ToolChain

This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.

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

Added: 


Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index 7495e08fe6e6..db4c4a730232 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -575,6 +575,9 @@ class ToolChain {
   // given compilation arguments.
   virtual UnwindLibType GetUnwindLibType(const llvm::opt::ArgList ) const;
 
+  // Detect the highest available version of libc++ in base path.
+  virtual std::string detectLibcxxIncludePath(StringRef Base) const;
+
   /// AddClangCXXStdlibIncludeArgs - Add the clang -cc1 level arguments to set
   /// the include paths to use for the given C++ standard library type.
   virtual void

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 8991216da676..8e98e3206880 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -924,6 +924,29 @@ void ToolChain::addExternCSystemIncludeIfExists(const 
ArgList ,
   }
 }
 
+std::string ToolChain::detectLibcxxIncludePath(StringRef Base) const {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Base, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  if (!MaxVersion)
+return "";
+  SmallString<128> P(Base);
+  llvm::sys::path::append(P, MaxVersionString);
+  return std::string(P.str());
+}
+
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.

diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 781179be39a3..e5f23ee38555 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -319,8 +319,8 @@ void Fuchsia::AddClangCXXStdlibIncludeArgs(const ArgList 
,
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++", "v1");
-addSystemInclude(DriverArgs, CC1Args, P.str());
+llvm::sys::path::append(P, "..", "include", "c++");
+addSystemInclude(DriverArgs, CC1Args, detectLibcxxIncludePath(P.str()));
 break;
   }
 

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index f3843685a522..3778b6f297ed 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2877,31 +2877,11 @@ void Generic_GCC::AddClangCXXStdlibIncludeArgs(const 
ArgList ,
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
-}
-
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
+std::string IncludePath = detectLibcxxIncludePath(Path);
 if (IncludePath.empty() || !getVFS().exists(IncludePath))
   return false;
 addSystemInclude(DriverArgs, CC1Args, IncludePath);

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri marked 3 inline comments as done.
lebedev.ri added a comment.

@aaron.ballman @JonasToth thank you for the review!
@tonic @lattner thank you for helping resolve the misunderstading :)

> ! In D36836#2309432 , @aaron.ballman 
> wrote:
>  LGTM, thank you for your patience with the process.

HURRAY!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM, thank you for your patience with the process.




Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:381
+// FIXME: "each method in a recursion cycle" Increment is not implemented.
+case Stmt::ConditionalOperatorClass:
+case Stmt::SwitchStmtClass:

lebedev.ri wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > aaron.ballman wrote:
> > > > `BinaryConditionalOperatorClass` as well (for all the places we're 
> > > > dealing with `ConditionalOperatorClass`)?
> > > No, `BinaryConditionalOperator` is explicitly exempt.
> > I didn't see anything in the paper that talked about this (it's a GNU 
> > extension). I feel like anywhere we handle a ternary conditional we should 
> > also handle a binary conditional, e.g.,
> > ```
> > foo ? foo : bar; // ternary form
> > foo ? : bar; // binary form of the same thing
> > ```
> > but maybe I'm misunderstanding something.
> As discussed, it does seem like they should at least cause increase in 
> nesting level.
> I suspect, they should also cause increase in cognitive complexity IFF 
> they're nested somehow,
> because `foo ?: bar?: baz` doesn't really seem straight-forward.
> But likewise, they're an extension, so i think we could fine-tune that later.
Agreed, this can be done in a follow-up.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:473
+case Decl::CXXConstructor:
+case Decl::CXXDestructor:
+  break;

lebedev.ri wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > aaron.ballman wrote:
> > > > What about other special member functions like overloaded operators and 
> > > > whatnot? How about block declarations?
> > > > 
> > > > Namespaces is another one I was curious about but suspect may not want 
> > > > to be handled here.
> > > > What about other special member functions like overloaded operators and 
> > > > whatnot?
> > > 
> > > Those are `CXXMethodDecl`, but i'll add a test.
> > > 
> > > > How about block declarations?
> > > 
> > > Right, we should handle them, not blockstatements.
> > > 
> > > > Namespaces is another one I was curious about but suspect may not want 
> > > > to be handled here.
> > > 
> > > To the best of my knowledge, those can only appear at the global scope.
> > >> Namespaces is another one I was curious about but suspect may not want 
> > >> to be handled here.
> > > To the best of my knowledge, those can only appear at the global scope.
> > 
> > They can, but I wasn't certain if they'd add to complexity or not given 
> > that you can nest them deeply. But now I see that the paper doesn't mention 
> > them in terms of C++ but does talk about something similar with JavaScript 
> > that suggests they should not contribute to complexity.
> What i mean is, can you define a new `namespace` within the function's body?
> I don't believe that to be possible, therefore we shouldn't/couldn't care 
> about that,
> because we start at function scope.
> What i mean is, can you define a new namespace within the function's body?

You cannot.

> I don't believe that to be possible, therefore we shouldn't/couldn't care 
> about that, because we start at function scope.

Agreed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D88700: [clang-tidy] modernize-use-trailing-return-type fix #44206

[Bernhard Manfred Gruber via Phabricator via cfe-commits]

bernhardmgruber added a comment.

Thank you for the quick review! Can you please commit it for me as well? Thank 
you!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88700/new/

https://reviews.llvm.org/D88700

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

[PATCH] D88734: [HIP] Align device binary

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:374
+auto BI = BundlesInfo[CurWriteBundleTarget];
+OS.seek(BI.Offset);
 OS.write(Input.getBufferStart(), Input.getBufferSize());

tra wrote:
> Does the bundler anways create the file from scratch or truncate it?
> If it were to operate on existing file, seek would leave some data as is and 
> that may result in nondeterministic output.
> It may be better to explicitly zero the padding.
It will truncate the output file if it exists, therefore it should be fine to 
use seek.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88734/new/

https://reviews.llvm.org/D88734

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri marked 4 inline comments as done.
lebedev.ri added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:381
+// FIXME: "each method in a recursion cycle" Increment is not implemented.
+case Stmt::ConditionalOperatorClass:
+case Stmt::SwitchStmtClass:

aaron.ballman wrote:
> lebedev.ri wrote:
> > aaron.ballman wrote:
> > > `BinaryConditionalOperatorClass` as well (for all the places we're 
> > > dealing with `ConditionalOperatorClass`)?
> > No, `BinaryConditionalOperator` is explicitly exempt.
> I didn't see anything in the paper that talked about this (it's a GNU 
> extension). I feel like anywhere we handle a ternary conditional we should 
> also handle a binary conditional, e.g.,
> ```
> foo ? foo : bar; // ternary form
> foo ? : bar; // binary form of the same thing
> ```
> but maybe I'm misunderstanding something.
As discussed, it does seem like they should at least cause increase in nesting 
level.
I suspect, they should also cause increase in cognitive complexity IFF they're 
nested somehow,
because `foo ?: bar?: baz` doesn't really seem straight-forward.
But likewise, they're an extension, so i think we could fine-tune that later.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:428
+case Stmt::DoStmtClass:
+case Stmt::CXXCatchStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::PenalizeNesting;

aaron.ballman wrote:
> lebedev.ri wrote:
> > aaron.ballman wrote:
> > > `SEHExceptStmtClass` as well?
> > I'm very much unfamiliar with that extension.
> > I would prefer to leave it as-is for now.
> I'm fine handling it in a follow-up. I suspect there may be other esoteric 
> AST nodes we want to add, I just tried to hit the ones that were most obvious 
> to me.
Okay, thanks.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:473
+case Decl::CXXConstructor:
+case Decl::CXXDestructor:
+  break;

aaron.ballman wrote:
> lebedev.ri wrote:
> > aaron.ballman wrote:
> > > What about other special member functions like overloaded operators and 
> > > whatnot? How about block declarations?
> > > 
> > > Namespaces is another one I was curious about but suspect may not want to 
> > > be handled here.
> > > What about other special member functions like overloaded operators and 
> > > whatnot?
> > 
> > Those are `CXXMethodDecl`, but i'll add a test.
> > 
> > > How about block declarations?
> > 
> > Right, we should handle them, not blockstatements.
> > 
> > > Namespaces is another one I was curious about but suspect may not want to 
> > > be handled here.
> > 
> > To the best of my knowledge, those can only appear at the global scope.
> >> Namespaces is another one I was curious about but suspect may not want to 
> >> be handled here.
> > To the best of my knowledge, those can only appear at the global scope.
> 
> They can, but I wasn't certain if they'd add to complexity or not given that 
> you can nest them deeply. But now I see that the paper doesn't mention them 
> in terms of C++ but does talk about something similar with JavaScript that 
> suggests they should not contribute to complexity.
What i mean is, can you define a new `namespace` within the function's body?
I don't believe that to be possible, therefore we shouldn't/couldn't care about 
that,
because we start at function scope.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D88730: [HIP] Fix default output file for -E

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

LGTM.




Comment at: clang/test/Driver/hip-output-file-name.hip:13-15
+// RUN: %clang -### -E -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s

yaxunl wrote:
> tra wrote:
> > What does it mean for `-E` to be used when we compile for host and multiple 
> > devices. I believe for CUDA clang errors out unless there's only one 
> > sub-compilation. What does HIP do when it's run with `-E -o -` ?
> > 
> > Looks like CUDA (and, maybe HIP, too) has a bug there. `-E` will run 
> > preprocess on all subcompilations. `-E -o -` will error out claiming that 
> > you can't use `-o` for multiple output files, even though `-###` shows the 
> > same `-o -` in all subcompilations in both cases.
> > 
> > 
> > 
> > 
> HIP will emit a clang-offload-bundler file in textual format. Clang is able 
> to consume this file by unbundling it. I think ccache uses it to generate a 
> hash to check if a file and its dependent header files have changed. Since 
> this bundled file is in text format, ccache is able to use it to generate a 
> hash which covers both host dependence and device dependence.
That would explain why I sometimes get a screenfull of noise when I do 
something like that with HIP. :-/
My expectation of `-E [-o -]` is that I get the text of preprocessed source. In 
this regard, CUDA's concatenate all preprocessd outputs is a bit better than 
HIPs' "here's a binary blob with preprocessed output inside".

This is a bit of a mess that's beyond the scope of this CL and should be dealt 
with separately.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88730/new/

https://reviews.llvm.org/D88730

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:367-368
+  bool TraverseStmt(Stmt *Node) {
+if (!Node)
+  return Base::TraverseStmt(Node);
+

lebedev.ri wrote:
> aaron.ballman wrote:
> > If there's not a node, do we really need to traverse it?
> This is consistent across this whole `FunctionASTVisitor`, and is consistent 
> with other `RecursiveASTVisitor<>`s,
> so i'll leave this as-is. If this is wrong, other places should be changed 
> too.
Fine by me, thanks.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:381
+// FIXME: "each method in a recursion cycle" Increment is not implemented.
+case Stmt::ConditionalOperatorClass:
+case Stmt::SwitchStmtClass:

lebedev.ri wrote:
> aaron.ballman wrote:
> > `BinaryConditionalOperatorClass` as well (for all the places we're dealing 
> > with `ConditionalOperatorClass`)?
> No, `BinaryConditionalOperator` is explicitly exempt.
I didn't see anything in the paper that talked about this (it's a GNU 
extension). I feel like anywhere we handle a ternary conditional we should also 
handle a binary conditional, e.g.,
```
foo ? foo : bar; // ternary form
foo ? : bar; // binary form of the same thing
```
but maybe I'm misunderstanding something.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:428
+case Stmt::DoStmtClass:
+case Stmt::CXXCatchStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::PenalizeNesting;

lebedev.ri wrote:
> aaron.ballman wrote:
> > `SEHExceptStmtClass` as well?
> I'm very much unfamiliar with that extension.
> I would prefer to leave it as-is for now.
I'm fine handling it in a follow-up. I suspect there may be other esoteric AST 
nodes we want to add, I just tried to hit the ones that were most obvious to me.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:473
+case Decl::CXXConstructor:
+case Decl::CXXDestructor:
+  break;

lebedev.ri wrote:
> aaron.ballman wrote:
> > What about other special member functions like overloaded operators and 
> > whatnot? How about block declarations?
> > 
> > Namespaces is another one I was curious about but suspect may not want to 
> > be handled here.
> > What about other special member functions like overloaded operators and 
> > whatnot?
> 
> Those are `CXXMethodDecl`, but i'll add a test.
> 
> > How about block declarations?
> 
> Right, we should handle them, not blockstatements.
> 
> > Namespaces is another one I was curious about but suspect may not want to 
> > be handled here.
> 
> To the best of my knowledge, those can only appear at the global scope.
>> Namespaces is another one I was curious about but suspect may not want to be 
>> handled here.
> To the best of my knowledge, those can only appear at the global scope.

They can, but I wasn't certain if they'd add to complexity or not given that 
you can nest them deeply. But now I see that the paper doesn't mention them in 
terms of C++ but does talk about something similar with JavaScript that 
suggests they should not contribute to complexity.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 295904.
lebedev.ri added a comment.

Maybe fine tune comments - we count block decls, not block 
statements/expressions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
@@ -0,0 +1,1015 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- -config='{CheckOptions: [{key: readability-function-cognitive-complexity.Threshold, value: 0}]}' -- -std=c++11 -fblocks -w
+
+// any function should be checked.
+
+extern int ext_func(int x = 0);
+
+int some_func(int x = 0);
+
+static int some_other_func(int x = 0) {}
+
+template void some_templ_func(T x = 0) {}
+
+class SomeClass {
+public:
+  int *begin(int x = 0);
+  int *end(int x = 0);
+  static int func(int x = 0);
+  template void some_templ_func(T x = 0) {}
+  SomeClass() = default;
+  SomeClass(SomeClass&) = delete;
+};
+
+// nothing ever decreases cognitive complexity, so we can check all the things
+// in one go. none of the following should increase cognitive complexity:
+void unittest_false() {
+  {};
+  ext_func();
+  some_func();
+  some_other_func();
+  some_templ_func();
+  some_templ_func();
+  SomeClass::func();
+  SomeClass C;
+  C.some_templ_func();
+  C.some_templ_func();
+  C.func();
+  C.end();
+  int i = some_func();
+  i = i;
+  i++;
+  --i;
+  i < 0;
+  int j = 0 ?: 1;
+  auto k = new int;
+  delete k;
+  throw i;
+  {
+throw i;
+  }
+end:
+  return;
+}
+
+#if 1
+#define CC100
+#else
+// this macro has cognitive complexity of 100.
+// it is needed to be able to compare the testcases with the
+// reference Sonar implementation. please place it right after the first
+// CHECK-NOTES in each function
+#define CC100 if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){}if(1){}
+#endif
+
+////
+//-- B1. Increments --//
+////
+// Check that every thing listed in B1 of the specification does indeed   //
+// recieve the base increment, and that not-body does not increase nesting//
+////
+
+// break does not increase cognitive complexity.
+// only  break LABEL  does, but it is unavaliable in C or C++
+
+// continue does not increase cognitive complexity.
+// only  continue LABEL  does, but it is unavaliable in C or C++
+
+void unittest_b1_00() {
+// CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'unittest_b1_00' has cognitive complexity of 33 (threshold 0) [readability-function-cognitive-complexity]
+  CC100;
+
+  if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:3: note: +1, including nesting penalty of 0, nesting level increased to 1{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:9: note: +1, including nesting penalty of 0, nesting level increased to 1{{$}}
+
+if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:5: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:11: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+} else if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:12: note: +1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:18: note: +3, including nesting penalty of 2, nesting level increased to 3{{$}}
+} else {
+// CHECK-NOTES: :[[@LINE-1]]:7: note: +1, nesting level increased to 2{{$}}
+}
+  } else if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:10: note: +1, nesting level increased to 1{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:16: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+
+if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:5: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+// CHECK-NOTES: :[[@LINE-2]]:11: note: +2, including nesting penalty of 1, nesting level increased to 2{{$}}
+} else if (1 ? 1 : 0) {
+// CHECK-NOTES: :[[@LINE-1]]:12: note: +1, nesting level increased to 2{{$}}

[PATCH] D88754: [clang] Add a test for CGDebugInfo treatment of blocks

[Scott Linder via Phabricator via cfe-commits]

scott.linder created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
scott.linder requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88754

Files:
  clang/test/CodeGen/debug-info-block-expr.c


Index: clang/test/CodeGen/debug-info-block-expr.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-block-expr.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -emit-llvm -o - %s | 
FileCheck %s
+// Verify that the desired DIExpression are generated for blocks.
+
+void test() {
+// CHECK: call void @llvm.dbg.declare({{.*}}!DIExpression(DW_OP_plus_uconst, 
8, DW_OP_deref, DW_OP_plus_uconst, 24){{.*}})
+  __block int i;
+// CHECK: call void @llvm.dbg.declare({{.*}}!DIExpression(DW_OP_deref, 
DW_OP_plus_uconst, 32, DW_OP_deref, DW_OP_plus_uconst, 8, DW_OP_deref, 
DW_OP_plus_uconst, 24){{.*}})
+  ^ { i = 1; }();
+}


Index: clang/test/CodeGen/debug-info-block-expr.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-block-expr.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
+// Verify that the desired DIExpression are generated for blocks.
+
+void test() {
+// CHECK: call void @llvm.dbg.declare({{.*}}!DIExpression(DW_OP_plus_uconst, 8, DW_OP_deref, DW_OP_plus_uconst, 24){{.*}})
+  __block int i;
+// CHECK: call void @llvm.dbg.declare({{.*}}!DIExpression(DW_OP_deref, DW_OP_plus_uconst, 32, DW_OP_deref, DW_OP_plus_uconst, 8, DW_OP_deref, DW_OP_plus_uconst, 24){{.*}})
+  ^ { i = 1; }();
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:367-368
+  bool TraverseStmt(Stmt *Node) {
+if (!Node)
+  return Base::TraverseStmt(Node);
+

aaron.ballman wrote:
> If there's not a node, do we really need to traverse it?
This is consistent across this whole `FunctionASTVisitor`, and is consistent 
with other `RecursiveASTVisitor<>`s,
so i'll leave this as-is. If this is wrong, other places should be changed too.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:381
+// FIXME: "each method in a recursion cycle" Increment is not implemented.
+case Stmt::ConditionalOperatorClass:
+case Stmt::SwitchStmtClass:

aaron.ballman wrote:
> `BinaryConditionalOperatorClass` as well (for all the places we're dealing 
> with `ConditionalOperatorClass`)?
No, `BinaryConditionalOperator` is explicitly exempt.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:388
+case Stmt::CXXCatchStmtClass:
+case Stmt::GotoStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::Increment;

aaron.ballman wrote:
> Should `IndirectGotoStmtClass` be handled the same way?
Right, it should be.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:410
+case Stmt::CXXCatchStmtClass:
+case Stmt::LambdaExprClass:
+  Reasons |= CognitiveComplexity::Criteria::IncrementNesting;

aaron.ballman wrote:
> `BlockExprClass` as well?
> 
> Should GNU statement expressions also be treated like a lambda or block?
> BlockExprClass as well?

Thank you for the example, that seems obvious & straight-forward to support.
As discussed, we should handle decls thought, not exprs.

> Should GNU statement expressions also be treated like a lambda or block?

Hm, i guess it should be.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:428
+case Stmt::DoStmtClass:
+case Stmt::CXXCatchStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::PenalizeNesting;

aaron.ballman wrote:
> `SEHExceptStmtClass` as well?
I'm very much unfamiliar with that extension.
I would prefer to leave it as-is for now.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:473
+case Decl::CXXConstructor:
+case Decl::CXXDestructor:
+  break;

aaron.ballman wrote:
> What about other special member functions like overloaded operators and 
> whatnot? How about block declarations?
> 
> Namespaces is another one I was curious about but suspect may not want to be 
> handled here.
> What about other special member functions like overloaded operators and 
> whatnot?

Those are `CXXMethodDecl`, but i'll add a test.

> How about block declarations?

Right, we should handle them, not blockstatements.

> Namespaces is another one I was curious about but suspect may not want to be 
> handled here.

To the best of my knowledge, those can only appear at the global scope.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 295902.
lebedev.ri marked 10 inline comments as done.
lebedev.ri added a comment.

In D36836#2309243 , @aaron.ballman 
wrote:

> In D36836#2308981 , @lattner wrote:
>
>> Hi all,
>>
>> The LLVM foundation board discussed this offline -- it looks like the 
>> contributor is a bit confused about the LLVM project policies towards 
>> copyright, license, patent stuff etc.  I really appreciate the dilligence 
>> here to capture the ideas that went into this code.
>>
>> My understanding is that the code and documentation are not derived from 
>> anyone else's code or documentation -- they are fresh implementations based 
>> on a paper written in english prose.  If that is the case, please remove the 
>> LICENSE.TXT file -- it isn't necessary and it is confusing for people.I 
>> would also recommend replacing all the references to sonar source with a 
>> functional description of what this patch is doing - we aren't talking about 
>> adding a feature because of sonar source, my understanding is that this is 
>> adding a cyclomatic complexity checker.  If and when the feature evolves 
>> over time, it would be misleading for it to be called sonar source.
>>
>> Please note that I didn't do a full code review here, others should do that.
>
> Thank you to you and the board for looking into this and helping us reach the 
> right decision!

+1.

> In D36836#2309103 , @lebedev.ri 
> wrote:
>
>>> please remove the LICENSE.TXT file -- it isn't necessary and it is 
>>> confusing for people.I would also recommend replacing all the 
>>> references to sonar source with a functional description of what this patch 
>>> is doing - we aren't talking about adding a feature because of sonar source,
>>
>> Done, as much as possible. I'd still prefer to maintain a reference to the 
>> spec on which it is based.
>> Note that it was done because that is what was requested previously by 
>> reviewers.
>
> I agree that we should still document that this is based off the Sonar Source 
> paper because it's not a generic implementation but a specific one. I think 
> you've struck a good balance with the current patch.

Good!

I've addressed most of the review comments, excluding the one about Microsoft 
SEH support - i'd prefer to leave that for a follow-up :)
There may be other straddlers anyway.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
@@ -0,0 +1,1015 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- -config='{CheckOptions: [{key: readability-function-cognitive-complexity.Threshold, value: 0}]}' -- -std=c++11 -fblocks -w
+
+// any function should be checked.
+
+extern int ext_func(int x = 0);
+
+int some_func(int x = 0);
+
+static int some_other_func(int x = 0) {}
+
+template void some_templ_func(T x = 0) {}
+
+class SomeClass {
+public:
+  int *begin(int x = 0);
+  int *end(int x = 0);
+  static int func(int x = 0);
+  template void some_templ_func(T x = 0) {}
+  SomeClass() = default;
+  SomeClass(SomeClass&) = delete;
+};
+
+// nothing ever decreases cognitive complexity, so we can check all the things
+// in one go. none of the following should increase cognitive complexity:
+void unittest_false() {
+  {};
+  ext_func();
+  some_func();
+  some_other_func();
+  some_templ_func();
+  some_templ_func();
+  SomeClass::func();
+  SomeClass C;
+  C.some_templ_func();
+  C.some_templ_func();
+  C.func();
+  C.end();
+  int i = some_func();
+  i = i;
+  i++;
+  --i;
+  i < 0;
+  int j = 0 ?: 1;
+  auto k = new int;
+  delete k;
+  throw i;
+  {
+throw i;
+  }
+end:
+  return;
+}
+
+#if 1
+#define CC100
+#else
+// this macro has cognitive complexity of 100.
+// it is needed to be able to compare the testcases with the
+// reference Sonar implementation. please place it right after the first
+// CHECK-NOTES in each function
+#define CC100 

[PATCH] D88730: [HIP] Fix default output file for -E

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/test/Driver/hip-output-file-name.hip:13-15
+// RUN: %clang -### -E -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s

tra wrote:
> What does it mean for `-E` to be used when we compile for host and multiple 
> devices. I believe for CUDA clang errors out unless there's only one 
> sub-compilation. What does HIP do when it's run with `-E -o -` ?
> 
> Looks like CUDA (and, maybe HIP, too) has a bug there. `-E` will run 
> preprocess on all subcompilations. `-E -o -` will error out claiming that you 
> can't use `-o` for multiple output files, even though `-###` shows the same 
> `-o -` in all subcompilations in both cases.
> 
> 
> 
> 
HIP will emit a clang-offload-bundler file in textual format. Clang is able to 
consume this file by unbundling it. I think ccache uses it to generate a hash 
to check if a file and its dependent header files have changed. Since this 
bundled file is in text format, ccache is able to use it to generate a hash 
which covers both host dependence and device dependence.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88730/new/

https://reviews.llvm.org/D88730

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D36836#2308981 , @lattner wrote:

> Hi all,
>
> The LLVM foundation board discussed this offline -- it looks like the 
> contributor is a bit confused about the LLVM project policies towards 
> copyright, license, patent stuff etc.  I really appreciate the dilligence 
> here to capture the ideas that went into this code.
>
> My understanding is that the code and documentation are not derived from 
> anyone else's code or documentation -- they are fresh implementations based 
> on a paper written in english prose.  If that is the case, please remove the 
> LICENSE.TXT file -- it isn't necessary and it is confusing for people.I 
> would also recommend replacing all the references to sonar source with a 
> functional description of what this patch is doing - we aren't talking about 
> adding a feature because of sonar source, my understanding is that this is 
> adding a cyclomatic complexity checker.  If and when the feature evolves over 
> time, it would be misleading for it to be called sonar source.
>
> Please note that I didn't do a full code review here, others should do that.

Thank you to you and the board for looking into this and helping us reach the 
right decision!

In D36836#2309103 , @lebedev.ri wrote:

>> please remove the LICENSE.TXT file -- it isn't necessary and it is confusing 
>> for people.I would also recommend replacing all the references to sonar 
>> source with a functional description of what this patch is doing - we aren't 
>> talking about adding a feature because of sonar source,
>
> Done, as much as possible. I'd still prefer to maintain a reference to the 
> spec on which it is based.
> Note that it was done because that is what was requested previously by 
> reviewers.

I agree that we should still document that this is based off the Sonar Source 
paper because it's not a generic implementation but a specific one. I think 
you've struck a good balance with the current patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:93-96
+// Criteria only uses three bits, so uint8_t is used as an underlying type.
+// We could make C a bitfield, but then we would not save anything because
+// of the padding for alignment, and also we would have to worry about
+// the differences between compilers.

I'm not certain this comment adds a whole lot.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:154
+
+// All the possible messages that can be outputed. The choice of the message
+// to use is based of the combination of the CognitiveComplexity::Criteria's.

outputed -> output



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:155
+// All the possible messages that can be outputed. The choice of the message
+// to use is based of the combination of the CognitiveComplexity::Criteria's.
+// It would be nice to have it in CognitiveComplexity struct, but then it is

Criteria's -> Criteria



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:222
+
+  // Used to efficiently know the last type of binary sequence operator that
+  // was encountered. It would make sense for the function call to start the

of binary -> of the binary



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:367-368
+  bool TraverseStmt(Stmt *Node) {
+if (!Node)
+  return Base::TraverseStmt(Node);
+

If there's not a node, do we really need to traverse it?



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:381
+// FIXME: "each method in a recursion cycle" Increment is not implemented.
+case Stmt::ConditionalOperatorClass:
+case Stmt::SwitchStmtClass:

`BinaryConditionalOperatorClass` as well (for all the places we're dealing with 
`ConditionalOperatorClass`)?



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:388
+case Stmt::CXXCatchStmtClass:
+case Stmt::GotoStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::Increment;

Should `IndirectGotoStmtClass` be handled the same way?



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:410
+case Stmt::CXXCatchStmtClass:
+case Stmt::LambdaExprClass:
+  Reasons |= CognitiveComplexity::Criteria::IncrementNesting;

`BlockExprClass` as well?

Should GNU statement expressions also be treated like a lambda or block?



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:428
+case Stmt::DoStmtClass:
+case Stmt::CXXCatchStmtClass:
+  Reasons |= CognitiveComplexity::Criteria::PenalizeNesting;

`SEHExceptStmtClass` as well?



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:473
+case Decl::CXXConstructor:
+case Decl::CXXDestructor:
+  break;

What about other special member functions like overloaded operators and 
whatnot? How about block declarations?

Namespaces is another one I was curious about but suspect may not want to be 
handled here.



Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h:16-20
+namespace clang {
+namespace tidy {
+class ClangTidyContext;
+}
+} // namespace clang

This shouldn't be necessary, right?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D88730: [HIP] Fix default output file for -E

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/Driver/hip-output-file-name.hip:13-15
+// RUN: %clang -### -E -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s

What does it mean for `-E` to be used when we compile for host and multiple 
devices. I believe for CUDA clang errors out unless there's only one 
sub-compilation. What does HIP do when it's run with `-E -o -` ?

Looks like CUDA (and, maybe HIP, too) has a bug there. `-E` will run preprocess 
on all subcompilations. `-E -o -` will error out claiming that you can't use 
`-o` for multiple output files, even though `-###` shows the same `-o -` in all 
subcompilations in both cases.






CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88730/new/

https://reviews.llvm.org/D88730

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

[clang] 66cf68e - [docs] Update ControlFlowIntegrity.rst.

[Evgenii Stepanov via cfe-commits]

Author: Evgenii Stepanov
Date: 2020-10-02T12:01:05-07:00
New Revision: 66cf68ed46789217a8382bb419a0bda1c4e97650

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

LOG: [docs] Update ControlFlowIntegrity.rst.

Expand the list of targets that support cfi-icall.
Add ThinLTO everywhere LTO is mentioned. AFAIK all CFI features are
supported with ThinLTO.

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

Added: 


Modified: 
clang/docs/ControlFlowIntegrity.rst

Removed: 




diff  --git a/clang/docs/ControlFlowIntegrity.rst 
b/clang/docs/ControlFlowIntegrity.rst
index 03e27d3ede89..3f6b3ca6cafb 100644
--- a/clang/docs/ControlFlowIntegrity.rst
+++ b/clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@ For example, you can build your program with
 to use all schemes except for non-virtual member function call and indirect 
call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@ statically linked into the program or shared library, and 
calls across
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@ Shared library support
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI



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

[PATCH] D87717: [docs] Update ControlFlowIntegrity.rst.

[Evgenii Stepanov via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG66cf68ed4678: [docs] Update ControlFlowIntegrity.rst. 
(authored by eugenis).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87717/new/

https://reviews.llvm.org/D87717

Files:
  clang/docs/ControlFlowIntegrity.rst


Index: clang/docs/ControlFlowIntegrity.rst
===
--- clang/docs/ControlFlowIntegrity.rst
+++ clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@
 to use all schemes except for non-virtual member function call and indirect 
call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI


Index: clang/docs/ControlFlowIntegrity.rst
===
--- clang/docs/ControlFlowIntegrity.rst
+++ clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@
 to use all schemes except for non-virtual member function call and indirect call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87717: [docs] Update ControlFlowIntegrity.rst.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis updated this revision to Diff 295888.
eugenis added a comment.

fix a typo


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87717/new/

https://reviews.llvm.org/D87717

Files:
  clang/docs/ControlFlowIntegrity.rst


Index: clang/docs/ControlFlowIntegrity.rst
===
--- clang/docs/ControlFlowIntegrity.rst
+++ clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@
 to use all schemes except for non-virtual member function call and indirect 
call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI


Index: clang/docs/ControlFlowIntegrity.rst
===
--- clang/docs/ControlFlowIntegrity.rst
+++ clang/docs/ControlFlowIntegrity.rst
@@ -76,8 +76,8 @@
 to use all schemes except for non-virtual member function call and indirect call
 checking.
 
-Remember that you have to provide ``-flto`` if at least one CFI scheme is
-enabled.
+Remember that you have to provide ``-flto`` or ``-flto=thin`` if at
+least one CFI scheme is enabled.
 
 Trapping and Diagnostics
 
@@ -217,7 +217,8 @@
 shared library boundaries are handled as if the callee was not compiled with
 ``-fsanitize=cfi-icall``.
 
-This scheme is currently only supported on the x86 and x86_64 architectures.
+This scheme is currently supported on a limited set of targets: x86,
+x86_64, arm, arch64 and wasm.
 
 ``-fsanitize-cfi-icall-generalize-pointers``
 
@@ -368,7 +369,7 @@
 Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control
 flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
-built with ``-flto``.
+built with ``-flto`` or ``-flto=thin``.
 
 Normally, CFI checks will only be performed for classes that have hidden LTO
 visibility. With this flag enabled, the compiler will emit cross-DSO CFI
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88734: [HIP] Align device binary

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:374
+auto BI = BundlesInfo[CurWriteBundleTarget];
+OS.seek(BI.Offset);
 OS.write(Input.getBufferStart(), Input.getBufferSize());

Does the bundler anways create the file from scratch or truncate it?
If it were to operate on existing file, seek would leave some data as is and 
that may result in nondeterministic output.
It may be better to explicitly zero the padding.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88734/new/

https://reviews.llvm.org/D88734

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

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGObjC.cpp:487
+
+  // Walk both lists to get the full set of implied protocols
+  llvm::DenseSet AllImpliedProtocols;

lanza wrote:
> rjmccall wrote:
> > You should add something like ", including all the runtime protocols but 
> > not the non-runtime protocols".
> Do you anticipate a usage of `getImpliedProtocols` other than this algorithm? 
> I include the non-runtime protos in the all implied list simply because it 
> simplifies the collection. e.g. you insert iff it's a runtime protocol and if 
> not you have to check `contains` and then potentially add a non-runtime to 
> the work queue as many times as it's seen. 
> 
> Ultimately their inclusion in the all-implied list is meaningless because we 
> never attempt to insert a non-runtime protocol into the `RuntimePDs` list 
> anyways. So it's either extra elements in the `AllImplied` list or extra work 
> in the `getImpliedProtocols` method without any behavioral differences.
Ah, yes, that's a fair point.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75574/new/

https://reviews.llvm.org/D75574

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

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/test/SemaCUDA/device-var-init.cu:404
 __host__ __device__ void hd_sema() {
   static int x = 42;
 }

yaxunl wrote:
> tra wrote:
> > yaxunl wrote:
> > > how does this work in device compilation? Is this equivalent to `static 
> > > __device__ int x = 42`?
> > Correct. 
> so static variable without `__device__/__constant__` attribute in host device 
> function implies `__device__` attribute in device compilation.
> 
> Is this also true in device function? We need Sema and CodeGen tests for 
> these cases.
> 
> Also, can we document these changes? It is easily forgotten.
I think of it as a static variable in a `__device__` function. There should be 
no host-side shadow for it, which would normally be created for a `__device__` 
variable.

The tests at the beginning of df_sema() in SemaCUDA/device-var-init.cu already 
check that static w/o attributes is allowed in `__device__`.
I'll update CodeGen tests to verify that we generate correct code.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88345/new/

https://reviews.llvm.org/D88345

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

[PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend cf. D69272 - Work in Progress

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 295880.
mibintc added a comment.

I patched my workspace with D88498  from Sept 
29. I fixed some nits and also enabled FENV_ACCESS when the command line option 
specifies frounding-math. This corresponds to Microsoft's documentation of 
their option /fp:strict 
https://docs.microsoft.com/en-us/cpp/preprocessor/fenv-access?view=vs-2019 "The 
[/fp:strict] command-line option automatically enables fenv_access."  Also if 
#pragma to enable fenv_access is seen, RoundingMode is set to Dynamic
I have some questions I'll add them as inline comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87528/new/

https://reviews.llvm.org/D87528

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/CodeGen/fp-floatcontrol-pragma.cpp
  clang/test/CodeGen/pragma-fenv_access.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/test/Parser/pragma-fenv_access.c
  clang/test/Preprocessor/pragma_unknown.c

Index: clang/test/Preprocessor/pragma_unknown.c
===
--- clang/test/Preprocessor/pragma_unknown.c
+++ clang/test/Preprocessor/pragma_unknown.c
@@ -16,15 +16,6 @@
 // CHECK: {{^}}#pragma STDC FP_CONTRACT DEFAULT{{$}}
 // CHECK: {{^}}#pragma STDC FP_CONTRACT IN_BETWEEN{{$}}
 
-#pragma STDC FENV_ACCESS ON  // expected-warning {{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
-#pragma STDC FENV_ACCESS OFF
-#pragma STDC FENV_ACCESS DEFAULT
-#pragma STDC FENV_ACCESS IN_BETWEEN   // expected-warning {{expected 'ON' or 'OFF' or 'DEFAULT' in pragma}}
-// CHECK: {{^}}#pragma STDC FENV_ACCESS ON{{$}}
-// CHECK: {{^}}#pragma STDC FENV_ACCESS OFF{{$}}
-// CHECK: {{^}}#pragma STDC FENV_ACCESS DEFAULT{{$}}
-// CHECK: {{^}}#pragma STDC FENV_ACCESS IN_BETWEEN{{$}}
-
 #pragma STDC CX_LIMITED_RANGE ON
 #pragma STDC CX_LIMITED_RANGE OFF
 #pragma STDC CX_LIMITED_RANGE DEFAULT 
Index: clang/test/Parser/pragma-fenv_access.c
===
--- /dev/null
+++ clang/test/Parser/pragma-fenv_access.c
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -ffp-exception-behavior=strict -DSTRICT -fsyntax-only -verify %s
+// RUN: %clang_cc1 -x c++ -DCPP -DSTRICT -ffp-exception-behavior=strict -fsyntax-only -verify %s
+#ifdef CPP
+#define CONST constexpr
+#else
+#define CONST const
+#endif
+
+#pragma STDC FENV_ACCESS IN_BETWEEN   // expected-warning {{expected 'ON' or 'OFF' or 'DEFAULT' in pragma}}
+
+#pragma STDC FENV_ACCESS OFF
+
+float func_04(int x, float y) {
+  if (x)
+return y + 2;
+  #pragma STDC FENV_ACCESS ON // expected-error{{'#pragma STDC FENV_ACCESS' can only appear at file scope or at the start of a compound statement}}
+  return x + y;
+}
+
+int main() {
+  CONST float one = 1.0F ;
+  CONST float three = 3.0F ;
+  CONST float four = 4.0F ;
+  CONST float frac_ok = one/four;
+#if defined(CPP) & defined(STRICT)
+//expected-error@+3 {{constexpr variable 'frac' must be initialized by a constant expression}}
+//expected-note@+2 {{compile time floating point arithmetic suppressed in strict evaluation modes}}
+#endif
+  CONST float frac = one/three; // rounding
+  CONST double d = one;
+  CONST int not_too_big = 255;
+  CONST float fnot_too_big = not_too_big;
+  CONST int too_big = 0x7ff0;
+#if defined(CPP) & defined(STRICT)
+//expected-error@+6 {{constexpr variable 'fbig' must be initialized by a constant expression}}
+//expected-note@+5 {{compile time floating point arithmetic suppressed in strict evaluation modes}}
+#endif
+#if defined(CPP)
+//expected-warning@+2{{implicit conversion}}
+#endif
+  CONST float fbig = too_big; // inexact
+  if (one <= four)  return 0;
+  return -1;
+}
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -26,19 +26,14 @@
 double a = 0.0;
 double b = 1.0;
 
-//FIXME At some point this warning will be removed, until then
-//  document the warning
-#ifdef FAST
-// expected-warning@+1{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
-#pragma STDC FENV_ACCESS ON
-#else
-#pragma STDC FENV_ACCESS ON // expected-warning{{pragma STDC FENV_ACCESS ON is not supported, ignoring pragma}}
-#endif
 #ifdef STRICT
 #pragma float_control(precise, off) // expected-error {{'#pragma float_control(precise, 

[PATCH] D36836: [clang-tidy] Implement readability-function-cognitive-complexity check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 295879.
lebedev.ri retitled this revision from "[clang-tidy] Implement 
sonarsource-function-cognitive-complexity check" to "[clang-tidy] Implement 
readability-function-cognitive-complexity check".
lebedev.ri added a comment.

@aaron.ballman @alexfh it is my understanding that i'm to proceed with commit. 
No explicit acknowledgement from your side is needed.

In D36836#2308981 , @lattner wrote:

> Hi all,
>
> The LLVM foundation board discussed this offline

Yay, thank you!

> it looks like the contributor is a bit confused about the LLVM project 
> policies towards copyright, license, patent stuff etc.

...

> I really appreciate the dilligence here to capture the ideas that went into 
> this code.
>
> My understanding is that the code and documentation are not derived from 
> anyone else's code or documentation -- they are fresh implementations based 
> on a paper written in english prose.  If that is the case,

That is the case, yes. This is based on the spec 
.

> please remove the LICENSE.TXT file -- it isn't necessary and it is confusing 
> for people.I would also recommend replacing all the references to sonar 
> source with a functional description of what this patch is doing - we aren't 
> talking about adding a feature because of sonar source,

Done, as much as possible. I'd still prefer to maintain a reference to the spec 
on which it is based.
Note that it was done because that is what was requested previously by 
reviewers.

> my understanding is that this is adding a cyclomatic complexity checker.

Well, yes and no. Note that this is *NOT* a well-known `cyclomatic complexity` 
metric, but a novel `cognitive complexity` metric.

> If and when the feature evolves over time, it would be misleading for it to 
> be called sonar source.

Yes.

> Please note that I didn't do a full code review here, others should do that.

All good on that front, this has been quite extensively reviewed years ago :)

> -Chris

Roman


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity.cpp
@@ -0,0 +1,956 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- -config='{CheckOptions: [{key: readability-function-cognitive-complexity.Threshold, value: 0}]}' -- -std=c++11 -w
+
+// any function should be checked.
+
+extern int ext_func(int x = 0);
+
+int some_func(int x = 0);
+
+static int some_other_func(int x = 0) {}
+
+template void some_templ_func(T x = 0) {}
+
+class SomeClass {
+public:
+  int *begin(int x = 0);
+  int *end(int x = 0);
+  static int func(int x = 0);
+  template void some_templ_func(T x = 0) {}
+  SomeClass() = default;
+  SomeClass(SomeClass&) = delete;
+};
+
+// nothing ever decreases cognitive complexity, so we can check all the things
+// in one go. none of the following should increase cognitive complexity:
+void unittest_false() {
+  {};
+  ext_func();
+  some_func();
+  some_other_func();
+  some_templ_func();
+  some_templ_func();
+  SomeClass::func();
+  SomeClass C;
+  C.some_templ_func();
+  C.some_templ_func();
+  C.func();
+  C.end();
+  int i = some_func();
+  i = i;
+  i++;
+  --i;
+  i < 0;
+  int j = 0 ?: 1;
+  auto k = new int;
+  delete k;
+  throw i;
+  {
+throw i;
+  }
+end:
+  return;
+}
+
+#if 1
+#define CC100
+#else
+// this macro has cognitive complexity of 100.
+// it is needed to be able to compare the testcases with the
+// reference Sonar implementation. please place it right after the first
+// CHECK-NOTES in each function
+#define CC100 if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){if(1){}if(1){}
+#endif
+
+////
+//-- B1. Increments --//
+////
+// Check that every thing listed in B1 of the specification does indeed   //
+// recieve the base 

[PATCH] D88665: [ASTImporter][AST] Fix structural equivalency crash on dependent FieldDecl

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

In D88665#2308366 , @martong wrote:

>> In D88665#2307562 , @shafik wrote:
>>
>>> So was the bug we were saying there were falsely equivalent or falsely not 
>>> equivalent?
>>
>> I think the bug is the crash :)
>
> Yes. More specifically, the call of `getBitWidthValue()` caused a segfault 
> with release builds and with assertions enabled it caused the mentioned 
> assert on the given test code.

Thank you! From the test it was not obvious what was the actual cause of the 
crash so evaluating the correctness was difficult.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88665/new/

https://reviews.llvm.org/D88665

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

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

lanza updated this revision to Diff 295876.
lanza added a comment.

Comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75574/new/

https://reviews.llvm.org/D75574

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/DeclObjC.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGObjCGNU.cpp
  clang/lib/CodeGen/CGObjCMac.cpp
  clang/lib/CodeGen/CGObjCRuntime.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/CodeGenObjC/non-runtime-protocol.m
  clang/test/Misc/pragma-attribute-supported-attributes-list.test

Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -118,6 +118,7 @@
 // CHECK-NEXT: ObjCExternallyRetained (SubjectMatchRule_variable_not_is_parameter, SubjectMatchRule_function, SubjectMatchRule_block, SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCMethodFamily (SubjectMatchRule_objc_method)
 // CHECK-NEXT: ObjCNonLazyClass (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_implementation)
+// CHECK-NEXT: ObjCNonRuntimeProtocol (SubjectMatchRule_objc_protocol)
 // CHECK-NEXT: ObjCPreciseLifetime (SubjectMatchRule_variable)
 // CHECK-NEXT: ObjCRequiresPropertyDefs (SubjectMatchRule_objc_interface)
 // CHECK-NEXT: ObjCRequiresSuper (SubjectMatchRule_objc_method)
Index: clang/test/CodeGenObjC/non-runtime-protocol.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/non-runtime-protocol.m
@@ -0,0 +1,142 @@
+// RUN: not %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DPROTOEXPR -o - 2>&1 \
+// RUN: | FileCheck -check-prefix=PROTOEXPR %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY1 %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DREDUNDANCY -o - \
+// RUN: | FileCheck -check-prefix=REDUNDANCY2 %s
+
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=NONFRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -fobjc-arc -triple x86_64-apple-darwin10 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=INHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-apple-darwin -fobjc-runtime=macosx-fragile-10.5 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=FRAGILEINHERITANCE %s
+
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNUINHERITANCE %s
+//
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DBASE -o - \
+// RUN: | FileCheck -check-prefix=GNU2 %s
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu -fobjc-runtime=gnustep-2 %s -DINHERITANCE -o - \
+// RUN: | FileCheck -check-prefix=GNU2INHERITANCE %s
+
+__attribute__((objc_root_class))
+@interface Root
+@end
+@implementation Root
+@end
+
+#ifdef REDUNDANCY
+// REDUNDANCY1-NOT: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_B
+// REDUNDANCY2: _OBJC_CLASS_PROTOCOLS_$_Implementer{{.*}}_OBJC_PROTOCOL_$_C{{.*}}_OBJC_PROTOCOL_$_A
+@protocol C
+@end
+@protocol B 
+@end
+@protocol A 
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Alpha
+@end
+__attribute__((objc_non_runtime_protocol)) @protocol Beta
+@end
+@interface Implementer : Root 
+@end
+@implementation Implementer
+@end
+#endif
+
+#ifdef BASE
+// Confirm that we're not emitting protocol information for the
+// NONFRAGILE-NOT: OBJC_CLASS_NAME{{.*}}NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_INSTANCE_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_$_PROTOCOL_CLASS_METHODS_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_LABEL_PROTOCOL_$_NonRuntimeProtocol
+// NONFRAGILE-NOT: _OBJC_CLASS_PROTOCOLS_$_NonRuntimeImplementer
+// FRAGILE-NOT: OBJC_CLASS_NAME_.{{.*}}"Runtime\00"
+// FRAGILE-NOT: OBJC_PROTOCOL_NonRuntime
+// FRAGILE_NOT: OBJC_PROTOCOLS_NonRuntimeImplementer
+// GNU-NOT: private unnamed_addr constant {{.*}} c"NonRuntimeProtocol\00"
+// GNU-NOT: @.objc_protocol {{.*}}
+// GNU2-NOT: private unnamed_addr constant {{.*}} c"NonRuntimeProtocol\00"
+// GNU2-NOT: @.objc_protocol {{.*}}
+__attribute__((objc_non_runtime_protocol))

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

lanza added inline comments.



Comment at: clang/lib/CodeGen/CGObjC.cpp:487
+
+  // Walk both lists to get the full set of implied protocols
+  llvm::DenseSet AllImpliedProtocols;

rjmccall wrote:
> You should add something like ", including all the runtime protocols but not 
> the non-runtime protocols".
Do you anticipate a usage of `getImpliedProtocols` other than this algorithm? I 
include the non-runtime protos in the all implied list simply because it 
simplifies the collection. e.g. you insert iff it's a runtime protocol and if 
not you have to check `contains` and then potentially add a non-runtime to the 
work queue as many times as it's seen. 

Ultimately their inclusion in the all-implied list is meaningless because we 
never attempt to insert a non-runtime protocol into the `RuntimePDs` list 
anyways. So it's either extra elements in the `AllImplied` list or extra work 
in the `getImpliedProtocols` method without any behavioral differences.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75574/new/

https://reviews.llvm.org/D75574

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

[clang] eb55735 - Reland [AlwaysInliner] Update BFI when inlining

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2020-10-02T10:46:57-07:00
New Revision: eb55735073d53f7816b9a4080e6f54dfeda5ae50

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

LOG: Reland [AlwaysInliner] Update BFI when inlining

Reviewed By: davidxl

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

Added: 
llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll

Modified: 
clang/test/CodeGen/lto-newpm-pipeline.c
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
llvm/test/Transforms/Inline/prof-update-sample.ll

Removed: 




diff  --git a/clang/test/CodeGen/lto-newpm-pipeline.c 
b/clang/test/CodeGen/lto-newpm-pipeline.c
index 9694cef326d5..ad3f076e5d8b 100644
--- a/clang/test/CodeGen/lto-newpm-pipeline.c
+++ b/clang/test/CodeGen/lto-newpm-pipeline.c
@@ -28,6 +28,7 @@
 // CHECK-FULL-O0: Starting llvm::Module pass manager run.
 // CHECK-FULL-O0: Running pass: AlwaysInlinerPass
 // CHECK-FULL-O0-NEXT: Running analysis: InnerAnalysisManagerProxy
+// CHECK-FULL-O0-NEXT: Running analysis: ProfileSummaryAnalysis
 // CHECK-FULL-O0-NEXT: Running pass: CanonicalizeAliasesPass
 // CHECK-FULL-O0-NEXT: Running pass: NameAnonGlobalPass
 // CHECK-FULL-O0-NEXT: Running pass: BitcodeWriterPass
@@ -36,6 +37,7 @@
 // CHECK-THIN-O0: Starting llvm::Module pass manager run.
 // CHECK-THIN-O0: Running pass: AlwaysInlinerPass
 // CHECK-THIN-O0-NEXT: Running analysis: InnerAnalysisManagerProxy
+// CHECK-THIN-O0-NEXT: Running analysis: ProfileSummaryAnalysis
 // CHECK-THIN-O0-NEXT: Running pass: CanonicalizeAliasesPass
 // CHECK-THIN-O0-NEXT: Running pass: NameAnonGlobalPass
 // CHECK-THIN-O0-NEXT: Running pass: ThinLTOBitcodeWriterPass

diff  --git a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp 
b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
index a9cf363ec98f..f3b23ea77bcd 100644
--- a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -15,6 +15,7 @@
 #include "llvm/ADT/SetVector.h"
 #include "llvm/Analysis/AssumptionCache.h"
 #include "llvm/Analysis/InlineCost.h"
+#include "llvm/Analysis/ProfileSummaryInfo.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
@@ -39,7 +40,7 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
   auto GetAssumptionCache = [&](Function ) -> AssumptionCache & {
 return FAM.getResult(F);
   };
-  InlineFunctionInfo IFI(/*cg=*/nullptr, GetAssumptionCache);
+  auto  = MAM.getResult(M);
 
   SmallSetVector Calls;
   bool Changed = false;
@@ -67,6 +68,11 @@ PreservedAnalyses AlwaysInlinerPass::run(Module ,
 emitInlinedInto(ORE, CB->getDebugLoc(), CB->getParent(), F, *Caller,
 *OIC, false, DEBUG_TYPE);
 
+InlineFunctionInfo IFI(
+/*cg=*/nullptr, GetAssumptionCache, ,
+(*(CB->getCaller())),
+(F));
+
 InlineResult Res =
 InlineFunction(*CB, IFI, /*CalleeAAR=*/nullptr, InsertLifetime);
 assert(Res.isSuccess() && "unexpected failure to inline");

diff  --git a/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll 
b/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll
new file mode 100644
index ..5bb5834faefd
--- /dev/null
+++ b/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll
@@ -0,0 +1,60 @@
+; RUN: opt < %s -passes=always-inline -S | FileCheck %s
+; Checks if always-inline updates branch_weights annotation for call 
instructions.
+
+declare void @ext();
+declare void @ext1();
+@func = global void ()* null
+
+; CHECK: define void @callee(i32 %n) #0 !prof ![[ENTRY_COUNT:[0-9]*]]
+define void  @callee(i32 %n) #0 !prof !15 {
+  %cond = icmp sle i32 %n, 10
+  br i1 %cond, label %cond_true, label %cond_false
+cond_true:
+; ext1 is optimized away, thus not updated.
+; CHECK: call void @ext1(), !prof ![[COUNT_CALLEE1:[0-9]*]]
+  call void @ext1(), !prof !16
+  ret void
+cond_false:
+; ext is cloned and updated.
+; CHECK: call void @ext(), !prof ![[COUNT_CALLEE:[0-9]*]]
+  call void @ext(), !prof !16
+  %f = load void ()*, void ()** @func
+; CHECK: call void %f(), !prof ![[COUNT_IND_CALLEE:[0-9]*]] 
+  call void %f(), !prof !18
+  ret void
+}
+
+; CHECK: define void @caller()
+define void @caller() {
+; CHECK: call void @ext(), !prof ![[COUNT_CALLER:[0-9]*]]
+; CHECK: call void %f.i(), !prof ![[COUNT_IND_CALLER:[0-9]*]]
+  call void @callee(i32 15), !prof !17
+  ret void
+}
+
+!llvm.module.flags = !{!1}
+!1 = !{i32 1, !"ProfileSummary", !2}
+!2 = !{!3, !4, !5, !6, !7, !8, !9, !10}
+!3 = !{!"ProfileFormat", !"SampleProfile"}
+!4 = !{!"TotalCount", i64 1}
+!5 = !{!"MaxCount", i64 10}
+!6 = !{!"MaxInternalCount", i64 1}
+!7 = !{!"MaxFunctionCount", i64 2000}
+!8 = !{!"NumCounts", i64 2}
+!9 = !{!"NumFunctions", i64 2}
+!10 = 

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

jasonliu wrote:
> jasonliu wrote:
> > MaskRay wrote:
> > > From the current code. I don't see HasExplicitDataSections is necessary. 
> > > Please remove the lld changes.
> > The reason I need `HasExplicitDataSections` goes back to D88493(which I 
> > haven't land yet, because I actually need to land these two patches 
> > together to avoid build break). In D88493, I'm trying to get the llc's 
> > default for -data-sections to be correct for AIX and introduced 
> > `HasExplicitDataSections`. If `HasExplicitDataSections` is not set, then 
> > llc would think there is -data-sections set, so it would just take the 
> > target triple's default, which makes `DataSections` setting to be useless. 
> > It seems there is no good way to set a certain TargetOption's default to be 
> > dependant on the current target triple. As I already mentioned in my own 
> > comment in this patch, one of the way to achieve that could be make 
> > DataSections an enum option in TargetOptions, so that it could have a 
> > `Default` enum which could mean true or false depending on the triple 
> > setting. But it could mean a bigger refactoring to this option. 
> Correction:
> If HasExplicitDataSections is not set, then llc would think there is **no** 
> -data-sections set, so it would just take the target triple's default...
D88748


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

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

[PATCH] D36836: [clang-tidy] Implement sonarsource-function-cognitive-complexity check

[Chris Lattner via Phabricator via cfe-commits]

lattner added a comment.

Hi all,

The LLVM foundation board discussed this offline -- it looks like the 
contributor is a bit confused about the LLVM project policies towards 
copyright, license, patent stuff etc.  I really appreciate the dilligence here 
to capture the ideas that went into this code.

My understanding is that the code and documentation are not derived from anyone 
else's code or documentation -- they are fresh implementations based on a paper 
written in english prose.  If that is the case, please remove the LICENSE.TXT 
file -- it isn't necessary and it is confusing for people.I would also 
recommend replacing all the references to sonar source with a functional 
description of what this patch is doing - we aren't talking about adding a 
feature because of sonar source, my understanding is that this is adding a 
cyclomatic complexity checker.  If and when the feature evolves over time, it 
would be misleading for it to be called sonar source.

Please note that I didn't do a full code review here, others should do that.

-Chris


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36836/new/

https://reviews.llvm.org/D36836

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

[PATCH] D87972: [OldPM] Pass manager: run SROA after (simple) loop unrolling

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

>> I'm not really sure what are my potential next steps here.

Maybe just add option to disable late SROA?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87972/new/

https://reviews.llvm.org/D87972

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

[PATCH] D88745: [clangd][WIP] Add new code completion signals to improve MRR by 3%.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 created this revision.
Herald added subscribers: cfe-commits, kadircet, arphaman.
Herald added a project: clang.
usaxena95 requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

Adds two more signals.

- NumNameInContext: Strength of match of name with context.
- SemaPriority: Priority of a sema completion as given by sema.

This will potentially increase the MRR further by 3%.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88745

Files:
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/Quality.h
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json


Index: clang-tools-extra/clangd/quality/model/features.json
===
--- clang-tools-extra/clangd/quality/model/features.json
+++ clang-tools-extra/clangd/quality/model/features.json
@@ -23,6 +23,10 @@
 "name": "IsNameInContext",
 "kind": "NUMBER"
 },
+{
+"name": "NumNameInContext",
+"kind": "NUMBER"
+},
 {
 "name": "IsForbidden",
 "kind": "NUMBER"
@@ -63,6 +67,10 @@
 "name": "TypeMatchesPreferred",
 "kind": "NUMBER"
 },
+{
+"name": "SemaPriority",
+"kind": "NUMBER"
+},
 {
 "name": "SymbolCategory",
 "kind": "ENUM",
Index: clang-tools-extra/clangd/Quality.h
===
--- clang-tools-extra/clangd/Quality.h
+++ clang-tools-extra/clangd/Quality.h
@@ -140,6 +140,9 @@
   /// CompletionPrefix.
   unsigned FilterLength = 0;
 
+  /// Priority of the completion item as computed by Sema.
+  unsigned SemaPriority = 0;
+
   /// Set of derived signals computed by calculateDerivedSignals(). Must not be
   /// set explicitly.
   struct DerivedSignals {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -300,6 +300,8 @@
   SemaCCResult.Availability == CXAvailability_NotAccessible)
 Forbidden = true;
 
+  SemaPriority = SemaCCResult.Priority;
+
   if (SemaCCResult.Declaration) {
 SemaSaysInScope = true;
 // We boost things that have decls in the main file. We give a fixed score
@@ -499,6 +501,8 @@
   SymbolRelevanceSignals::DerivedSignals Derived =
   Relevance.calculateDerivedSignals();
   E.setIsNameInContext(Derived.NameMatchesContext);
+  // FIXME: Use number of matches of name in context here.
+  E.setNumNameInContext(Derived.NameMatchesContext);
   E.setIsForbidden(Relevance.Forbidden);
   E.setIsInBaseClass(Relevance.InBaseClass);
   E.setFileProximityDistance(Derived.FileProximityDistance);
@@ -512,6 +516,7 @@
   E.setHadSymbolType(Relevance.HadSymbolType);
   E.setTypeMatchesPreferred(Relevance.TypeMatchesPreferred);
   E.setFilterLength(Relevance.FilterLength);
+  E.setSemaPriority(Relevance.SemaPriority);
   return Evaluate(E);
 }
 


Index: clang-tools-extra/clangd/quality/model/features.json
===
--- clang-tools-extra/clangd/quality/model/features.json
+++ clang-tools-extra/clangd/quality/model/features.json
@@ -23,6 +23,10 @@
 "name": "IsNameInContext",
 "kind": "NUMBER"
 },
+{
+"name": "NumNameInContext",
+"kind": "NUMBER"
+},
 {
 "name": "IsForbidden",
 "kind": "NUMBER"
@@ -63,6 +67,10 @@
 "name": "TypeMatchesPreferred",
 "kind": "NUMBER"
 },
+{
+"name": "SemaPriority",
+"kind": "NUMBER"
+},
 {
 "name": "SymbolCategory",
 "kind": "ENUM",
Index: clang-tools-extra/clangd/Quality.h
===
--- clang-tools-extra/clangd/Quality.h
+++ clang-tools-extra/clangd/Quality.h
@@ -140,6 +140,9 @@
   /// CompletionPrefix.
   unsigned FilterLength = 0;
 
+  /// Priority of the completion item as computed by Sema.
+  unsigned SemaPriority = 0;
+
   /// Set of derived signals computed by calculateDerivedSignals(). Must not be
   /// set explicitly.
   struct DerivedSignals {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -300,6 +300,8 @@
   SemaCCResult.Availability == CXAvailability_NotAccessible)
 Forbidden = true;
 
+  SemaPriority = SemaCCResult.Priority;
+
   if (SemaCCResult.Declaration) {
 SemaSaysInScope = true;
 // We boost things that have decls in the main file. We give a fixed score
@@ -499,6 +501,8 @@
   SymbolRelevanceSignals::DerivedSignals Derived =
   Relevance.calculateDerivedSignals();
   E.setIsNameInContext(Derived.NameMatchesContext);
+  // FIXME: Use number of matches of name in context here.
+  

[PATCH] D87451: add new option ignore-xcoff-visibility

[David Tenty via Phabricator via cfe-commits]

daltenty added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:2622
+
+Do not emit any visibility attribute for asm on AIX or give all symbols 
'unspecified' visibility in xcoff object file(XCOFF only)
+

nit: add a space before parens



Comment at: clang/docs/ClangCommandLineReference.rst:2622
+
+Do not emit any visibility attribute for asm on AIX or give all symbols 
'unspecified' visibility in xcoff object file(XCOFF only)
+

daltenty wrote:
> nit: add a space before parens
I don't think the object file writing case was handled yet? This makes it sound 
like it is.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5242
 
+  if (const Arg *A = Args.getLastArg(options::OPT_mignore_xcoff_visibility)) {
+if (Triple.isOSAIX())

Use `Args.hasFlag` instead, since this option doesn't have a value we need to 
check.



Comment at: clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp:72
+
+// ERROR: unsupported option '-mignore-xcoff-visibility' for target 
'powerpc-unknown-linux'
+

This isn't being checked anymore, also probably belongs in the other file



Comment at: clang/test/Driver/ignore-xcoff-visibility.cpp:2
+// RUN: %clang -### -target powerpc-unknown-aix  -mignore-xcoff-visibility -S 
%s 2> %t.log
+// RUN: FileCheck -check-prefix=CHECK %s < %t.log
+// CHECK: "-mignore-xcoff-visibility"

We should check the diagnostic here



Comment at: clang/test/Driver/ignore-xcoff-visibility.cpp:3
+// RUN: FileCheck -check-prefix=CHECK %s < %t.log
+// CHECK: "-mignore-xcoff-visibility"

nit: We should constrain this to be following the cc1 invocation


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87451/new/

https://reviews.llvm.org/D87451

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

[PATCH] D87972: [OldPM] Pass manager: run SROA after (simple) loop unrolling

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D87972#2294614 , @lebedev.ri wrote:

> In D87972#2294488 , @xbolva00 wrote:
>
 Does that sound reasonable?
>>
>> Yes IMHO.
>>
 What are the next suggested steps?
>>
>> It would be great to isolate and check the cases which regressed a bit.
>
> I've rerun my benchmark, and while the results are still the same (runtime 
> geomean -0.53%/-0.40%,
> but that obviously depends on the benchmarks), there are some obvious 
> outliers:
> F13059172: image.png 
> F13059175: rsbench.txt 
> I'll try to take a look at that, assuming it's not noise.

Hmm. So i did just take a look, manually re-benchmarking each of these, and 
while i still see a few small improvements,
the regressions there are all appear to be basically noise. Not what i was 
hoping for :/

In D87972#2284060 , @MaskRay wrote:

> I have tested this patch internally and seen gains and losses. On one 
> document search related benchmark 3~5% improvement. One zippy (snappy) there 
> is 3~5% regression. Perhaps we do need a conditional extra SROA run.

Does it look like one of the scary "branch predictor got confused"/"code layout 
changed causing different alignment"?

I'm not really sure what are my potential next steps here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87972/new/

https://reviews.llvm.org/D87972

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

jasonliu wrote:
> MaskRay wrote:
> > From the current code. I don't see HasExplicitDataSections is necessary. 
> > Please remove the lld changes.
> The reason I need `HasExplicitDataSections` goes back to D88493(which I 
> haven't land yet, because I actually need to land these two patches together 
> to avoid build break). In D88493, I'm trying to get the llc's default for 
> -data-sections to be correct for AIX and introduced 
> `HasExplicitDataSections`. If `HasExplicitDataSections` is not set, then llc 
> would think there is -data-sections set, so it would just take the target 
> triple's default, which makes `DataSections` setting to be useless. 
> It seems there is no good way to set a certain TargetOption's default to be 
> dependant on the current target triple. As I already mentioned in my own 
> comment in this patch, one of the way to achieve that could be make 
> DataSections an enum option in TargetOptions, so that it could have a 
> `Default` enum which could mean true or false depending on the triple 
> setting. But it could mean a bigger refactoring to this option. 
Correction:
If HasExplicitDataSections is not set, then llc would think there is **no** 
-data-sections set, so it would just take the target triple's default...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

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

[PATCH] D74144: [OPENMP50]Add basic support for array-shaping operation.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D74144#2308796 , @cchen wrote:

> In D74144#2307494 , @ABataev wrote:
>
>> In D74144#2307454 , @cchen wrote:
>>
>>> @ABataev, the below test is extracted from Sollve test suite and Clang now 
>>> emit:
>>>
>>>   test.c:17:35: error: subscripted value is not an array or pointer
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>> ^
>>>   test.c:17:5: error: expected at least one 'to' clause or 'from' clause 
>>> specified to '#pragma omp target update'
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>>
>>> This error message came from the `ActOnOMPArraySectionExpr` which is called 
>>> inside `ParsePostfixExpressionSuffix`. The issue is that the base 
>>> expression in `ActOnOMPArraySectionExpr` looks like:
>>>
>>>   ParenExpr 0x122859be0 '' lvalue
>>>   `-OMPArrayShapingExpr 0x122859b98 '' lvalue
>>> |-IntegerLiteral 0x122859b38 'int' 5
>>> |-IntegerLiteral 0x122859b58 'int' 5
>>> `-DeclRefExpr 0x122859b78 'int *' lvalue Var 0x1228599d0 'foo' 'int *'
>>>
>>> which is not a base that we would expect in an array section expr. I've 
>>> tried relaxing the base type check in `ActOnOMPArraySectionExpr` but not 
>>> sure it's the way to go. (or should I just extract the DeclReExpr from 
>>> ArrayShapingExpr before calling `ActOnOMPArraySectionExpr`?)
>>>
>>>   #define N 5
>>>   #define M 3
>>>   
>>>   int main(void) {
>>>   int tmp[N][N];
>>>   for(int i=0; i>>   for(int j=0; j>>   tmp[i][j] = N*i + j;
>>>   
>>>   int *foo = [0][0];
>>>   
>>>   // This compiles just fine
>>>   //#pragma omp target update to( ([N][N])foo )
>>>   
>>>   // This is rejected by the compiler
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>>   }
>>
>> I don't think it is allowed by the standard.
>>
>> According to the standard, The shape-operator can appear only in clauses 
>> where it is explicitly allowed.
>> In this case, array shaping is used as a base expression of array section 
>> (or subscript) expression, which does not meet the standard. Tje array 
>> sjaping operation is not used in clause, instead it is used as a base 
>> subexpression of another expression.
>
> In OpenMP 5.0 [2.12.6, target update construct, Restrictions, C/C++, p.1] The 
> list items that appear in the to or from clauses may use shape-operators.
> Also, in the array shaping section in https://github.com/OpenMP/Examples, the 
> example is also illustrated with the same usage:
>
>   ...
>   S-17 // update boundary points (two columns of 2D array) on the host
>   S-18 // pointer is shaped to 2D array using the shape-operator
>   S-19 #pragma omp target update from( (([nx][ny+2])a)[0:nx][1], 
> (([nx][ny+2])a)[0:nx][ny] )
>   ...

Then just need to fix it, if examples document has this example.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74144/new/

https://reviews.llvm.org/D74144

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

[PATCH] D88338: [clangd] clangd --check: standalone diagnosis of common problems

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D88338#2307976 , @sammccall wrote:

> Sorry @rsmith @hoy, I've replaced the test with one without such dependencies 
> in bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb 
> .

Thanks for the quick turnaround!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88338/new/

https://reviews.llvm.org/D88338

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

[PATCH] D88377: Diagnose invalid target ID for AMDGPU toolchain for assembler

[Aaron Enye Shi via Phabricator via cfe-commits]

ashi1 accepted this revision.
ashi1 added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88377/new/

https://reviews.llvm.org/D88377

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

MaskRay wrote:
> From the current code. I don't see HasExplicitDataSections is necessary. 
> Please remove the lld changes.
The reason I need `HasExplicitDataSections` goes back to D88493(which I haven't 
land yet, because I actually need to land these two patches together to avoid 
build break). In D88493, I'm trying to get the llc's default for -data-sections 
to be correct for AIX and introduced `HasExplicitDataSections`. If 
`HasExplicitDataSections` is not set, then llc would think there is 
-data-sections set, so it would just take the target triple's default, which 
makes `DataSections` setting to be useless. 
It seems there is no good way to set a certain TargetOption's default to be 
dependant on the current target triple. As I already mentioned in my own 
comment in this patch, one of the way to achieve that could be make 
DataSections an enum option in TargetOptions, so that it could have a `Default` 
enum which could mean true or false depending on the triple setting. But it 
could mean a bigger refactoring to this option. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:41
+static bool isAllowedSystemCall(const FunctionDecl *FD) {
+  if (!FD->getIdentifier())
+return true;

balazske wrote:
> aaron.ballman wrote:
> > A function without an identifier is not a system call, so I would have 
> > expected this to return `false` based on the function name.
> I would think that if the function is an operation on a std object 
> (`std::vector`) it should be classified as system call, and these operations 
> (or many of them) look not asynchronous-safe.
Hmm, that's an interesting point I hadn't considered and I don't know what the 
correct answer is as it relates to this check. For instance, this code is bad, 
but not because of sig30-C:
```
std::vector some_global_vector;
void sig_handler(int sig) {
  int  = some_global_vector[0];
  ...
}
```
I doubt that `operator[]()` is actually making any system calls under the hood, 
so it's fine per sig30-c, but the code is still bad (it should fail sig31-c 
about not using shared objects from signals). On the flip side:
```
std::packaged_task some_task;
void sig_handler(int sig) {
  some_task(sig); // Who knows what this will execute when it calls operator()()
}
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87449/new/

https://reviews.llvm.org/D87449

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:27
+  // Find a possible redeclaration in system header.
+  for (const FunctionDecl *D : FD->redecls())
+if (FD->getASTContext().getSourceManager().isInSystemHeader(

```
return llvm::any_of(FD->redecls(), [](const FunctionDecl *D) {
  return 
D->getASTContext().getSourceManager().isInSystemHeader(D->getLocation());
});
```



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:117-118
+FunctionCallCollector Collector{[](const CallExpr *CE) {
+  if (isa(CE->getCalleeDecl()))
+CalledFunctions.push_back(CE);
+}};

For correctness, I think you need to handle more than just calls to function 
declarations -- for instance, this should be just as problematic:
```
void some_signal_handler(int sig) {
  []{ puts("this should not be an escape hatch for the check); }();
}
```
even though the call expression in the signal handler doesn't resolve back to a 
function declaration. (Similar for blocks instead of lambdas.) WDYT?



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:134
+// At insertion we have already ensured that only function calls are there.
+const FunctionDecl *F = cast(FunctionCall->getCalleeDecl());
+

`const auto *`



Comment at: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp:52
+void test() {
+  std::signal(SIGINT, handler_abort);
+  std::signal(SIGINT, handler__Exit);

I'd also like to see a test case where the handler to `signal` call is itself 
not a function call:
```
std::signal(SIGINT, [](int sig) {
  puts("I did the bad thing this way"); // should be diagnosed, yes?
});
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87449/new/

https://reviews.llvm.org/D87449

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

[PATCH] D74144: [OPENMP50]Add basic support for array-shaping operation.

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D74144#2307494 , @ABataev wrote:

> In D74144#2307454 , @cchen wrote:
>
>> @ABataev, the below test is extracted from Sollve test suite and Clang now 
>> emit:
>>
>>   test.c:17:35: error: subscripted value is not an array or pointer
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>> ^
>>   test.c:17:5: error: expected at least one 'to' clause or 'from' clause 
>> specified to '#pragma omp target update'
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>
>> This error message came from the `ActOnOMPArraySectionExpr` which is called 
>> inside `ParsePostfixExpressionSuffix`. The issue is that the base expression 
>> in `ActOnOMPArraySectionExpr` looks like:
>>
>>   ParenExpr 0x122859be0 '' lvalue
>>   `-OMPArrayShapingExpr 0x122859b98 '' lvalue
>> |-IntegerLiteral 0x122859b38 'int' 5
>> |-IntegerLiteral 0x122859b58 'int' 5
>> `-DeclRefExpr 0x122859b78 'int *' lvalue Var 0x1228599d0 'foo' 'int *'
>>
>> which is not a base that we would expect in an array section expr. I've 
>> tried relaxing the base type check in `ActOnOMPArraySectionExpr` but not 
>> sure it's the way to go. (or should I just extract the DeclReExpr from 
>> ArrayShapingExpr before calling `ActOnOMPArraySectionExpr`?)
>>
>>   #define N 5
>>   #define M 3
>>   
>>   int main(void) {
>>   int tmp[N][N];
>>   for(int i=0; i>   for(int j=0; j>   tmp[i][j] = N*i + j;
>>   
>>   int *foo = [0][0];
>>   
>>   // This compiles just fine
>>   //#pragma omp target update to( ([N][N])foo )
>>   
>>   // This is rejected by the compiler
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>   }
>
> I don't think it is allowed by the standard.
>
> According to the standard, The shape-operator can appear only in clauses 
> where it is explicitly allowed.
> In this case, array shaping is used as a base expression of array section (or 
> subscript) expression, which does not meet the standard. Tje array sjaping 
> operation is not used in clause, instead it is used as a base subexpression 
> of another expression.

In OpenMP 5.0 [2.12.6, target update construct, Restrictions, C/C++, p.1] The 
list items that appear in the to or from clauses may use shape-operators.
Also, in the array shaping section in https://github.com/OpenMP/Examples, the 
example is also illustrated with the same usage:

  ...
  S-17 // update boundary points (two columns of 2D array) on the host
  S-18 // pointer is shaped to 2D array using the shape-operator
  S-19 #pragma omp target update from( (([nx][ny+2])a)[0:nx][1], 
(([nx][ny+2])a)[0:nx][ny] )
  ...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74144/new/

https://reviews.llvm.org/D74144

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

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdb2a646c5f00: [clangd] Add bencmark for measuring latency of 
DecisionForest model. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88590/new/

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example  : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State ) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] db2a646 - [clangd] Add bencmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via cfe-commits]

Author: Utkarsh Saxena
Date: 2020-10-02T18:04:31+02:00
New Revision: db2a646c5f002cc16d02d6fac0b2d715cdd4a809

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

LOG: [clangd] Add bencmark for measuring latency of DecisionForest model.

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

Added: 
clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt

clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Modified: 
clang-tools-extra/clangd/benchmarks/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/benchmarks/CMakeLists.txt 
b/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
index 1f3d88b42bce..b62ffd7a1ad1 100644
--- a/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ b/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark

diff  --git 
a/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
new file mode 100644
index ..3998aa122533
--- /dev/null
+++ b/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )

diff  --git 
a/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
new file mode 100644
index ..69ce65e08b77
--- /dev/null
+++ 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//
tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example  : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State ) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

balazske marked 9 inline comments as done.
balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > balazske wrote:
> > > > aaron.ballman wrote:
> > > > > I'm not certain I understand why we're looking through the entire 
> > > > > redeclaration chain to see if the function is ever mentioned in a 
> > > > > system header. I was expecting we'd look at the expansion location of 
> > > > > the declaration and see if that's in a system header, which is 
> > > > > already handled by the `isExpansionInSystemHeader()` matcher. Similar 
> > > > > below.
> > > > This function is called from ` SignalHandlerCheck::check` when any 
> > > > function call is found. So the check for system header is needed. It 
> > > > was unclear to me what the "expansion location" means but it seems to 
> > > > work if using that expansion location and checking for system header, 
> > > > instead of this loop. I will update the code.
> > > > This function is called from  SignalHandlerCheck::check when any 
> > > > function call is found. So the check for system header is needed. 
> > > 
> > > The check for the system header isn't what I was concerned by, it was the 
> > > fact that we're walking the entire redeclaration chain to see if *any* 
> > > declaration is in a system header that I don't understand the purpose of.
> > > 
> > > > It was unclear to me what the "expansion location" means but it seems 
> > > > to work if using that expansion location and checking for system 
> > > > header, instead of this loop. I will update the code.
> > > 
> > > The spelling location is where the user wrote the code and the expansion 
> > > location is where the macro name is written, but thinking on it harder, 
> > > that shouldn't matter for this situation as either location would be in 
> > > the system header anyway.
> > The function declaration is not often a macro name so there is no 
> > "expansion location" or the same as the original location. My concern was 
> > that if there is a declaration of system call function in a source file 
> > (like `void abort(void);` in .c file) for any reason, we may find this 
> > declaration instead of the one in the header file, if not looping over the 
> > declaration chain.
> > The function declaration is not often a macro name so there is no 
> > "expansion location" or the same as the original location.
> 
> Agreed.
> 
> > My concern was that if there is a declaration of system call function in a 
> > source file (like `void abort(void);` in .c file) for any reason, we may 
> > find this declaration instead of the one in the header file, if not looping 
> > over the declaration chain.
> 
> Typically, when a C user does something like that, it's because they're 
> explicitly *not* including the header file at all (they're just forward 
> declaring the function so they can use it) and so we'd get the logic wrong 
> for them anyway because we'd never find the declaration in the system header.
> 
> Using the canonical declaration is more typical and would realistically fail 
> only in circumstances like forward declaring a system header function and 
> then later including the system header itself. That said, I suppose your 
> approach is defensible enough. Redeclaration chains are hopefully short 
> enough that it isn't a performance hit.
I changed back to the original code to search the entire redeclaration chain. 
Otherwise it can be fooled with declarations before or after inclusion of the 
system header. Such declarations were added to the test file (it did not pass 
if `isExpansionInSystemHeader` was used).



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:41
+static bool isAllowedSystemCall(const FunctionDecl *FD) {
+  if (!FD->getIdentifier())
+return true;

aaron.ballman wrote:
> A function without an identifier is not a system call, so I would have 
> expected this to return `false` based on the function name.
I would think that if the function is an operation on a std object 
(`std::vector`) it should be classified as system call, and these operations 
(or many of them) look not asynchronous-safe.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:13
+(for ``signal`` there are additional conditions that are not checked).
+Every other system call is considered as non asynchronous-safe by the checker.
+

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > I would document this as: `Any function that cannot be determined to be 
> > > an asynchronous-safe function call is assumed to be non-asynchronous-safe 
> > > by the checker, including function calls for which only the declaration 
> > > of the called 

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

balazske updated this revision to Diff 295840.
balazske added a comment.

Updated check for system function.
Updated documentation.
Added more test cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87449/new/

https://reviews.llvm.org/D87449

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/cert-sig30-c_cpp.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
  clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
  clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+
+#include "cert-sig30-c_cpp.h"
+#include "stdio.h"
+
+void handler_abort(int) {
+  std::abort();
+}
+
+void handler__Exit(int) {
+  std::_Exit(0);
+}
+
+void handler_quick_exit(int) {
+  std::quick_exit(0);
+}
+
+void handler_bad1(int) {
+  std::something(1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'something' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_bad2(int) {
+  std::SysStruct S;
+  S << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'operator<<' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  std::signal(0, SIG_DFL);
+  std::signal(0, SIG_IGN);
+}
+
+void handler_nowarn(int) {
+  std::something(2);
+}
+
+// Function called "signal" that is not to be recognized by the checker.
+typedef void (*callback_t)(int);
+void signal(int, callback_t, int);
+
+namespace ns {
+void signal(int, callback_t);
+}
+
+struct S {
+  static void signal(int, callback_t);
+};
+
+void test() {
+  std::signal(SIGINT, handler_abort);
+  std::signal(SIGINT, handler__Exit);
+  std::signal(SIGINT, handler_quick_exit);
+  std::signal(SIGINT, handler_signal);
+  std::signal(SIGINT, handler_bad1);
+  std::signal(SIGINT, handler_bad2);
+
+  // Do not find problems here.
+  signal(SIGINT, handler_nowarn, 1);
+  ns::signal(SIGINT, handler_nowarn);
+  S::signal(SIGINT, handler_nowarn);
+  system_other::signal(SIGINT, handler_nowarn);
+}
Index: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
@@ -0,0 +1,81 @@
+// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+
+// The function should be classified as system call even if there is a
+// declaration before or after the one in a system header.
+int printf(const char *, ...);
+
+typedef void (*sighandler_t)(int);
+sighandler_t signal(int signum, sighandler_t handler);
+
+#include "signal.h"
+#include "stdio.h"
+#include "stdlib.h"
+
+int printf(const char *, ...);
+
+sighandler_t signal(int signum, sighandler_t handler);
+
+void handler_abort(int) {
+  abort();
+}
+
+void handler__Exit(int) {
+  _Exit(0);
+}
+
+void handler_quick_exit(int) {
+  quick_exit(0);
+}
+
+void handler_other(int) {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  signal(0, SIG_DFL);
+}
+
+void f_ok() {
+  abort();
+}
+
+void f_bad() {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void f_extern();
+
+void handler_ok(int) {
+  f_ok();
+}
+
+void handler_bad(int) {
+  f_bad();
+}
+
+void handler_extern(int) {
+  f_extern();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void test() {
+  signal(SIGINT, handler_abort);
+  signal(SIGINT, handler__Exit);
+  signal(SIGINT, handler_quick_exit);
+  signal(SIGINT, handler_signal);
+  signal(SIGINT, handler_other);
+
+  signal(SIGINT, handler_ok);
+  signal(SIGINT, handler_bad);
+  signal(SIGINT, handler_extern);
+
+  signal(SIGINT, quick_exit);
+  signal(SIGINT, other_call);
+  // CHECK-MESSAGES: 

[PATCH] D87451: add new option ignore-xcoff-visibility

[Digger via Phabricator via cfe-commits]

DiggerLin updated this revision to Diff 295838.
DiggerLin marked an inline comment as done.
DiggerLin added a comment.

address comment and merger the patch https://reviews.llvm.org/D88234 into the 
patch


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87451/new/

https://reviews.llvm.org/D87451

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
  clang/test/Driver/ignore-xcoff-visibility.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetMachine.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll

Index: llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll
@@ -0,0 +1,48 @@
+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec  < %s | \
+; RUN:   FileCheck --check-prefix=VISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec -ignore-xcoff-visibility < %s | \
+; RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec < %s | \
+; RUN:   FileCheck --check-prefix=VISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec -ignore-xcoff-visibility < %s | \
+; RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
+
+@foo_p = global void ()* @zoo_extern_h, align 4
+@b = protected global i32 0, align 4
+
+define hidden void @foo_h(i32* %p) {
+entry:
+  %p.addr = alloca i32*, align 4
+  store i32* %p, i32** %p.addr, align 4
+  %0 = load i32*, i32** %p.addr, align 4
+  %1 = load i32, i32* %0, align 4
+  %inc = add nsw i32 %1, 1
+  store i32 %inc, i32* %0, align 4
+  ret void
+}
+
+declare hidden void @zoo_extern_h()
+
+define protected void @bar() {
+entry:
+  call void @foo_h(i32* @b)
+  %0 = load void ()*, void ()** @foo_p, align 4
+  call void %0()
+  ret void
+}
+
+; VISIBILITY-ASM: .globl  foo_h[DS],hidden
+; VISIBILITY-ASM: .globl  .foo_h,hidden
+; VISIBILITY-ASM: .globl  bar[DS],protected
+; VISIBILITY-ASM: .globl  .bar,protected
+; VISIBILITY-ASM: .globl  b,protected
+
+; IGNOREVISIBILITY-ASM: .globl  foo_h[DS]
+; IGNOREVISIBILITY-ASM: .globl  .foo_h
+; IGNOREVISIBILITY-ASM: .globl  bar[DS]
+; IGNOREVISIBILITY-ASM: .globl  .bar
+; IGNOREVISIBILITY-ASM: .globl  b
Index: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
===
--- llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
+++ llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
@@ -1702,17 +1702,19 @@
   assert(LinkageAttr != MCSA_Invalid && "LinkageAttr should not MCSA_Invalid.");
 
   MCSymbolAttr VisibilityAttr = MCSA_Invalid;
-  switch (GV->getVisibility()) {
+  if (!TM.getIgnoreXCOFFVisibility()) {
+switch (GV->getVisibility()) {
 
-  // TODO: "exported" and "internal" Visibility needs to go here.
-  case GlobalValue::DefaultVisibility:
-break;
-  case GlobalValue::HiddenVisibility:
-VisibilityAttr = MAI->getHiddenVisibilityAttr();
-break;
-  case GlobalValue::ProtectedVisibility:
-VisibilityAttr = MAI->getProtectedVisibilityAttr();
-break;
+// TODO: "exported" and "internal" Visibility needs to go here.
+case GlobalValue::DefaultVisibility:
+  break;
+case GlobalValue::HiddenVisibility:
+  VisibilityAttr = MAI->getHiddenVisibilityAttr();
+  break;
+case GlobalValue::ProtectedVisibility:
+  VisibilityAttr = MAI->getProtectedVisibilityAttr();
+  break;
+}
   }
 
   OutStreamer->emitXCOFFSymbolLinkageWithVisibility(GVSym, LinkageAttr,
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -74,6 +74,7 @@
 CGOPT(bool, RelaxELFRelocations)
 CGOPT_EXP(bool, DataSections)
 CGOPT_EXP(bool, FunctionSections)
+CGOPT(bool, IgnoreXCOFFVisibility)
 CGOPT(std::string, BBSections)
 CGOPT(unsigned, TLSSize)
 CGOPT(bool, EmulatedTLS)
@@ -333,6 +334,13 @@
   cl::init(false));
   CGBINDOPT(FunctionSections);
 
+  static cl::opt IgnoreXCOFFVisibility(
+  "ignore-xcoff-visibility",
+  cl::desc("Not emit the visibility attribute for asm in AIX OS or give "
+   "all symbols 'unspecified' visibility in xcoff object file"),
+  cl::init(false));
+  CGBINDOPT(IgnoreXCOFFVisibility);
+
   static cl::opt BBSections(
   

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 added inline comments.



Comment at: 
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp:74
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();

adamcz wrote:
> Move this out of the loop. Right now we re-generate "random" dataset, but 
> it's always the same dataset ;-)
I added it inside the loop since there is only one state right now. But 
probably moving it out makes it more meaningful.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88590/new/

https://reviews.llvm.org/D88590

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

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 295837.
usaxena95 marked an inline comment as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88590/new/

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example  : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State ) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd updated this revision to Diff 295835.
compnerd added a comment.

Update text based on feedback.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

Files:
  clang/docs/APINotes.rst
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
  clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes

Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
@@ -0,0 +1,15 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector: "privateTransform:input:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+Properties:
+  - Name: internalProperty
+Nullability: N
+Protocols:
+  - Name: InternalProtocol
+Availability: none
+AvailabilityMsg: "not for you"
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
@@ -0,0 +1,4 @@
+@interface A(ExplicitNullabilityProperties)
+@property (nonatomic, readwrite, retain, nonnull) A *explicitNonnullInstance;
+@property (nonatomic, readwrite, retain, nullable) A *explicitNullableInstance;
+@end
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
@@ -0,0 +1,60 @@
+#ifndef SOMEKIT_H
+#define SOMEKIT_H
+
+__attribute__((objc_root_class))
+@interface A
+-(A*)transform:(A*)input;
+-(A*)transform:(A*)input integer:(int)integer;
+
+@property (nonatomic, readonly, retain) A* someA;
+@property (nonatomic, retain) A* someOtherA;
+
+@property (nonatomic) int intValue;
+@end
+
+@interface B : A
+@end
+
+@interface C : A
+- (instancetype)init;
+- (instancetype)initWithA:(A*)a;
+@end
+
+@interface ProcessInfo : A
++(instancetype)processInfo;
+@end
+
+@interface A(NonNullProperties)
+@property (nonatomic, readwrite, retain) A *nonnullAInstance;
+@property (class, nonatomic, readwrite, retain) A *nonnullAInstance;
+
+@property (nonatomic, readwrite, retain) A *nonnullAClass;
+@property (class, nonatomic, readwrite, retain) A *nonnullAClass;
+
+@property (nonatomic, readwrite, retain) A *nonnullABoth;
+@property (class, nonatomic, readwrite, retain) A *nonnullABoth;
+@end
+
+#import 
+
+extern int *global_int_ptr;
+
+int *global_int_fun(int *ptr, int *ptr2);
+
+#define SOMEKIT_DOUBLE double
+
+__attribute__((objc_root_class))
+@interface OverriddenTypes
+-(int *)methodToMangle:(int *)ptr1 second:(int *)ptr2;
+@property int *intPropertyToMangle;
+@end
+
+@interface A(ImplicitGetterSetters)
+@property (nonatomic, readonly, retain) A *implicitGetOnlyInstance;
+@property (class, nonatomic, readonly, retain) A *implicitGetOnlyClass;
+
+@property (nonatomic, readwrite, retain) A *implicitGetSetInstance;
+@property (class, nonatomic, readwrite, retain) A *implicitGetSetClass;
+@end
+
+#endif
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
@@ -0,0 +1,98 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector:"transform:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "anything but this"
+  - Selector: "transform:integer:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+  - Selector: "implicitGetOnlyInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetOnlyClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "setImplicitGetSetInstance:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "setter gone"
+  - Selector: "setImplicitGetSetClass:"
+

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Fangrui Song via Phabricator via cfe-commits]

MaskRay requested changes to this revision.
MaskRay added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

From the current code. I don't see HasExplicitDataSections is necessary. Please 
remove the lld changes.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4915
+  CmdArgs.push_back("-fno-data-sections");
+  } else if (UseSeparateSections) {
 CmdArgs.push_back("-fdata-sections");

You can place AIX in isUseSeparateSections instead.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:994
 
+  if (Args.getLastArg(OPT_fdata_sections) ||
+  Args.getLastArg(OPT_fno_data_sections)) {

In many cases, there is no need for having both positive and negative CC1 
options. The driver handles the default.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

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

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd marked an inline comment as done.
compnerd added inline comments.



Comment at: clang/docs/APINotes.rst:216
+Due to a compiler bug, 'NullabilityOfRet' may change nullability of the
+parameters as well (rdar://30544062). Avoid using it and instead use
+'ResultType' and specify the return type along with a nullability

hlopko wrote:
> Could we get more context from the Apple bug tracker? Depending on the 
> details it might be reasonable to drop NullabilityOfRet attribute completely, 
> or more precisely document when it should be used.
The bug is that Nullability and Type on Parameters entries don’t really 
compose. Consider the following note:

```
  NullabilityOfRet: N
  Parameters:
  - Position: 1
Nullability: O
Type: 'NSDictionary *'
```

on a method: this parameter won’t be treated as optional. Effectively, you need 
to write the _Nullable on the type because the Nullability entry is ignored.

I think that fixing this later is preferable rather than earlier to ensure that 
we at least have a unified starting point where clang and Swift can co-evolve.  
If we try to do that while upstreaming, it will make everything far more 
difficult because you have to coordinate over multiple (3+) repositories.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88446/new/

https://reviews.llvm.org/D88446

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

[PATCH] D87256: [clangd] Avoid relations being overwritten in a header shard

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Sorry, I had a response to that comment but accidentally left it as 
unsubmitted...




Comment at: clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp:232
 
+TEST_F(BackgroundIndexTest, RelationsMultiFile) {
+  MockFS FS;

kadircet wrote:
> do we still need this test?
I think it's still useful, yes. If someone makes a change to the way relations 
are stored in the future, they could regress this use case without a test 
specifically for it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87256/new/

https://reviews.llvm.org/D87256

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

[PATCH] D72218: [clang-tidy] new altera kernel name restriction check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp:90
+Check.diag(SM.getLocForStartOfFile(SM.getMainFileID()),
+   "Naming your OpenCL kernel source file 'kernel.cl', 
'Verilog.cl'"
+   ", or 'VHDL.cl' could cause compilation errors.");

aaron.ballman wrote:
> Similar here, I would word it something like: `compiling a source file named 
> '%0' may result in additional compilation errors due to the name of the file; 
> consider renaming the source file`
The diagnostic here doesn't look quite right. This is the case where the source 
compiland is named poorly, but the diagnostic is talking about including files. 
It looks like there's test coverage missing for this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72218/new/

https://reviews.llvm.org/D72218

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

[PATCH] D87451: add new option ignore-xcoff-visibility

[Digger via Phabricator via cfe-commits]

DiggerLin marked 5 inline comments as done.
DiggerLin added inline comments.



Comment at: clang/test/CodeGen/aix-no-xcoff-visibility.cpp:75
+
+// VISIBILITY-IR:@b = protected global i32 0
+// VISIBILITY-IR:@pramb = hidden global i32 0

jasonliu wrote:
> Not sure if the IR check is really necessary, since we haven't made any IR 
> change here. It's going to be all the same with or without the new -m option. 
IR output will not change in the new option. I think we need to check whether 
the IR be changed in the new option 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87451/new/

https://reviews.llvm.org/D87451

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

[clang] c87c017 - Fix failure in test hip-macros.hip

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T10:33:32-04:00
New Revision: c87c017a4c47c47b002b9f55f25285298cd07093

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

LOG: Fix failure in test hip-macros.hip

requires amdgpu-registered-target.

Added: 


Modified: 
clang/test/Driver/hip-macros.hip

Removed: 




diff  --git a/clang/test/Driver/hip-macros.hip 
b/clang/test/Driver/hip-macros.hip
index 00dcca17a08a..3105c25b8b9d 100644
--- a/clang/test/Driver/hip-macros.hip
+++ b/clang/test/Driver/hip-macros.hip
@@ -1,3 +1,4 @@
+// REQUIRES: clang-driver, amdgpu-registered-target
 // RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
 // RUN:   --cuda-device-only -nogpuinc -nogpulib \
 // RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s



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

[PATCH] D88680: Add ability to turn off -fpch-instantiate-templates in clang-cl

[Zachary Henkel via Phabricator via cfe-commits]

zahen added a comment.

This patch doesn't need a test case outside of the one that @rnk requested to 
make sure that the flag flows from the clang-cl driver appropriately.  
`pch-instantiate-templates` as authored doesn't match cl.exe behavior and being 
unable to turn it off will prevent our adoption of clang 11.  This is a release 
blocking issue at least for 11.1 if not 11.0 (I leave it to @hans to make the 
decision).  I suspect there are other users that will run into the same problem 
we have.

Of course we'll continue to work on a reduced repro to understand where the 
feature and msvc diverge but that will be a follow up patch or new bug.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88680/new/

https://reviews.llvm.org/D88680

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added a comment.

Not sure if there is a better way to do this. But I have to admit this approach 
along with D88493  is a bit fragile. 
If plug-in writer forgets to set `HasExplicitDataSections` to true, then the 
final result that TargetMachine give for `getDataSections()` could be false on 
most platform even when they deliberately set `DataSections` to true.
We have other targets in LLVM that have -fdata-sections by default as well. And 
they do it differently as well, which makes this a bit more complicate to be 
consistent. 
For example, cloudABI would pass -fdata-sections through the Clang Driver by 
default. But that approach means if some user just invoke llc directly, they 
could get the wrong default on llc for that platform. 
Wasm would just overwrite the `DataSections` option to true in their 
TargetMachine. But that means you could not set it to false even if you want to.
I've thought about making the `DataSections` option in TargetOptions an enum 
instead of boolean value, where you could have `Default`, `On` and `Off` to 
represent what we actually want for the options. That's not a trivial change, 
as a lot of consumers for TargetOptions are relying it to be a boolean.
If you think it's a better way to solve this problem and I should explore, let 
me know.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88737/new/

https://reviews.llvm.org/D88737

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

[PATCH] D88370: Emit predefined macro for wavefront size for amdgcn

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG36501b180a4f: Emit predefined macro for wavefront size for 
amdgcn (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88370/new/

https://reviews.llvm.org/D88370

Files:
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/amdgpu-features.c
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/hip-macros.hip
  clang/test/Driver/hip-toolchain-features.hip

Index: clang/test/Driver/hip-toolchain-features.hip
===
--- clang/test/Driver/hip-toolchain-features.hip
+++ clang/test/Driver/hip-toolchain-features.hip
@@ -37,8 +37,17 @@
 // RUN:   -mcumode -mcumode -mno-cumode -mwavefrontsize64 -mcumode \
 // RUN:   -mwavefrontsize64 -mno-wavefrontsize64 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DUP
-// DUP: {{.*}}clang{{.*}} "-target-feature" "-wavefrontsize16"
-// DUP-SAME: "-target-feature" "+wavefrontsize32"
-// DUP-SAME: "-target-feature" "-wavefrontsize64"
-// DUP-SAME: "-target-feature" "+cumode"
-// DUP: {{.*}}lld{{.*}} "-plugin-opt=-mattr=-wavefrontsize16,+wavefrontsize32,-wavefrontsize64,+cumode"
+// DUP: {{.*}}clang{{.*}} "-target-feature" "+cumode"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize16"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize32"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize64"
+// DUP: {{.*}}lld{{.*}} "-plugin-opt=-mattr=+cumode"
+
+// RUN: %clang -### -target x86_64-linux-gnu -fgpu-rdc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx1010 %s \
+// RUN:   -mno-wavefrontsize64 -mwavefrontsize64 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=WAVE64
+// WAVE64: {{.*}}clang{{.*}} "-target-feature" "+wavefrontsize64"
+// WAVE64-NOT: "-target-feature" "{{.*}}wavefrontsize16"
+// WAVE64-NOT: "-target-feature" "{{.*}}wavefrontsize32"
+// WAVE64: {{.*}}lld{{.*}} "-plugin-opt=-mattr=+wavefrontsize64"
Index: clang/test/Driver/hip-macros.hip
===
--- /dev/null
+++ clang/test/Driver/hip-macros.hip
@@ -0,0 +1,20 @@
+// RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE32 %s
+// RUN: %clang -E -dM --offload-arch=gfx906 -mno-wavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mwavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mno-wavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mwavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// WAVE64-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// WAVE32-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
Index: clang/test/Driver/amdgpu-macros.cl
===
--- clang/test/Driver/amdgpu-macros.cl
+++ clang/test/Driver/amdgpu-macros.cl
@@ -346,4 +346,42 @@
 // GFX1011-DAG: #define __amdgcn_processor__ "gfx1011"
 // GFX1012-DAG: #define __amdgcn_processor__ "gfx1012"
 // GFX1030-DAG: #define __amdgcn_processor__ "gfx1030"
-// GFX1031-DAG: #define __amdgcn_processor__ "gfx1031"
\ No newline at end of file
+// GFX1031-DAG: #define __amdgcn_processor__ "gfx1031"
+
+// GFX600-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX601-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX700-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX701-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX702-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX703-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX704-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX801-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX802-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX803-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX810-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX900-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX902-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX904-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX906-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX908-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX909-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX1010-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
+// GFX1011-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
+// 

[clang] 36501b1 - Emit predefined macro for wavefront size for amdgcn

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T10:17:21-04:00
New Revision: 36501b180a4f0194f0cfb4374d096ae660182827

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

LOG: Emit predefined macro for wavefront size for amdgcn

Also fix the issue of multiple -m[no-]wavefrontsize64
options to make the last one wins.

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

Added: 
clang/test/Driver/hip-macros.hip

Modified: 
clang/lib/Basic/Targets/AMDGPU.cpp
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/test/Driver/amdgpu-features.c
clang/test/Driver/amdgpu-macros.cl
clang/test/Driver/hip-toolchain-features.hip

Removed: 




diff  --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index da25bf10ca07..ba9be72af971 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -316,6 +316,7 @@ AMDGPUTargetInfo::AMDGPUTargetInfo(const llvm::Triple 
,
 
   HasLegalHalfType = true;
   HasFloat16 = true;
+  WavefrontSize = GPUFeatures & llvm::AMDGPU::FEATURE_WAVE32 ? 32 : 64;
 
   // Set pointer width and alignment for target address space 0.
   PointerWidth = PointerAlign = DataLayout->getPointerSizeInBits();
@@ -388,6 +389,8 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
,
 Builder.defineMacro("__HAS_FP64__");
   if (hasFastFMA())
 Builder.defineMacro("FP_FAST_FMA");
+
+  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE", Twine(WavefrontSize));
 }
 
 void AMDGPUTargetInfo::setAuxTarget(const TargetInfo *Aux) {

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 1f2fc081ae9d..a0e4c19f4fea 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -41,6 +41,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : public 
TargetInfo {
 
   llvm::AMDGPU::GPUKind GPUKind;
   unsigned GPUFeatures;
+  unsigned WavefrontSize;
 
   /// Target ID is device name followed by optional feature name postfixed
   /// by plus or minus sign delimitted by colon, e.g. gfx908:xnack+:sram-ecc-.
@@ -407,6 +408,8 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
 getAllPossibleTargetIDFeatures(getTriple(), 
getArchNameAMDGCN(GPUKind));
 llvm::for_each(Features, [&](const auto ) {
   assert(F.front() == '+' || F.front() == '-');
+  if (F == "+wavefrontsize64")
+WavefrontSize = 64;
   bool IsOn = F.front() == '+';
   StringRef Name = StringRef(F).drop_front();
   if (llvm::find(TargetIDFeatures, Name) == TargetIDFeatures.end())

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 61254e3eeaef..656de9dd9e1e 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -390,16 +390,9 @@ void amdgpu::getAMDGPUTargetFeatures(const Driver ,
 }
   }
 
-  if (Args.getLastArg(options::OPT_mwavefrontsize64)) {
-Features.push_back("-wavefrontsize16");
-Features.push_back("-wavefrontsize32");
+  if (Args.hasFlag(options::OPT_mwavefrontsize64,
+   options::OPT_mno_wavefrontsize64, false))
 Features.push_back("+wavefrontsize64");
-  }
-  if (Args.getLastArg(options::OPT_mno_wavefrontsize64)) {
-Features.push_back("-wavefrontsize16");
-Features.push_back("+wavefrontsize32");
-Features.push_back("-wavefrontsize64");
-  }
 
   handleTargetFeaturesGroup(
 Args, Features, options::OPT_m_amdgpu_Features_Group);

diff  --git a/clang/test/Driver/amdgpu-features.c 
b/clang/test/Driver/amdgpu-features.c
index b97a98b90f7d..71fd63715e00 100644
--- a/clang/test/Driver/amdgpu-features.c
+++ b/clang/test/Driver/amdgpu-features.c
@@ -25,10 +25,16 @@
 // NO-SRAM-ECC: "-target-feature" "-sram-ecc"
 
 // RUN: %clang -### -target amdgcn-amdpal -mcpu=gfx1010 -mwavefrontsize64 %s 
2>&1 | FileCheck --check-prefix=WAVE64 %s
-// WAVE64: "-target-feature" "-wavefrontsize16" "-target-feature" 
"-wavefrontsize32" "-target-feature" "+wavefrontsize64"
+// RUN: %clang -### -target amdgcn-amdpal -mcpu=gfx1010 -mno-wavefrontsize64 
-mwavefrontsize64 %s 2>&1 | FileCheck --check-prefix=WAVE64 %s
+// WAVE64: "-target-feature" "+wavefrontsize64"
+// WAVE64-NOT: {{".*wavefrontsize16"}}
+// WAVE64-NOT: {{".*wavefrontsize32"}}
 
 // RUN: %clang -### -target amdgcn -mcpu=gfx1010 -mno-wavefrontsize64 %s 2>&1 
| FileCheck --check-prefix=NO-WAVE64 %s
-// NO-WAVE64: "-target-feature" "-wavefrontsize16" "-target-feature" 
"+wavefrontsize32" "-target-feature" "-wavefrontsize64"
+// RUN: %clang -### -target amdgcn -mcpu=gfx1010 -mwavefrontsize64 
-mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefix=NO-WAVE64 %s
+// NO-WAVE64-NOT: {{".*wavefrontsize16"}}
+// NO-WAVE64-NOT: 

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp:25
+// RUN: {key: readability-identifier-naming.FunctionCase   , value: 
CamelCase },   \
+// RUN: {key: readability-identifier-naming.ClassCase  , value: 
szHungarianNotation }, \
+// RUN: {key: readability-identifier-naming.TypedefCase, value: 
szHungarianNotation }, \

dougpuob wrote:
> njames93 wrote:
> > Class names shouldn't use hungarian notation.
> OK~ I have classified CheckOptions, and all test cases one by one in the next 
> diff.
> 
> ```
> // RUN:   -config='{ CheckOptions: [ \
> // RUN: { key: readability-identifier-naming.ClassMemberCase  
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantMemberCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantParameterCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantPointerParameterCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstexprVariableCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalConstantCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalConstantPointerCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalVariableCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalConstantCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalConstantPointerCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalPointerCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalVariableCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.MemberCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ParameterCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.PointerParameterCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.PrivateMemberCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StaticConstantCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StaticVariableCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StructCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.UnionCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.VariableCase 
> , value: szHungarianNotation }  \
> // RUN:   ]}'
> ```
> Class names shouldn't use hungarian notation.

That may be debatable as I've definitely seen `C` used as a prefix for class 
names and `I` used as a prefix for pure virtual class names (interfaces). Doing 
a quick search on Google brings up evidence that this isn't uncommon.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86671/new/

https://reviews.llvm.org/D86671

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

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/test/SemaCUDA/device-var-init.cu:404
 __host__ __device__ void hd_sema() {
   static int x = 42;
 }

tra wrote:
> yaxunl wrote:
> > how does this work in device compilation? Is this equivalent to `static 
> > __device__ int x = 42`?
> Correct. 
so static variable without `__device__/__constant__` attribute in host device 
function implies `__device__` attribute in device compilation.

Is this also true in device function? We need Sema and CodeGen tests for these 
cases.

Also, can we document these changes? It is easily forgotten.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88345/new/

https://reviews.llvm.org/D88345

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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0f0cbcc4b166: [clangd] Extend the rename API. (authored by 
hokein).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88634/new/

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer , PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer , PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions );
+llvm::Expected runRename(ClangdServer , PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions );
+
+llvm::Expected
+runPrepareRename(ClangdServer , PathRef File, Position Pos,
+ const clangd::RenameOptions );
 
 llvm::Expected
 runFormatFile(ClangdServer , PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer , PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions ) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer , PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions ) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer ,
+  PathRef File, Position Pos,
+  const RenameOptions ) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer , PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,9 +502,10 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
-expectedResult(Code, NewName));
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(
+  applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
+  expectedResult(Code, NewName));
 }
   }
 }
@@ -653,8 +654,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(Results->GlobalChanges)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +684,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +704,44 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  Annotations FooH("void func();");
+  Annotations FooCC(R"cpp(
+#include "foo.h"
+void [[fu^nc]]() {}
+  )cpp");
+  

[clang-tools-extra] 0f0cbcc - [clangd] Extend the rename API.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2020-10-02T16:03:44+02:00
New Revision: 0f0cbcc4b166f32603371fb1d62ef3816cf8425f

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

LOG: [clangd] Extend the rename API.

several changes:
- return a structure result in rename API;
- prepareRename now returns more information (main-file occurrences);
- remove the duplicated detecting-touch-identifier code in prepareRename (which 
is implemented in rename API);

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/SourceCode.h
clang-tools-extra/clangd/refactor/Rename.cpp
clang-tools-extra/clangd/refactor/Rename.h
clang-tools-extra/clangd/test/rename.test
clang-tools-extra/clangd/unittests/RenameTests.cpp
clang-tools-extra/clangd/unittests/SyncAPI.cpp
clang-tools-extra/clangd/unittests/SyncAPI.h

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index c2915aeada4f..34d5a305494c 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -793,8 +793,13 @@ void ClangdLSPServer::onWorkspaceSymbol(
 
 void ClangdLSPServer::onPrepareRename(const TextDocumentPositionParams ,
   Callback> Reply) {
-  Server->prepareRename(Params.textDocument.uri.file(), Params.position,
-Opts.Rename, std::move(Reply));
+  Server->prepareRename(
+  Params.textDocument.uri.file(), Params.position, Opts.Rename,
+  [Reply = std::move(Reply)](llvm::Expected Result) mutable {
+if (!Result)
+  return Reply(Result.takeError());
+return Reply(std::move(Result->Target));
+  });
 }
 
 void ClangdLSPServer::onRename(const RenameParams ,
@@ -806,14 +811,14 @@ void ClangdLSPServer::onRename(const RenameParams ,
   Server->rename(
   File, Params.position, Params.newName, Opts.Rename,
   [File, Params, Reply = std::move(Reply),
-   this](llvm::Expected Edits) mutable {
-if (!Edits)
-  return Reply(Edits.takeError());
-if (auto Err = validateEdits(DraftMgr, *Edits))
+   this](llvm::Expected R) mutable {
+if (!R)
+  return Reply(R.takeError());
+if (auto Err = validateEdits(DraftMgr, R->GlobalChanges))
   return Reply(std::move(Err));
 WorkspaceEdit Result;
 Result.changes.emplace();
-for (const auto  : *Edits) {
+for (const auto  : R->GlobalChanges) {
   (*Result.changes)[URI::createFile(Rep.first()).toString()] =
   Rep.second.asTextEdits();
 }

diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 8c73b6a7d063..0840155fc8f9 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -400,46 +400,35 @@ void ClangdServer::formatOnType(PathRef File, 
llvm::StringRef Code,
 
 void ClangdServer::prepareRename(PathRef File, Position Pos,
  const RenameOptions ,
- Callback> CB) {
+ Callback CB) {
   auto Action = [Pos, File = File.str(), CB = std::move(CB), RenameOpts,
  this](llvm::Expected InpAST) mutable {
 if (!InpAST)
   return CB(InpAST.takeError());
-auto  = InpAST->AST;
-const auto  = AST.getSourceManager();
-auto Loc = sourceLocationInMainFile(SM, Pos);
-if (!Loc)
-  return CB(Loc.takeError());
-const auto *TouchingIdentifier =
-spelledIdentifierTouching(*Loc, AST.getTokens());
-if (!TouchingIdentifier)
-  return CB(llvm::None); // no rename on non-identifiers.
-
-auto Range = halfOpenToRange(
-SM, CharSourceRange::getCharRange(TouchingIdentifier->location(),
-  TouchingIdentifier->endLocation()));
-
-if (RenameOpts.AllowCrossFile)
-  // FIXME: we now assume cross-file rename always succeeds, revisit this.
-  return CB(Range);
-
-// Performing the local rename isn't substantially more expensive than
-// doing an AST-based check, so we just rename and throw away the results.
-auto Changes = clangd::rename({Pos, "dummy", AST, File, Index, RenameOpts,
-   /*GetDirtyBuffer=*/nullptr});
-if (!Changes) {
+// prepareRename is latency-sensitive:
+//  - for single-file rename, performing rename isn't substantially more
+//expensive than doing an AST-based check (the index is used to see if
+//the rename is 

[PATCH] D63640: [clang] Improve Serialization/Imporing of APValues

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:9010
+  ToPath[Idx] =
+  cast(const_cast(ImpDecl.get()));
+}

Tyker wrote:
> rsmith wrote:
> > We want the path in an `APValue` to be canonical, but importing a canonical 
> > decl might result in a non-canonical decl.
> > but importing a canonical decl might result in a non-canonical decl.
> this is a quite surprising behavior.
> > but importing a canonical decl might result in a non-canonical decl.
> this is a quite surprising behavior.

If you already have an existing redecl chain in the destination ASTContext 
(let's say A->B->C, A is the canonical decl), then importing a canonical decl 
(let's say D) would result an A->B->C->D' chain. Where D' is the imported 
version of D.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63640/new/

https://reviews.llvm.org/D63640

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

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Adam Czachorowski via Phabricator via cfe-commits]

adamcz accepted this revision.
adamcz added a comment.
This revision is now accepted and ready to land.

Still a couple of lint warnings, otherwise LGTM




Comment at: 
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp:74
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();

Move this out of the loop. Right now we re-generate "random" dataset, but it's 
always the same dataset ;-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88590/new/

https://reviews.llvm.org/D88590

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu created this revision.
jasonliu added reviewers: hubert.reinterpretcast, daltenty, sfertile, 
Xiangling_L, DiggerLin.
Herald added subscribers: dang, dexonsmith, steven_wu, hiraditya, arichardson, 
sbc100, emaste.
Herald added a reviewer: espindola.
Herald added a reviewer: MaskRay.
jasonliu requested review of this revision.
Herald added a subscriber: aheejin.

This is the follow up on D88493  where we 
flipped the default for llc on AIX.
We would also want to flip the default for Clang as well.


https://reviews.llvm.org/D88737

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/function-sections.c
  lld/COFF/LTO.cpp
  lld/ELF/LTO.cpp
  lld/wasm/LTO.cpp

Index: lld/wasm/LTO.cpp
===
--- lld/wasm/LTO.cpp
+++ lld/wasm/LTO.cpp
@@ -45,6 +45,7 @@
 
   // Always emit a section per function/data with LTO.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   c.DisableVerify = config->disableVerify;
Index: lld/ELF/LTO.cpp
===
--- lld/ELF/LTO.cpp
+++ lld/ELF/LTO.cpp
@@ -86,6 +86,7 @@
 
   // Always emit a section per function/datum with LTO.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   // Check if basic block sections must be used.
Index: lld/COFF/LTO.cpp
===
--- lld/COFF/LTO.cpp
+++ lld/COFF/LTO.cpp
@@ -66,6 +66,7 @@
   // Always emit a section per function/datum with LTO. LLVM LTO should get most
   // of the benefit of linker GC, but there are still opportunities for ICF.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   // Use static reloc model on 32-bit x86 because it usually results in more
Index: clang/test/Driver/function-sections.c
===
--- clang/test/Driver/function-sections.c
+++ clang/test/Driver/function-sections.c
@@ -3,13 +3,15 @@
 // CHECK-FS: -ffunction-sections
 // CHECK-NOFS-NOT: -ffunction-sections
 // CHECK-DS: -fdata-sections
-// CHECK-NODS-NOT: -fdata-sections
+// CHECK-NODS: -fno-data-sections
+// CHECK-DS-DEFAULT-NOT: -fdata-sections
+// CHECK-DS-DEFAULT-NOT: -fno-data-sections
 // CHECK-US-NOT: -fno-unique-section-names
 // CHECK-NOUS: -fno-unique-section-names
 
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target i386-unknown-linux \
-// RUN:   | FileCheck --check-prefix=CHECK-NOFS --check-prefix=CHECK-NODS %s
+// RUN:   | FileCheck --check-prefix=CHECK-NOFS --check-prefix=CHECK-DS-DEFAULT %s
 
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target i386-unknown-linux \
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -991,6 +991,13 @@
   Args.hasArg(OPT_ffunction_sections) ||
   (Opts.BBSections != "none" && Opts.BBSections != "labels");
 
+  if (Args.getLastArg(OPT_fdata_sections) ||
+  Args.getLastArg(OPT_fno_data_sections)) {
+Opts.HasExplicitDataSections = true;
+Opts.DataSections =
+Args.hasFlag(OPT_fdata_sections, OPT_fno_data_sections, false);
+  }
+
   Opts.DataSections = Args.hasArg(OPT_fdata_sections);
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4906,8 +4906,13 @@
 }
   }
 
-  if (Args.hasFlag(options::OPT_fdata_sections, options::OPT_fno_data_sections,
-   UseSeparateSections)) {
+  if (Arg *A = Args.getLastArg(options::OPT_fdata_sections,
+   options::OPT_fno_data_sections)) {
+if (A->getOption().matches(options::OPT_fdata_sections))
+  CmdArgs.push_back("-fdata-sections");
+else
+  CmdArgs.push_back("-fno-data-sections");
+  } else if (UseSeparateSections) {
 CmdArgs.push_back("-fdata-sections");
   }
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -517,6 +517,7 @@
   Options.EnableMachineFunctionSplitter = CodeGenOpts.SplitMachineFunctions;
   Options.FunctionSections = CodeGenOpts.FunctionSections;
   Options.DataSections = 

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

balazske wrote:
> aaron.ballman wrote:
> > balazske wrote:
> > > aaron.ballman wrote:
> > > > I'm not certain I understand why we're looking through the entire 
> > > > redeclaration chain to see if the function is ever mentioned in a 
> > > > system header. I was expecting we'd look at the expansion location of 
> > > > the declaration and see if that's in a system header, which is already 
> > > > handled by the `isExpansionInSystemHeader()` matcher. Similar below.
> > > This function is called from ` SignalHandlerCheck::check` when any 
> > > function call is found. So the check for system header is needed. It was 
> > > unclear to me what the "expansion location" means but it seems to work if 
> > > using that expansion location and checking for system header, instead of 
> > > this loop. I will update the code.
> > > This function is called from  SignalHandlerCheck::check when any function 
> > > call is found. So the check for system header is needed. 
> > 
> > The check for the system header isn't what I was concerned by, it was the 
> > fact that we're walking the entire redeclaration chain to see if *any* 
> > declaration is in a system header that I don't understand the purpose of.
> > 
> > > It was unclear to me what the "expansion location" means but it seems to 
> > > work if using that expansion location and checking for system header, 
> > > instead of this loop. I will update the code.
> > 
> > The spelling location is where the user wrote the code and the expansion 
> > location is where the macro name is written, but thinking on it harder, 
> > that shouldn't matter for this situation as either location would be in the 
> > system header anyway.
> The function declaration is not often a macro name so there is no "expansion 
> location" or the same as the original location. My concern was that if there 
> is a declaration of system call function in a source file (like `void 
> abort(void);` in .c file) for any reason, we may find this declaration 
> instead of the one in the header file, if not looping over the declaration 
> chain.
> The function declaration is not often a macro name so there is no "expansion 
> location" or the same as the original location.

Agreed.

> My concern was that if there is a declaration of system call function in a 
> source file (like `void abort(void);` in .c file) for any reason, we may find 
> this declaration instead of the one in the header file, if not looping over 
> the declaration chain.

Typically, when a C user does something like that, it's because they're 
explicitly *not* including the header file at all (they're just forward 
declaring the function so they can use it) and so we'd get the logic wrong for 
them anyway because we'd never find the declaration in the system header.

Using the canonical declaration is more typical and would realistically fail 
only in circumstances like forward declaring a system header function and then 
later including the system header itself. That said, I suppose your approach is 
defensible enough. Redeclaration chains are hopefully short enough that it 
isn't a performance hit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87449/new/

https://reviews.llvm.org/D87449

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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 295819.
hokein marked an inline comment as done.
hokein added a comment.

change LocalChanges type to vector


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88634/new/

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer , PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer , PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions );
+llvm::Expected runRename(ClangdServer , PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions );
+
+llvm::Expected
+runPrepareRename(ClangdServer , PathRef File, Position Pos,
+ const clangd::RenameOptions );
 
 llvm::Expected
 runFormatFile(ClangdServer , PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer , PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions ) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer , PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions ) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer ,
+  PathRef File, Position Pos,
+  const RenameOptions ) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer , PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,9 +502,10 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
-expectedResult(Code, NewName));
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(
+  applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
+  expectedResult(Code, NewName));
 }
   }
 }
@@ -653,8 +654,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(Results->GlobalChanges)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +684,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +704,44 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  Annotations FooH("void func();");
+  Annotations FooCC(R"cpp(
+#include "foo.h"
+void [[fu^nc]]() {}
+  )cpp");
+  std::string FooHPath = testPath("foo.h");
+  std::string FooCCPath = 

[PATCH] D88314: Added llvm-string-referencing check

[Bogdan Serea via Phabricator via cfe-commits]

bogser01 added a comment.

@alexfh does this look alright?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88314/new/

https://reviews.llvm.org/D88314

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