[clang] 2121dc5 - [llvm-lto] Remove support for legacy pass manager

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T09:40:17+02:00
New Revision: 2121dc5b158b0d11667a5d8c39f0121b869ca1c5

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

LOG: [llvm-lto] Remove support for legacy pass manager

This removes support for the legacy pass manager in llvm-lto and
llvm-lto2. In this case I've dropped the use-new-pm option entirely,
as I don't think this is considered part of the public interface.

This also makes -debug-pass-manager work with llvm-lto, because
that was needed to migrate some tests to NewPM.

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

Added: 


Modified: 
clang/test/Driver/memtag_lto.c
llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
llvm/test/Analysis/StackSafetyAnalysis/ipa-alias.ll
llvm/test/Analysis/StackSafetyAnalysis/ipa.ll
llvm/test/Feature/load_extension.ll
llvm/test/LTO/Resolution/X86/load-sample-prof-icp.ll
llvm/test/LTO/Resolution/X86/load-sample-prof-lto.ll
llvm/test/LTO/X86/diagnostic-handler-remarks.ll
llvm/test/LTO/X86/disable-verify.ll
llvm/test/LTO/X86/tailcallelim.ll
llvm/test/LTO/X86/tli-nobuiltin.ll
llvm/test/Other/X86/lto-hot-cold-split.ll
llvm/test/ThinLTO/X86/cfi-devirt.ll
llvm/test/ThinLTO/X86/cfi-unsat.ll
llvm/test/ThinLTO/X86/cfi.ll
llvm/test/ThinLTO/X86/devirt-after-icp.ll
llvm/test/ThinLTO/X86/devirt.ll
llvm/test/ThinLTO/X86/devirt2.ll
llvm/test/ThinLTO/X86/devirt_check.ll
llvm/test/ThinLTO/X86/devirt_external_comdat_same_guid.ll
llvm/test/ThinLTO/X86/devirt_local_same_guid.ll
llvm/test/ThinLTO/X86/devirt_promote.ll
llvm/test/ThinLTO/X86/devirt_vcall_vis_hidden.ll
llvm/test/ThinLTO/X86/devirt_vcall_vis_public.ll
llvm/test/ThinLTO/X86/diagnostic-handler-remarks-with-hotness.ll
llvm/test/ThinLTO/X86/diagnostic-handler-remarks.ll
llvm/test/ThinLTO/X86/newpm-basic.ll
llvm/test/ThinLTO/X86/nodevirt-nonpromoted-typeid.ll
llvm/test/ThinLTO/X86/printer.ll
llvm/test/tools/llvm-lto2/X86/pipeline.ll
llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
llvm/tools/llvm-lto/llvm-lto.cpp
llvm/tools/llvm-lto2/llvm-lto2.cpp

Removed: 




diff  --git a/clang/test/Driver/memtag_lto.c b/clang/test/Driver/memtag_lto.c
index 2d3445c359fa5..d73670f99cb60 100644
--- a/clang/test/Driver/memtag_lto.c
+++ b/clang/test/Driver/memtag_lto.c
@@ -10,7 +10,7 @@
 // Full LTO
 // RUN: %clang -O1 -target aarch64-unknown-linux -c %s -flto=full -o 
%t.ltonewpm1.bc
 // RUN: %clang -O1 -target aarch64-unknown-linux -c -DBUILD2 %s -flto=full -o 
%t.ltonewpm2.bc
-// RUN: llvm-lto2 run -use-new-pm -o %t.ltonewpm %t.ltonewpm1.bc 
%t.ltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
+// RUN: llvm-lto2 run -o %t.ltonewpm %t.ltonewpm1.bc %t.ltonewpm2.bc 
-save-temps -stack-safety-print -thinlto-threads 1 -O1 \
 // RUN:  -r %t.ltonewpm1.bc,fn,plx \
 // RUN:  -r %t.ltonewpm1.bc,use,lx \
 // RUN:  -r %t.ltonewpm1.bc,use_local,plx \
@@ -21,7 +21,7 @@
 // Thin LTO, new PM
 // RUN: %clang -O1 -target aarch64-unknown-linux -c %s -flto=thin -o 
%t.thinltonewpm1.bc
 // RUN: %clang -O1 -target aarch64-unknown-linux -c -DBUILD2 %s -flto=thin -o 
%t.thinltonewpm2.bc
-// RUN: llvm-lto2 run -use-new-pm -o %t.thinltonewpm %t.thinltonewpm1.bc 
%t.thinltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
+// RUN: llvm-lto2 run -o %t.thinltonewpm %t.thinltonewpm1.bc 
%t.thinltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
 // RUN:  -r %t.thinltonewpm1.bc,fn,plx \
 // RUN:  -r %t.thinltonewpm1.bc,use,lx \
 // RUN:  -r %t.thinltonewpm1.bc,use_local,plx \
@@ -41,7 +41,7 @@
 // Full LTO: both are safe.
 // RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag 
-fsanitize=memtag -c %s -flto=full -o %t.ltonewpm1.bc
 // RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag 
-fsanitize=memtag -c -DBUILD2 %s -flto=full -o %t.ltonewpm2.bc
-// RUN: llvm-lto2 run -use-new-pm -o %t.ltonewpm %t.ltonewpm1.bc 
%t.ltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
+// RUN: llvm-lto2 run -o %t.ltonewpm %t.ltonewpm1.bc %t.ltonewpm2.bc 
-save-temps -stack-safety-print -thinlto-threads 1 -O1 \
 // RUN:  -r %t.ltonewpm1.bc,fn,plx \
 // RUN:  -r %t.ltonewpm1.bc,use,lx \
 // RUN:  -r %t.ltonewpm1.bc,use_local,plx \
@@ -52,7 +52,7 @@
 // Thin LTO: both are safe.
 // RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag 
-fsanitize=memtag -c %s -flto=thin -o %t.thinltonewpm1.bc
 // RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag 
-fsanitize=memtag -c -DBUILD2 %s -flto=thin -o %t.thinltonewpm2.bc
-// RUN: llvm-lto2 run -use-new-pm -o %t.thinltonewpm %t.thinltonewpm1.bc 
%t.thinltonewpm2.bc -s

[PATCH] D123376: [llvm-lto] Remove support for legacy pass manager

2022-04-11 Thread Nikita Popov 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 rG2121dc5b158b: [llvm-lto] Remove support for legacy pass 
manager (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123376

Files:
  clang/test/Driver/memtag_lto.c
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/test/Analysis/StackSafetyAnalysis/ipa-alias.ll
  llvm/test/Analysis/StackSafetyAnalysis/ipa.ll
  llvm/test/Feature/load_extension.ll
  llvm/test/LTO/Resolution/X86/load-sample-prof-icp.ll
  llvm/test/LTO/Resolution/X86/load-sample-prof-lto.ll
  llvm/test/LTO/X86/diagnostic-handler-remarks.ll
  llvm/test/LTO/X86/disable-verify.ll
  llvm/test/LTO/X86/tailcallelim.ll
  llvm/test/LTO/X86/tli-nobuiltin.ll
  llvm/test/Other/X86/lto-hot-cold-split.ll
  llvm/test/ThinLTO/X86/cfi-devirt.ll
  llvm/test/ThinLTO/X86/cfi-unsat.ll
  llvm/test/ThinLTO/X86/cfi.ll
  llvm/test/ThinLTO/X86/devirt-after-icp.ll
  llvm/test/ThinLTO/X86/devirt.ll
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/ThinLTO/X86/devirt_check.ll
  llvm/test/ThinLTO/X86/devirt_external_comdat_same_guid.ll
  llvm/test/ThinLTO/X86/devirt_local_same_guid.ll
  llvm/test/ThinLTO/X86/devirt_promote.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_hidden.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_public.ll
  llvm/test/ThinLTO/X86/diagnostic-handler-remarks-with-hotness.ll
  llvm/test/ThinLTO/X86/diagnostic-handler-remarks.ll
  llvm/test/ThinLTO/X86/newpm-basic.ll
  llvm/test/ThinLTO/X86/nodevirt-nonpromoted-typeid.ll
  llvm/test/ThinLTO/X86/printer.ll
  llvm/test/tools/llvm-lto2/X86/pipeline.ll
  llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -143,11 +143,6 @@
  cl::desc("Run PGO context sensitive IR instrumentation"),
  cl::init(false), cl::Hidden);
 
-static cl::opt
-UseNewPM("use-new-pm",
- cl::desc("Run LTO passes using the new pass manager"),
- cl::init(true), cl::Hidden);
-
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
  cl::desc("Print pass management debugging information"));
@@ -267,7 +262,6 @@
   Conf.AAPipeline = AAPipeline;
 
   Conf.OptLevel = OptLevel - '0';
-  Conf.UseNewPM = UseNewPM;
   Conf.Freestanding = EnableFreestanding;
   for (auto &PluginFN : PassPlugins)
 Conf.PassPlugins.push_back(PluginFN);
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -256,11 +256,6 @@
 cl::desc("Instead of running LTO, print the mach-o cpu in each IR file"),
 cl::cat(LTOCategory));
 
-static cl::opt
-UseNewPM("use-new-pm",
- cl::desc("Run LTO passes using the new pass manager"),
- cl::init(true), cl::Hidden, cl::cat(LTOCategory));
-
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
  cl::desc("Print pass management debugging information"),
@@ -605,7 +600,6 @@
 ThinGenerator.setCacheMaxSizeFiles(ThinLTOCacheMaxSizeFiles);
 ThinGenerator.setCacheMaxSizeBytes(ThinLTOCacheMaxSizeBytes);
 ThinGenerator.setFreestanding(EnableFreestanding);
-ThinGenerator.setUseNewPM(UseNewPM);
 ThinGenerator.setDebugPassManager(DebugPassManager);
 
 // Add all the exported symbols to the table of symbols to preserve.
@@ -1016,6 +1010,7 @@
 
   CodeGen.setCodePICModel(codegen::getExplicitRelocModel());
   CodeGen.setFreestanding(EnableFreestanding);
+  CodeGen.setDebugPassManager(DebugPassManager);
 
   CodeGen.setDebugInfo(LTO_DEBUG_MODEL_DWARF);
   CodeGen.setTargetOptions(Options);
@@ -1070,8 +1065,6 @@
   CodeGen.setOptLevel(OptLevel - '0');
   CodeGen.setAttrs(codegen::getMAttrs());
 
-  CodeGen.setUseNewPM(UseNewPM);
-
   if (auto FT = codegen::getExplicitFileType())
 CodeGen.setFileType(FT.getValue());
 
Index: llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
===
--- llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
+++ llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
@@ -2,19 +2,19 @@
 
 ; Test SLP and Loop Vectorization are enabled by default at O2 and O3.
 ; RUN: llvm-lto2 run %t1.bc -o %t2.o -O0 -r %t1.bc,foo,plx -debug-pass-manager \
-; RUN:  -use-new-pm -save-temps 2>&1 | FileCheck %s --check-prefix=CHECK-O0-SLP
+; RUN:  -save-temps 2>&1 | FileCheck %s --check-prefix=CHECK-O0-SLP
 ; RUN

[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

Would it not be better if these parens were stripped in the fixit as they are 
unnecessary in the enum value decl?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123479

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


[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

2022-04-11 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 421847.
kadircet added a comment.

- Address comments and more cleanups


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123289

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/SymbolCollector.h
  clang-tools-extra/clangd/index/SymbolID.cpp
  clang-tools-extra/clangd/index/SymbolID.h
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1013,10 +1013,21 @@
   )cpp",
   "Foo::Foo" /// constructor.
 },
+{ // Unclean identifiers
+  R"cpp(
+struct Foo {};
+  )cpp",
+  R"cpp(
+$spelled[[Fo\
+o]] f{};
+  )cpp",
+  "Foo",
+},
   };
   CollectorOpts.RefFilter = RefKind::All;
   CollectorOpts.RefsInHeaders = false;
   for (const auto& T : TestCases) {
+SCOPED_TRACE(T.Header + "\n---\n" + T.Main);
 Annotations Header(T.Header);
 Annotations Main(T.Main);
 // Reset the file system.
@@ -1039,10 +1050,14 @@
 }
 const auto SpelledRefs = std::move(SpelledSlabBuilder).build(),
ImplicitRefs = std::move(ImplicitSlabBuilder).build();
-EXPECT_THAT(SpelledRefs,
-Contains(Pair(TargetID, haveRanges(SpelledRanges;
-EXPECT_THAT(ImplicitRefs,
-Contains(Pair(TargetID, haveRanges(ImplicitRanges;
+EXPECT_EQ(SpelledRanges.empty(), SpelledRefs.empty());
+EXPECT_EQ(ImplicitRanges.empty(), ImplicitRefs.empty());
+if (!SpelledRanges.empty())
+  EXPECT_THAT(SpelledRefs,
+  Contains(Pair(TargetID, haveRanges(SpelledRanges;
+if (!ImplicitRanges.empty())
+  EXPECT_THAT(ImplicitRefs,
+  Contains(Pair(TargetID, haveRanges(ImplicitRanges;
   }
 }
 
Index: clang-tools-extra/clangd/index/SymbolID.h
===
--- clang-tools-extra/clangd/index/SymbolID.h
+++ clang-tools-extra/clangd/index/SymbolID.h
@@ -14,6 +14,7 @@
 #include "llvm/Support/Error.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+#include 
 #include 
 #include 
 
@@ -36,9 +37,7 @@
   bool operator==(const SymbolID &Sym) const {
 return HashValue == Sym.HashValue;
   }
-  bool operator!=(const SymbolID &Sym) const {
-return !(*this == Sym);
-  }
+  bool operator!=(const SymbolID &Sym) const { return !(*this == Sym); }
   bool operator<(const SymbolID &Sym) const {
 return HashValue < Sym.HashValue;
   }
@@ -60,7 +59,14 @@
   std::array HashValue{};
 };
 
-llvm::hash_code hash_value(const SymbolID &ID);
+inline llvm::hash_code hash_value(const SymbolID &ID) {
+  // We already have a good hash, just return the first bytes.
+  static_assert(sizeof(size_t) <= SymbolID::RawSize,
+"size_t longer than SHA1!");
+  size_t Result;
+  memcpy(&Result, ID.raw().data(), sizeof(size_t));
+  return llvm::hash_code(Result);
+}
 
 // Write SymbolID into the given stream. SymbolID is encoded as ID.str().
 llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const SymbolID &ID);
Index: clang-tools-extra/clangd/index/SymbolID.cpp
===
--- clang-tools-extra/clangd/index/SymbolID.cpp
+++ clang-tools-extra/clangd/index/SymbolID.cpp
@@ -20,8 +20,7 @@
 }
 
 llvm::StringRef SymbolID::raw() const {
-  return llvm::StringRef(reinterpret_cast(HashValue.data()),
- RawSize);
+  return llvm::StringRef(reinterpret_cast(&HashValue), RawSize);
 }
 
 SymbolID SymbolID::fromRaw(llvm::StringRef Raw) {
@@ -46,14 +45,5 @@
   return OS << llvm::toHex(ID.raw());
 }
 
-llvm::hash_code hash_value(const SymbolID &ID) {
-  // We already have a good hash, just return the first bytes.
-  static_assert(sizeof(size_t) <= SymbolID::RawSize,
-"size_t longer than SHA1!");
-  size_t Result;
-  memcpy(&Result, ID.raw().data(), sizeof(size_t));
-  return llvm::hash_code(Result);
-}
-
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/SymbolCollector.h
===
--- clang-tools-extra/clangd/index/SymbolCollector.h
+++ clang-tools-extra/clangd/index/SymbolCollector.h
@@ -13,6 +13,7 @@
 #include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/Symbol.h"
+#include "index/SymbolID.h"
 #include "index/SymbolOrigin.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
@@ -21,6 +22,8 @@
 #include "clang/Index/IndexDataConsumer.h"
 #include "clang/Index/IndexSymbol.h"
 #include "clang/Sema/CodeCompleteConsumer.h"
+#include "clang/Tooling/Syntax/Tokens.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/De

[PATCH] D123488: [clangd] IncludeCleaner: Add filtering mechanism

2022-04-11 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev created this revision.
kbobyrev added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
Herald added a project: All.
kbobyrev requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This introduces filtering out inclusions based on the resolved path. This
mechanism will be important for disabling warnings for headers that we can not
diagnose correctly yet.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123488

Files:
  clang-tools-extra/clangd/Config.h
  clang-tools-extra/clangd/ConfigCompile.cpp
  clang-tools-extra/clangd/ConfigFragment.h
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp

Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -1675,6 +1675,9 @@
   Annotations Test(R"cpp(
 $fix[[  $diag[[#include "unused.h"]]
 ]]
+  // These two will be ignored by the filter.
+  #include "ignore.h"
+  #include "ignore_regex.h"
   #include "used.h"
 
   #include 
@@ -1693,12 +1696,22 @@
 #pragma once
 void used() {}
   )cpp";
+  TU.AdditionalFiles["ignore.h"] = R"cpp(
+#pragma once
+void ignore() {}
+  )cpp";
+  TU.AdditionalFiles["ignore_regex.h"] = R"cpp(
+#pragma once
+void ignore_regex() {}
+  )cpp";
   TU.AdditionalFiles["system/system_header.h"] = "";
   TU.ExtraArgs = {"-isystem" + testPath("system")};
   // Off by default.
   EXPECT_THAT(*TU.build().getDiagnostics(), IsEmpty());
   Config Cfg;
   Cfg.Diagnostics.UnusedIncludes = Config::UnusedIncludesPolicy::Strict;
+  // Set filtering.
+  Cfg.Diagnostics.Includes.IgnoreHeader.emplace_back(llvm::Regex("ignore.*.h"));
   WithContextValue WithCfg(Config::Key, std::move(Cfg));
   EXPECT_THAT(
   *TU.build().getDiagnostics(),
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -23,10 +23,12 @@
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/Syntax/Tokens.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/STLFunctionalExtras.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Regex.h"
 
 namespace clang {
 namespace clangd {
@@ -233,7 +235,8 @@
   }
 }
 
-static bool mayConsiderUnused(const Inclusion &Inc, ParsedAST &AST) {
+static bool mayConsiderUnused(const Inclusion &Inc, ParsedAST &AST,
+  llvm::ArrayRef IgnoreHeader) {
   if (Inc.BehindPragmaKeep)
 return false;
 
@@ -258,6 +261,12 @@
  FE->getName());
 return false;
   }
+  for (auto &Matcher : IgnoreHeader) {
+if (Matcher.match(Inc.Resolved)) {
+  dlog("{0} header is filterred out", FE->getName());
+  return false;
+}
+  }
   return true;
 }
 
@@ -369,6 +378,7 @@
   const llvm::DenseSet &ReferencedFiles,
   const llvm::StringSet<> &ReferencedPublicHeaders) {
   trace::Span Tracer("IncludeCleaner::getUnused");
+  const Config &Cfg = Config::current();
   std::vector Unused;
   for (const Inclusion &MFI : AST.getIncludeStructure().MainFileIncludes) {
 if (!MFI.HeaderID)
@@ -377,7 +387,8 @@
   continue;
 auto IncludeID = static_cast(*MFI.HeaderID);
 bool Used = ReferencedFiles.contains(IncludeID);
-if (!Used && !mayConsiderUnused(MFI, AST)) {
+if (!Used &&
+!mayConsiderUnused(MFI, AST, Cfg.Diagnostics.Includes.IgnoreHeader)) {
   dlog("{0} was not used, but is not eligible to be diagnosed as unused",
MFI.Written);
   continue;
Index: clang-tools-extra/clangd/ConfigFragment.h
===
--- clang-tools-extra/clangd/ConfigFragment.h
+++ clang-tools-extra/clangd/ConfigFragment.h
@@ -232,6 +232,15 @@
 /// - None
 llvm::Optional> UnusedIncludes;
 
+/// Controls IncludeCleaner diagnostics.
+struct IncludesBlock {
+  /// Regexes that will be used to avoid diagnosing certain includes. These
+  /// regexes are anchored on the right and will be matched against the
+  /// resolved include path.
+  std::vector> IgnoreHeader;
+};
+IncludesBlock Includes;
+
 /// Controls how clang-tidy will run over the code base.
 ///
 /// The settings are merged with any settings found in .clang-tidy
Index: clang-tools-extra/clangd/ConfigCompile.cpp
===
--- clang-tools-extra/clangd/ConfigCompile.cpp
+++ clang-tools-extra/clangd/ConfigCompile.cpp
@@ -432,6 +432,7 @@
 Out.Apply.push_back([Val](const Params &, Config &C) {

[clang] 92fed06 - [C++20][Modules] Remove an empty statement [NFC].

2022-04-11 Thread Iain Sandoe via cfe-commits

Author: Iain Sandoe
Date: 2022-04-11T10:06:23+01:00
New Revision: 92fed06f800aa2d0fd29f9e3eac8323cba64b167

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

LOG: [C++20][Modules] Remove an empty statement [NFC].

This addresses a post commit review comment by removing an unused and empty
'else' (replaced with a comment).

Added: 


Modified: 
clang/lib/Sema/SemaModule.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaModule.cpp b/clang/lib/Sema/SemaModule.cpp
index a9d3540e2ef6e..b0e7d30526a3c 100644
--- a/clang/lib/Sema/SemaModule.cpp
+++ b/clang/lib/Sema/SemaModule.cpp
@@ -858,8 +858,7 @@ static bool checkExportedDecl(Sema &S, Decl *D, 
SourceLocation BlockStart) {
 // We don't allow an empty anonymous namespace (we don't allow decls
 // in them either, but that's handled in the recursion).
 diagExportedUnnamedDecl(S, UnnamedDeclKind::Namespace, D, BlockStart);
-  else
-; // We allow an empty named namespace decl.
+  // We allow an empty named namespace decl.
 } else if (DC->getRedeclContext()->isFileContext() && !isa(D))
   return checkExportedDeclContext(S, DC, BlockStart);
   }



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


[clang] 69f7f15 - [Clang] Add -no-opaque-pointers to recently added test (NFC)

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T11:13:38+02:00
New Revision: 69f7f15683c451378dbe9029a0bd2dbd029bcf3a

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

LOG: [Clang] Add -no-opaque-pointers to recently added test (NFC)

Added: 


Modified: 
clang/test/CodeGen/PowerPC/quadword-atomics.c

Removed: 




diff  --git a/clang/test/CodeGen/PowerPC/quadword-atomics.c 
b/clang/test/CodeGen/PowerPC/quadword-atomics.c
index b1da89c2785b7..e8ea687ba5347 100644
--- a/clang/test/CodeGen/PowerPC/quadword-atomics.c
+++ b/clang/test/CodeGen/PowerPC/quadword-atomics.c
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -Werror -Wno-atomic-alignment -triple powerpc64le-linux-gnu 
\
+// RUN: %clang_cc1 -no-opaque-pointers -Werror -Wno-atomic-alignment -triple 
powerpc64le-linux-gnu \
 // RUN:   -target-cpu pwr8 -emit-llvm -o - %s | FileCheck %s 
--check-prefix=PPC64-PWR8
-// RUN: %clang_cc1 -Werror -Wno-atomic-alignment -triple powerpc64le-linux-gnu 
\
+// RUN: %clang_cc1 -no-opaque-pointers -Werror -Wno-atomic-alignment -triple 
powerpc64le-linux-gnu \
 // RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=PPC64
-// RUN: %clang_cc1 -Werror -Wno-atomic-alignment -triple powerpc64-unknown-aix 
\
+// RUN: %clang_cc1 -no-opaque-pointers -Werror -Wno-atomic-alignment -triple 
powerpc64-unknown-aix \
 // RUN:   -target-cpu pwr7 -emit-llvm -o - %s | FileCheck %s 
--check-prefix=PPC64
 
 typedef struct {



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


[clang] 702d5de - [Clang] Enable opaque pointers by default

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T11:13:45+02:00
New Revision: 702d5de4380b1e1554e5b90863093c3a57f76f70

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

LOG: [Clang] Enable opaque pointers by default

Enable opaque pointers by default in clang, which can be disabled
either via cc1 option -no-opaque-pointers or cmake flag
-DCLANG_ENABLE_OPAQUE_POINTERS=OFF.

See https://llvm.org/docs/OpaquePointers.html for context.

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

Added: 


Modified: 
clang/CMakeLists.txt
llvm/docs/OpaquePointers.rst

Removed: 




diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 3a77e7b0c8d60..594e6d0887429 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -251,7 +251,7 @@ option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and 
-pie on linux-gnu" ON)
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
 "Enable opaque pointers by default")
 if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
-  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 elseif(CLANG_ENABLE_OPAQUE_POINTERS)
   set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 else()

diff  --git a/llvm/docs/OpaquePointers.rst b/llvm/docs/OpaquePointers.rst
index 6e684369b6b35..12689d8cd6ccc 100644
--- a/llvm/docs/OpaquePointers.rst
+++ b/llvm/docs/OpaquePointers.rst
@@ -195,8 +195,10 @@ Transition State
 
 
 As of April 2022 both LLVM and Clang have complete support for opaque pointers,
-but typed pointers are still the default. Opaque pointers will be enabled by
-default in Clang soon.
+and opaque pointers are enabled by default in Clang. It is possible to
+temporarily restore the old default using the
+``-DCLANG_ENABLE_OPAQUE_POINTERS=OFF`` cmake option. Opaque pointers can be
+disabled for a single Clang invocation using ``-Xclang -no-opaque-pointers``.
 
 The MLIR and Polly monorepo projects are not fully compatible with opaque
 pointers yet.



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


[PATCH] D123300: [Clang] Enable opaque pointers by default

2022-04-11 Thread Nikita Popov 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 rG702d5de4380b: [Clang] Enable opaque pointers by default 
(authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

Files:
  clang/CMakeLists.txt
  llvm/docs/OpaquePointers.rst


Index: llvm/docs/OpaquePointers.rst
===
--- llvm/docs/OpaquePointers.rst
+++ llvm/docs/OpaquePointers.rst
@@ -195,8 +195,10 @@
 
 
 As of April 2022 both LLVM and Clang have complete support for opaque pointers,
-but typed pointers are still the default. Opaque pointers will be enabled by
-default in Clang soon.
+and opaque pointers are enabled by default in Clang. It is possible to
+temporarily restore the old default using the
+``-DCLANG_ENABLE_OPAQUE_POINTERS=OFF`` cmake option. Opaque pointers can be
+disabled for a single Clang invocation using ``-Xclang -no-opaque-pointers``.
 
 The MLIR and Polly monorepo projects are not fully compatible with opaque
 pointers yet.
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -251,7 +251,7 @@
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
 "Enable opaque pointers by default")
 if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
-  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 elseif(CLANG_ENABLE_OPAQUE_POINTERS)
   set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 else()


Index: llvm/docs/OpaquePointers.rst
===
--- llvm/docs/OpaquePointers.rst
+++ llvm/docs/OpaquePointers.rst
@@ -195,8 +195,10 @@
 
 
 As of April 2022 both LLVM and Clang have complete support for opaque pointers,
-but typed pointers are still the default. Opaque pointers will be enabled by
-default in Clang soon.
+and opaque pointers are enabled by default in Clang. It is possible to
+temporarily restore the old default using the
+``-DCLANG_ENABLE_OPAQUE_POINTERS=OFF`` cmake option. Opaque pointers can be
+disabled for a single Clang invocation using ``-Xclang -no-opaque-pointers``.
 
 The MLIR and Polly monorepo projects are not fully compatible with opaque
 pointers yet.
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -251,7 +251,7 @@
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
 "Enable opaque pointers by default")
 if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
-  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 elseif(CLANG_ENABLE_OPAQUE_POINTERS)
   set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

2022-04-11 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 421855.
kadircet marked 6 inline comments as done.
kadircet edited the summary of this revision.
kadircet added a comment.



- Get rid of leftovers and update comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123289

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/SymbolCollector.h
  clang-tools-extra/clangd/index/SymbolID.cpp
  clang-tools-extra/clangd/index/SymbolID.h
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1013,10 +1013,21 @@
   )cpp",
   "Foo::Foo" /// constructor.
 },
+{ // Unclean identifiers
+  R"cpp(
+struct Foo {};
+  )cpp",
+  R"cpp(
+$spelled[[Fo\
+o]] f{};
+  )cpp",
+  "Foo",
+},
   };
   CollectorOpts.RefFilter = RefKind::All;
   CollectorOpts.RefsInHeaders = false;
   for (const auto& T : TestCases) {
+SCOPED_TRACE(T.Header + "\n---\n" + T.Main);
 Annotations Header(T.Header);
 Annotations Main(T.Main);
 // Reset the file system.
@@ -1039,10 +1050,14 @@
 }
 const auto SpelledRefs = std::move(SpelledSlabBuilder).build(),
ImplicitRefs = std::move(ImplicitSlabBuilder).build();
-EXPECT_THAT(SpelledRefs,
-Contains(Pair(TargetID, haveRanges(SpelledRanges;
-EXPECT_THAT(ImplicitRefs,
-Contains(Pair(TargetID, haveRanges(ImplicitRanges;
+EXPECT_EQ(SpelledRanges.empty(), SpelledRefs.empty());
+EXPECT_EQ(ImplicitRanges.empty(), ImplicitRefs.empty());
+if (!SpelledRanges.empty())
+  EXPECT_THAT(SpelledRefs,
+  Contains(Pair(TargetID, haveRanges(SpelledRanges;
+if (!ImplicitRanges.empty())
+  EXPECT_THAT(ImplicitRefs,
+  Contains(Pair(TargetID, haveRanges(ImplicitRanges;
   }
 }
 
Index: clang-tools-extra/clangd/index/SymbolID.h
===
--- clang-tools-extra/clangd/index/SymbolID.h
+++ clang-tools-extra/clangd/index/SymbolID.h
@@ -14,6 +14,7 @@
 #include "llvm/Support/Error.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+#include 
 #include 
 #include 
 
@@ -36,9 +37,7 @@
   bool operator==(const SymbolID &Sym) const {
 return HashValue == Sym.HashValue;
   }
-  bool operator!=(const SymbolID &Sym) const {
-return !(*this == Sym);
-  }
+  bool operator!=(const SymbolID &Sym) const { return !(*this == Sym); }
   bool operator<(const SymbolID &Sym) const {
 return HashValue < Sym.HashValue;
   }
@@ -60,7 +59,14 @@
   std::array HashValue{};
 };
 
-llvm::hash_code hash_value(const SymbolID &ID);
+inline llvm::hash_code hash_value(const SymbolID &ID) {
+  // We already have a good hash, just return the first bytes.
+  static_assert(sizeof(size_t) <= SymbolID::RawSize,
+"size_t longer than SHA1!");
+  size_t Result;
+  memcpy(&Result, ID.raw().data(), sizeof(size_t));
+  return llvm::hash_code(Result);
+}
 
 // Write SymbolID into the given stream. SymbolID is encoded as ID.str().
 llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const SymbolID &ID);
Index: clang-tools-extra/clangd/index/SymbolID.cpp
===
--- clang-tools-extra/clangd/index/SymbolID.cpp
+++ clang-tools-extra/clangd/index/SymbolID.cpp
@@ -46,14 +46,5 @@
   return OS << llvm::toHex(ID.raw());
 }
 
-llvm::hash_code hash_value(const SymbolID &ID) {
-  // We already have a good hash, just return the first bytes.
-  static_assert(sizeof(size_t) <= SymbolID::RawSize,
-"size_t longer than SHA1!");
-  size_t Result;
-  memcpy(&Result, ID.raw().data(), sizeof(size_t));
-  return llvm::hash_code(Result);
-}
-
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/SymbolCollector.h
===
--- clang-tools-extra/clangd/index/SymbolCollector.h
+++ clang-tools-extra/clangd/index/SymbolCollector.h
@@ -8,11 +8,12 @@
 #ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_SYMBOLCOLLECTOR_H
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_SYMBOLCOLLECTOR_H
 
-#include "index/CanonicalIncludes.h"
 #include "CollectMacros.h"
+#include "index/CanonicalIncludes.h"
 #include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/Symbol.h"
+#include "index/SymbolID.h"
 #include "index/SymbolOrigin.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
@@ -21,6 +22,7 @@
 #include "clang/Index/IndexDataConsumer.h"
 #include "clang/Index/IndexSymbol.h"
 #include "clang/Sema/CodeCompleteConsumer.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT

[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

2022-04-11 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:710
 // FIXME: Populate container information for macro references.
-MacroRefs[ID].push_back({Loc, Roles, /*Container=*/nullptr});
+// FIXME: All macro references are marked as Spelled now, but this should 
be
+// checked.

sammccall wrote:
> What does a non-spelled macro reference look like?
I don't fully understand it either (hence decided to keep it as-is), but my 
initial guess is nested macro expansions, e.g:
```
#define FOO(X) X
#define BAR(X) FOO(X)

BAR(int x);
```

I suppose we assume there's a reference to FOO at expansion of BAR here today. 
But I am not sure if `libIndex` will actually emit a macro reference for `FOO` 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123289

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


[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

2022-04-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:189
+  clang::Token Tok;
+  if (clang::Lexer::getRawToken(Loc, Tok, SM, LO))
+return false;

You've changed this from tokenizing the file with a cache.
If I'm reading your benchmark spreadsheet right, this is ~3% speedup.

I'm not sure this is significant (I imagine not), but you don't actually have 
to run the lexer here, since you already know what the string is going to be, 
it's enough to grab the buffer pointer, check that it starts with the text, 
check that the next character is not an identifier-continuer.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:710
 // FIXME: Populate container information for macro references.
-MacroRefs[ID].push_back({Loc, Roles, /*Container=*/nullptr});
+// FIXME: All macro references are marked as Spelled now, but this should 
be
+// checked.

kadircet wrote:
> sammccall wrote:
> > What does a non-spelled macro reference look like?
> I don't fully understand it either (hence decided to keep it as-is), but my 
> initial guess is nested macro expansions, e.g:
> ```
> #define FOO(X) X
> #define BAR(X) FOO(X)
> 
> BAR(int x);
> ```
> 
> I suppose we assume there's a reference to FOO at expansion of BAR here 
> today. But I am not sure if `libIndex` will actually emit a macro reference 
> for `FOO` here.
oops nevermind, you're only moving this comment from elsewhere


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123289

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


[PATCH] D123478: [clangd] Fix incorrect operator< impl for HighlightingToken

2022-04-11 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

Oopsy :/ Thanks for the fix!

Regarding the test, if you came looking for this piece due to a particular 
issue, it might be nice to have that included in the test suite (assuming it 
can be minimized).
If not, I think it would still be valuable to include a simple unittest that 
just tests `operator<` by creating `HighlightingTokens` to make sure we don't 
make similar mistakes in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123478

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


[PATCH] D122525: [clang][ASTImporter] Fix an import error handling related bug.

2022-04-11 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:8792-8794
+if (!isa(FromDi))
+  if (auto *FromDiDC = dyn_cast(FromDi))
+if (FromDiDC->containsDecl(PrevFromDi))

balazske wrote:
> martong wrote:
> > We should elevate this logic and the one in `ImportDeclContext` that uses 
> > `consumeError` into a common abstraction. I.e. making them closer to each 
> > other in a class.
> > Something like (draft, did not test it, might not compile):
> > ```
> > class ErrorHandlingStrategy {
> >   static bool accumulateChildErrors(DeclContext*);
> >   static bool accumulateChildErrors(Decl *FromDi, Decl* Parent); // Use 
> > this one when traversing through the import path!
> > public:
> >   static Error handleDeclContextError(Error Err, DeclContext* FromDC) {
> > Error ChildErrors = Error::success();
> > if (Err && accumulateChildErrors(FromDC))
> >   ChildErrors =  joinErrors(std::move(ChildErrors), 
> > std::move(Err));
> > else
> >   consumeError(std::move(Err));
> >  return ChildErrors
> >   }
> >   
> > };
> > ```
> The `AccumulateChildErrors` value looks the only common thing. It can mean: 
> Accumulate errors (or not) for declarations that are in child-relationship 
> with the parent. The value is only dependent on the parent, true if it is a 
> `TagDecl`. This value can be extracted into a function that is used in 
> `importDeclContext` and at `Import(Decl *)`. At `importDeclContext` we should 
> accumulate or discard errors for every child node. But not for possible other 
> nodes that are imported but are not a child node (probably no such exists now 
> but theoretically it is possible, and when using the error handling strategy 
> for non-namespace-like nodes).
My point is to try to encapsulate the error handling logic as much as possible. 
It is not just about `AccumulateChildErrors`. The current change scatters the 
error handling logic into seemingly distant code parts. The 
`ErrorHandlingStrategy` class could serve this encapsulation, because that's 
what classes do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122525

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


[PATCH] D123127: [AST] Add a new TemplateName for templates found via a using declaration.

2022-04-11 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 421856.
hokein added a comment.

add a unittest for template name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123127

Files:
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/TemplateName.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/TemplateName.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/AST/ast-dump-using-template.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp
  clang/tools/libclang/CIndex.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/AST/TemplateNameTest.cpp

Index: clang/unittests/AST/TemplateNameTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/TemplateNameTest.cpp
@@ -0,0 +1,63 @@
+//===- unittests/AST/TemplateNameTest.cpp --- Tests for TemplateName --===//
+//
+// 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 "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace {
+using namespace ast_matchers;
+
+std::string printTemplateName(TemplateName TN, const PrintingPolicy &Policy,
+  TemplateName::Qualified Qual) {
+  std::string Result;
+  llvm::raw_string_ostream Out(Result);
+  TN.print(Out, Policy, Qual);
+  return Out.str();
+}
+
+TEST(TemplateName, PrintUsingTemplate) {
+  std::string Code = R"cpp(
+namespace std {
+  template  struct vector {};
+}
+namespace absl { using std::vector; }
+
+template class T> class X;
+
+using absl::vector;
+using A = X;
+  )cpp";
+  auto AST = tooling::buildASTFromCode(Code);
+  ASTContext &Ctx = AST->getASTContext();
+  // Match X in X.
+  auto Matcher = templateArgumentLoc().bind("id");
+
+  const auto *Template =
+  selectFirst("id", match(Matcher, Ctx));
+  assert(Template);
+  TemplateName TN = Template->getArgument().getAsTemplate();
+  EXPECT_EQ(TN.getKind(), TemplateName::UsingTemplate);
+  EXPECT_EQ(TN.getAsUsingShadowDecl()->getTargetDecl(), TN.getAsTemplateDecl());
+
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::Fully),
+"std::vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::AsWritten),
+"vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::None),
+"vector");
+}
+
+} // namespace
+} // namespace clang
Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -30,6 +30,7 @@
   SourceLocationTest.cpp
   StmtPrinterTest.cpp
   StructuralEquivalenceTest.cpp
+  TemplateNameTest.cpp
   TypePrinterTest.cpp
   )
 
Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -890,6 +890,18 @@
  functionDecl(hasDescendant(usingDecl(hasName("bar");
 }
 
+TEST_P(ImportDecl, ImportUsingTemplate) {
+  MatchVerifier Verifier;
+  testImport("namespace ns { template  struct S {}; }"
+ "template  class T> class X {};"
+ "void declToImport() {"
+ "using ns::S;  X xi; }",
+ Lang_CXX11, "", Lang_CXX11, Verifier,
+ functionDecl(
+ hasDescendant(varDecl(hasTypeLoc(templateSpecializationTypeLoc(
+ hasAnyTemplateArgumentLoc(templateArgumentLoc(;
+}
+
 TEST_P(ImportDecl, ImportUsingEnumDecl) {
   MatchVerifier Verifier;
   testImport("namespace foo { enum bar { baz, toto, quux }; }"
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1442,6 +1442,7 @@
 bool CursorVisitor::VisitTemplateName(TemplateName Name, SourceLocation Loc) {
   switch (Name.getKind()) {
   case TemplateName::Template:
+  case Template

[PATCH] D123397: [clang][ASTImporter] Add import of attribute 'enable_if'.

2022-04-11 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123397

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


[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

2022-04-11 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:189
+  clang::Token Tok;
+  if (clang::Lexer::getRawToken(Loc, Tok, SM, LO))
+return false;

sammccall wrote:
> You've changed this from tokenizing the file with a cache.
> If I'm reading your benchmark spreadsheet right, this is ~3% speedup.
> 
> I'm not sure this is significant (I imagine not), but you don't actually have 
> to run the lexer here, since you already know what the string is going to be, 
> it's enough to grab the buffer pointer, check that it starts with the text, 
> check that the next character is not an identifier-continuer.
right, I actually did that at first, but it implies keeping the behaviour 
around unclean tokens broken, and there wasn't much of a win (delta was in the 
noise). I think because the expensive part is actually figuring out the fileid, 
and the lexing call can do it cheaply right now as it benefits from the single 
element cache.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123289

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


[clang] 02cccdc - [AST] Remove a duplicated getDecl method in TemplateName, NFC.

2022-04-11 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-04-11T11:51:28+02:00
New Revision: 02cccdcab25eac735831b405b5ab712543b16950

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

LOG: [AST] Remove a duplicated getDecl method in TemplateName, NFC.

There is a TemplateName::getTemplateDecl which does the same work.

Added: 


Modified: 
clang/include/clang/AST/TemplateName.h
clang/lib/AST/TemplateName.cpp
clang/tools/libclang/CIndex.cpp

Removed: 




diff  --git a/clang/include/clang/AST/TemplateName.h 
b/clang/include/clang/AST/TemplateName.h
index 44080a7f56d42..26c64d0e277ff 100644
--- a/clang/include/clang/AST/TemplateName.h
+++ b/clang/include/clang/AST/TemplateName.h
@@ -415,10 +415,6 @@ class QualifiedTemplateName : public llvm::FoldingSetNode {
   /// keyword.
   bool hasTemplateKeyword() const { return Qualifier.getInt(); }
 
-  /// The template declaration that this qualified name refers
-  /// to.
-  TemplateDecl *getDecl() const { return Template; }
-
   /// The template declaration to which this qualified name
   /// refers.
   TemplateDecl *getTemplateDecl() const { return Template; }

diff  --git a/clang/lib/AST/TemplateName.cpp b/clang/lib/AST/TemplateName.cpp
index 05d7d58b71c4d..a6d8a7fe7b3dd 100644
--- a/clang/lib/AST/TemplateName.cpp
+++ b/clang/lib/AST/TemplateName.cpp
@@ -243,7 +243,7 @@ void TemplateName::print(raw_ostream &OS, const 
PrintingPolicy &Policy,
   QTN->getQualifier()->print(OS, Policy);
 if (QTN->hasTemplateKeyword())
   OS << "template ";
-OS << *QTN->getDecl();
+OS << *QTN->getTemplateDecl();
   } else if (DependentTemplateName *DTN = getAsDependentTemplateName()) {
 if (Qual == Qualified::AsWritten && DTN->getQualifier())
   DTN->getQualifier()->print(OS, Policy);

diff  --git a/clang/tools/libclang/CIndex.cpp b/clang/tools/libclang/CIndex.cpp
index 011d9f2fd7280..0c7406a9002b9 100644
--- a/clang/tools/libclang/CIndex.cpp
+++ b/clang/tools/libclang/CIndex.cpp
@@ -1462,7 +1462,7 @@ bool CursorVisitor::VisitTemplateName(TemplateName Name, 
SourceLocation Loc) {
   case TemplateName::QualifiedTemplate:
 // FIXME: Visit nested-name-specifier.
 return Visit(MakeCursorTemplateRef(
-Name.getAsQualifiedTemplateName()->getDecl(), Loc, TU));
+Name.getAsQualifiedTemplateName()->getTemplateDecl(), Loc, TU));
 
   case TemplateName::SubstTemplateTemplateParm:
 return Visit(MakeCursorTemplateRef(



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


[clang] b72fd1a - [CGCall] Check store type in findDominatingStoreToReturnValue()

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T12:08:29+02:00
New Revision: b72fd1a84d33e19f9f7fa6b7fdcaea57dc51aee4

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

LOG: [CGCall] Check store type in findDominatingStoreToReturnValue()

We need to make sure that the stored type matches the return type.

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/test/CodeGenObjC/section-name.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index c4d342e3d2aaa..e6a5fd1f4f985 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -3228,7 +3228,8 @@ static llvm::StoreInst 
*findDominatingStoreToReturnValue(CodeGenFunction &CGF) {
   // ReturnValue to some other location.
   auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
 auto *SI = dyn_cast(U);
-if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer() ||
+SI->getValueOperand()->getType() != CGF.ReturnValue.getElementType())
   return nullptr;
 // These aren't actually possible for non-coerced returns, and we
 // only care about non-coerced returns on this code path.

diff  --git a/clang/test/CodeGenObjC/section-name.m 
b/clang/test/CodeGenObjC/section-name.m
index b6b9fa4a59f19..63fad82af4e6e 100644
--- a/clang/test/CodeGenObjC/section-name.m
+++ b/clang/test/CodeGenObjC/section-name.m
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple thumbv7--windows-itanium 
-fdeclspec -fobjc-runtime=ios -emit-llvm -o - %s -Wno-objc-root-class | 
FileCheck %s
+// RUN: %clang_cc1 -triple thumbv7--windows-itanium -fdeclspec 
-fobjc-runtime=ios -emit-llvm -o - %s -Wno-objc-root-class | FileCheck %s
 
 @protocol Protocol
 - (void) protocol_method;



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


[PATCH] D122119: [C++20][Modules] Adjust handling of exports of namespaces and using-decls.

2022-04-11 Thread Iain Sandoe via Phabricator via cfe-commits
iains marked an inline comment as done.
iains added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:814-815
+diagExportedUnnamedDecl(S, UnnamedDeclKind::Namespace, D, BlockStart);
+  else
+; // We allow an empty named namespace decl.
+} else if (DC->getRedeclContext()->isFileContext() && !isa(D))

erichkeane wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > I think we should remove it. So that the above `if` could be further 
> > > merged.
> > we can remove the else ; but we cannot merge the !HasName into the if (that 
> > changes the logic of the expression such that empty & unnamed namespace 
> > decls get passed to checkExportedDeclContext()) - which emits a diagnostic 
> > not expected by the standard.
> > 
> > For me, the 'else ;' makes it clear what the alternative is doing (and 
> > there's a comment as well) - but if the general opinions is to remove it, 
> > that's also fine.
> I'd much prefer we did NOT do the empty else/semicolon here.  This ends up 
> causing a warning with GCC ( warning: suggest braces around empty body in an 
> ‘else’ statement [-Wempty-body]  ) and is jsut strange.  I don't mind a 
> comment, but the else/; is strange.
I committed:
rG92fed06f800a: [C++20][Modules] Remove an empty statement [NFC]. 
to resolve this.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122119

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


[PATCH] D123127: [AST] Add a new TemplateName for templates found via a using declaration.

2022-04-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/AST/TemplateName.cpp:246
  TemplateNameDependenceScope::DependentInstantiation)
   Template->printQualifiedName(OS, Policy);
 else

hokein wrote:
> sammccall wrote:
> > this is going to print the wrong qualifier: qualifier of the underlying 
> > rather than of the usingdecl
> I think this is a good argument -- after the code `namespace ns { using 
> std::vector;  }`, what's the fully-qualified name of the `vector` 
> UsingTemplateName within ns?
> 
> 1) `ns::vector` --  the qualified name of using-decl.
> 2) or `std::vector`- the qualified name of the underlying template decl.
> 
> after a second thought, I'm leaning towards 2). AFAIK, the major place to 
> print fully-qualified name is `TemplateArgument::print` (for template 
> template parameters). 2) is providing more useful information for users to 
> locate the actual template class. Imaging a case where we have a `using 
> long::long::long::abc` in a global namespace, printing `abc` seems less 
> useful. 
> 
> This is also consistent with `UsingType`.
OK, that makes sense, but deserves a serious comment - it *looks* like a bug.

(I'd forgotten about the UsingType behavior. It has a 9-line comment!)



Comment at: clang/lib/AST/TemplateName.cpp:115
 
+  if (auto *USD = Storage.dyn_cast())
+return cast(USD->getTargetDecl());

`= getAsUsingShadowDecl`



Comment at: clang/lib/Sema/SemaDecl.cpp:1114
+
   if (SS.isNotEmpty())
 Template =

FIXME here for qualified using case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123127

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


[clang] bb6f8d9 - [OpenCL] Add device enqueue guards for DSE builtins

2022-04-11 Thread Sven van Haastregt via cfe-commits

Author: Sven van Haastregt
Date: 2022-04-11T11:27:51+01:00
New Revision: bb6f8d9a93ef0172f227b04c92e7bbb703641a79

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

LOG: [OpenCL] Add device enqueue guards for DSE builtins

Align guards of these builtins with opencl-c.h.

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td
clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index b64b50867ce59..a7469d684bcc4 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -104,6 +104,7 @@ def FuncExtKhrMipmapImageWrites  : 
FunctionExtension<"cl_khr_mipmap_imag
 def FuncExtKhrGlMsaaSharing  : 
FunctionExtension<"cl_khr_gl_msaa_sharing">;
 def FuncExtKhrGlMsaaSharingReadWrite : 
FunctionExtension<"cl_khr_gl_msaa_sharing __opencl_c_read_write_images">;
 
+def FuncExtOpenCLCDeviceEnqueue  : 
FunctionExtension<"__opencl_c_device_enqueue">;
 def FuncExtOpenCLCGenericAddressSpace: 
FunctionExtension<"__opencl_c_generic_address_space">;
 def FuncExtOpenCLCNamedAddressSpaceBuiltins : 
FunctionExtension<"__opencl_c_named_address_space_builtins">;
 def FuncExtOpenCLCPipes  : 
FunctionExtension<"__opencl_c_pipes">;
@@ -1454,7 +1455,7 @@ let Extension = FuncExtOpenCLCPipes in {
 // Defined in Builtins.def
 
 // --- Table 33 ---
-let MinVersion = CL20 in {
+let Extension = FuncExtOpenCLCDeviceEnqueue in {
   def : Builtin<"enqueue_marker",
   [Int, Queue, UInt, PointerType, GenericAS>, 
PointerType]>;
 

diff  --git a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl 
b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
index e3602aa95e2a9..416f5342ef22e 100644
--- a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -73,6 +73,7 @@ typedef struct {int a;} ndrange_t;
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define __opencl_c_device_enqueue 1
 #define __opencl_c_generic_address_space 1
 #define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1



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


[clang] bdadf1c - [C++20][Modules] Add testcases from section 10.2 dependent on header units.

2022-04-11 Thread Iain Sandoe via cfe-commits

Author: Iain Sandoe
Date: 2022-04-11T11:30:45+01:00
New Revision: bdadf1c2ecb452ca41f23caa87415bc1f9a8431b

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

LOG: [C++20][Modules] Add testcases from section 10.2 dependent on header units.

This adds in testcases reflecting the remaining example in section 10.2
of the C++20 standard.

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

Added: 
clang/test/Modules/cxx20-10-2-ex2.cpp

Modified: 


Removed: 




diff  --git a/clang/test/Modules/cxx20-10-2-ex2.cpp 
b/clang/test/Modules/cxx20-10-2-ex2.cpp
new file mode 100644
index 0..1b0a02c6f91f9
--- /dev/null
+++ b/clang/test/Modules/cxx20-10-2-ex2.cpp
@@ -0,0 +1,42 @@
+// Based on C++20 10.2 example 2.
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-header-unit -I %t \
+// RUN: -xc++-user-header std-10-2-ex2-c.h -o %t/std-10-2-ex2-c.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu1.cpp \
+// RUN:  -o  %t/X.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu2.cpp \
+// RUN: -fmodule-file=%t/std-10-2-ex2-c.pcm -fmodule-file=%t/X.pcm \
+// RUN: -pedantic-errors -verify -o  %t/M.pcm
+
+//--- std-10-2-ex2-b.h
+int f();
+
+//--- std-10-2-ex2-c.h
+int g();
+
+//--- std-10-2-ex2-tu1.cpp
+export module X;
+export int h();
+
+//--- std-10-2-ex2-tu2.cpp
+module;
+#include "std-10-2-ex2-b.h"
+
+export module M;
+import "std-10-2-ex2-c.h";
+import X;
+export using ::f, ::g, ::h; // OK
+struct S;   // expected-note {{target of using declaration}}
+export using ::S;   // expected-error {{using declaration referring to 
'S' with module linkage cannot be exported}}
+
+namespace N {
+export int h();
+static int h(int); // expected-note {{target of using declaration}}
+} // namespace N
+export using N::h; // expected-error {{using declaration referring to 'h' with 
internal linkage cannot be exported}}



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


[PATCH] D122124: [C++20][Modules] Add testcases from section 10.2 dependent on header units.

2022-04-11 Thread Iain Sandoe 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 rGbdadf1c2ecb4: [C++20][Modules] Add testcases from section 
10.2 dependent on header units. (authored by iains).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122124

Files:
  clang/test/Modules/cxx20-10-2-ex2.cpp


Index: clang/test/Modules/cxx20-10-2-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-2-ex2.cpp
@@ -0,0 +1,42 @@
+// Based on C++20 10.2 example 2.
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-header-unit -I %t \
+// RUN: -xc++-user-header std-10-2-ex2-c.h -o %t/std-10-2-ex2-c.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu1.cpp \
+// RUN:  -o  %t/X.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu2.cpp \
+// RUN: -fmodule-file=%t/std-10-2-ex2-c.pcm -fmodule-file=%t/X.pcm \
+// RUN: -pedantic-errors -verify -o  %t/M.pcm
+
+//--- std-10-2-ex2-b.h
+int f();
+
+//--- std-10-2-ex2-c.h
+int g();
+
+//--- std-10-2-ex2-tu1.cpp
+export module X;
+export int h();
+
+//--- std-10-2-ex2-tu2.cpp
+module;
+#include "std-10-2-ex2-b.h"
+
+export module M;
+import "std-10-2-ex2-c.h";
+import X;
+export using ::f, ::g, ::h; // OK
+struct S;   // expected-note {{target of using declaration}}
+export using ::S;   // expected-error {{using declaration referring to 
'S' with module linkage cannot be exported}}
+
+namespace N {
+export int h();
+static int h(int); // expected-note {{target of using declaration}}
+} // namespace N
+export using N::h; // expected-error {{using declaration referring to 'h' with 
internal linkage cannot be exported}}


Index: clang/test/Modules/cxx20-10-2-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-2-ex2.cpp
@@ -0,0 +1,42 @@
+// Based on C++20 10.2 example 2.
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-header-unit -I %t \
+// RUN: -xc++-user-header std-10-2-ex2-c.h -o %t/std-10-2-ex2-c.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu1.cpp \
+// RUN:  -o  %t/X.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std-10-2-ex2-tu2.cpp \
+// RUN: -fmodule-file=%t/std-10-2-ex2-c.pcm -fmodule-file=%t/X.pcm \
+// RUN: -pedantic-errors -verify -o  %t/M.pcm
+
+//--- std-10-2-ex2-b.h
+int f();
+
+//--- std-10-2-ex2-c.h
+int g();
+
+//--- std-10-2-ex2-tu1.cpp
+export module X;
+export int h();
+
+//--- std-10-2-ex2-tu2.cpp
+module;
+#include "std-10-2-ex2-b.h"
+
+export module M;
+import "std-10-2-ex2-c.h";
+import X;
+export using ::f, ::g, ::h; // OK
+struct S;   // expected-note {{target of using declaration}}
+export using ::S;   // expected-error {{using declaration referring to 'S' with module linkage cannot be exported}}
+
+namespace N {
+export int h();
+static int h(int); // expected-note {{target of using declaration}}
+} // namespace N
+export using N::h; // expected-error {{using declaration referring to 'h' with internal linkage cannot be exported}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D122728: [OpenCL] opencl-c.h: Add const to get_image_num_samples

2022-04-11 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122728

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


[PATCH] D123452: [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Nico Weber via Phabricator via cfe-commits
thakis accepted this revision.
thakis added a comment.
This revision is now accepted and ready to land.

LG

Do you have commit permission, or do you want me to land this for you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123452

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


[clang] b00d0fa - [Clang] Add -no-opaque-pointers to native powerpc test (NFC)

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T13:15:46+02:00
New Revision: b00d0fa2c7f0a187867c535b3f7006376420d58f

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

LOG: [Clang] Add -no-opaque-pointers to native powerpc test (NFC)

Does not run on x86, so I missed this before. The test currently
has typed pointer check lines.

Added: 


Modified: 
clang/test/CodeGen/PowerPC/ppc-mm-malloc.c

Removed: 




diff  --git a/clang/test/CodeGen/PowerPC/ppc-mm-malloc.c 
b/clang/test/CodeGen/PowerPC/ppc-mm-malloc.c
index 25711e80fffd2..e5920b76d0e3c 100644
--- a/clang/test/CodeGen/PowerPC/ppc-mm-malloc.c
+++ b/clang/test/CodeGen/PowerPC/ppc-mm-malloc.c
@@ -6,7 +6,7 @@
 // require installing target headers in build env, otherwise expecting
 // failures. So this test will focus on native build only.
 
-// RUN: %clang -target powerpc64-unknown-linux-gnu -S -emit-llvm %s 
-fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt | 
FileCheck %s
+// RUN: %clang -Xclang -no-opaque-pointers -target powerpc64-unknown-linux-gnu 
-S -emit-llvm %s -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | 
llvm-cxxfilt | FileCheck %s
 
 #include 
 



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


[PATCH] D123452: [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Guoxiong Li via Phabricator via cfe-commits
lgxbslgx added a comment.

@thakis Thanks for the review.

I don't have the commit permission. Please use `Guoxiong Li 
` to commit the change. Thanks for your help.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123452

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-11 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

awarzynski wrote:
> rriddle wrote:
> > awarzynski wrote:
> > > awarzynski wrote:
> > > > rovka wrote:
> > > > > rovka wrote:
> > > > > > Is this the most llvm-ish option we have? I'm concerned that MLIR 
> > > > > > might also decide to add an option that sounds like this (and for 
> > > > > > sure -print-ir-before-all is mentioned in the [[ 
> > > > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > > > > Is this the most llvm-ish option we have? I'm concerned that MLIR 
> > > > > > might also decide to add an option that sounds like this (and for 
> > > > > > sure -print-ir-before-all is mentioned in the [[ 
> > > > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > > > 
> > > > > Right, I think that might be why the premerge tests are failing...
> > > > > Is this the most llvm-ish option we have? 
> > > > 
> > > > Sadly, most LLVM options have rather generic names that could at some 
> > > > point be added in MLIR. Perhaps you'll spot something more suitable:
> > > > 
> > > > ```lang=bash
> > > > USAGE: flang (LLVM option parsing) [options]
> > > > 
> > > > OPTIONS:
> > > > 
> > > > Color Options:
> > > > 
> > > >   --color   - Use colors in 
> > > > output (default=autodetect)
> > > > 
> > > > General options:
> > > > 
> > > >   --aarch64-neon-syntax= - Choose style of 
> > > > NEON code to emit from AArch64 backend:
> > > > =generic-   Emit generic 
> > > > NEON assembly
> > > > =apple  -   Emit 
> > > > Apple-style NEON assembly
> > > >   --aarch64-use-aa  - Enable the use of 
> > > > AA during codegen.
> > > >   --abort-on-max-devirt-iterations-reached  - Abort when the 
> > > > max iterations for devirtualization CGSCC repeat pass is reached
> > > >   --allow-ginsert-as-artifact   - Allow G_INSERT to 
> > > > be considered an artifact. Hack around AMDGPU test infinite loops.
> > > >   --always-execute-loop-body- force the body of 
> > > > a loop to execute at least once
> > > >   --array-constructor-initial-buffer-size=- set the 
> > > > incremental array construction buffer size (default=32)
> > > >   --cfg-hide-cold-paths=- Hide blocks with 
> > > > relative frequency below the given value
> > > >   --cfg-hide-deoptimize-paths   -
> > > >   --cfg-hide-unreachable-paths  -
> > > >   --cost-kind=   - Target cost kind
> > > > =throughput -   Reciprocal 
> > > > throughput
> > > > =latency-   Instruction 
> > > > latency
> > > > =code-size  -   Code size
> > > > =size-latency   -   Code size and 
> > > > latency
> > > >   --debugify-level=  - Kind of debug 
> > > > info to add
> > > > =locations  -   Locations only
> > > > =location+variables -   Locations and 
> > > > Variables
> > > >   --debugify-quiet  - Suppress verbose 
> > > > debugify output
> > > >   --default-kinds= - string to set 
> > > > default kind values
> > > >   --disable-i2p-p2i-opt - Disables 
> > > > inttoptr/ptrtoint roundtrip optimization
> > > >   --dot-cfg-mssa= - file name for 
> > > > generated dot file
> > > >   --enable-cse-in-irtranslator  - Should enable CSE 
> > > > in irtranslator
> > > >   --enable-cse-in-legalizer - Should enable CSE 
> > > > in Legalizer
> > > >   --enable-gvn-memdep   -
> > > >   --enable-load-in-loop-pre -
> > > >   --enable-load-pre -
> > > >   --enable-loop-simplifycfg-term-folding-
> > > >   --enable-name-compression - Enable 
> > > > name/filename string compression
> > > >   --enable-split-backedge-in-load-pre   -
> > > >   --experimental-debug-variable-locations   - Use experimental 
> > > > new value-tracking variable locations
> > > >   --fdebug-dump-pre-fir - dump the Pre-FIR 
> > > > tree prior to FIR generation
> > > >   --fs-profile-debug-bw-threshold=- Only show debug 
> > > > message if the source branch weight is greater  than this value.
> > > >   --fs-profile-debug-prob-diff-threshold= - Only show debug 
> > > > message if the branch probili

[PATCH] D115620: [AArch64] Lowering and legalization of strict FP16

2022-04-11 Thread John Brawn via Phabricator via cfe-commits
john.brawn added a comment.

Ping.


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

https://reviews.llvm.org/D115620

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


[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-11 Thread Tomas Matheson via Phabricator via cfe-commits
tmatheson accepted this revision.
tmatheson added inline comments.
This revision is now accepted and ready to land.



Comment at: llvm/unittests/Support/TargetParserTest.cpp:1474
   EXPECT_FALSE(AArch64::getExtensionFeatures(AArch64::AEK_INVALID, Features));
   EXPECT_TRUE(!Features.size());
 

Does this need a similar test for NONE?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123296

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


[clang] d29f8a5 - [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Nico Weber via cfe-commits

Author: Guoxiong Li
Date: 2022-04-11T08:38:37-04:00
New Revision: d29f8a5f83501f69621687c09ba4b3c75033bada

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

LOG: [Clang] Override method ModuleImportRead in 
MultiplexASTDeserializationListener

Fixes https://llvm.org/PR54521

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

Added: 


Modified: 
clang/include/clang/Frontend/MultiplexConsumer.h
clang/lib/Frontend/MultiplexConsumer.cpp

Removed: 




diff  --git a/clang/include/clang/Frontend/MultiplexConsumer.h 
b/clang/include/clang/Frontend/MultiplexConsumer.h
index 3054e1842811d..7f8d2858b3863 100644
--- a/clang/include/clang/Frontend/MultiplexConsumer.h
+++ b/clang/include/clang/Frontend/MultiplexConsumer.h
@@ -40,6 +40,8 @@ class MultiplexASTDeserializationListener : public 
ASTDeserializationListener {
   void MacroDefinitionRead(serialization::PreprocessedEntityID,
MacroDefinitionRecord *MD) override;
   void ModuleRead(serialization::SubmoduleID ID, Module *Mod) override;
+  void ModuleImportRead(serialization::SubmoduleID ID,
+SourceLocation ImportLoc) override;
 
 private:
   std::vector Listeners;

diff  --git a/clang/lib/Frontend/MultiplexConsumer.cpp 
b/clang/lib/Frontend/MultiplexConsumer.cpp
index 34bbc365e6476..737877329c9ce 100644
--- a/clang/lib/Frontend/MultiplexConsumer.cpp
+++ b/clang/lib/Frontend/MultiplexConsumer.cpp
@@ -73,6 +73,12 @@ void MultiplexASTDeserializationListener::ModuleRead(
 Listener->ModuleRead(ID, Mod);
 }
 
+void MultiplexASTDeserializationListener::ModuleImportRead(
+serialization::SubmoduleID ID, SourceLocation ImportLoc) {
+  for (auto &Listener : Listeners)
+Listener->ModuleImportRead(ID, ImportLoc);
+}
+
 // This ASTMutationListener forwards its notifications to a set of
 // child listeners.
 class MultiplexASTMutationListener : public ASTMutationListener {



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


[PATCH] D123452: [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Nico Weber 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 rGd29f8a5f8350: [Clang] Override method ModuleImportRead in 
MultiplexASTDeserializationListener (authored by lgxbslgx, committed by thakis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123452

Files:
  clang/include/clang/Frontend/MultiplexConsumer.h
  clang/lib/Frontend/MultiplexConsumer.cpp


Index: clang/lib/Frontend/MultiplexConsumer.cpp
===
--- clang/lib/Frontend/MultiplexConsumer.cpp
+++ clang/lib/Frontend/MultiplexConsumer.cpp
@@ -73,6 +73,12 @@
 Listener->ModuleRead(ID, Mod);
 }
 
+void MultiplexASTDeserializationListener::ModuleImportRead(
+serialization::SubmoduleID ID, SourceLocation ImportLoc) {
+  for (auto &Listener : Listeners)
+Listener->ModuleImportRead(ID, ImportLoc);
+}
+
 // This ASTMutationListener forwards its notifications to a set of
 // child listeners.
 class MultiplexASTMutationListener : public ASTMutationListener {
Index: clang/include/clang/Frontend/MultiplexConsumer.h
===
--- clang/include/clang/Frontend/MultiplexConsumer.h
+++ clang/include/clang/Frontend/MultiplexConsumer.h
@@ -40,6 +40,8 @@
   void MacroDefinitionRead(serialization::PreprocessedEntityID,
MacroDefinitionRecord *MD) override;
   void ModuleRead(serialization::SubmoduleID ID, Module *Mod) override;
+  void ModuleImportRead(serialization::SubmoduleID ID,
+SourceLocation ImportLoc) override;
 
 private:
   std::vector Listeners;


Index: clang/lib/Frontend/MultiplexConsumer.cpp
===
--- clang/lib/Frontend/MultiplexConsumer.cpp
+++ clang/lib/Frontend/MultiplexConsumer.cpp
@@ -73,6 +73,12 @@
 Listener->ModuleRead(ID, Mod);
 }
 
+void MultiplexASTDeserializationListener::ModuleImportRead(
+serialization::SubmoduleID ID, SourceLocation ImportLoc) {
+  for (auto &Listener : Listeners)
+Listener->ModuleImportRead(ID, ImportLoc);
+}
+
 // This ASTMutationListener forwards its notifications to a set of
 // child listeners.
 class MultiplexASTMutationListener : public ASTMutationListener {
Index: clang/include/clang/Frontend/MultiplexConsumer.h
===
--- clang/include/clang/Frontend/MultiplexConsumer.h
+++ clang/include/clang/Frontend/MultiplexConsumer.h
@@ -40,6 +40,8 @@
   void MacroDefinitionRead(serialization::PreprocessedEntityID,
MacroDefinitionRecord *MD) override;
   void ModuleRead(serialization::SubmoduleID ID, Module *Mod) override;
+  void ModuleImportRead(serialization::SubmoduleID ID,
+SourceLocation ImportLoc) override;
 
 private:
   std::vector Listeners;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D116280: [clang] adds unary type trait checks as compiler built-ins

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:4889-4890
 return T->isArrayType();
+  case UTT_IsBoundedArray:
+return T->isArrayType() && !T->isIncompleteArrayType();
+  case UTT_IsUnboundedArray:

Is a VLA a bounded array? (We support those as an extension in C++, 
unfortunately.)



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5282
+  return false;
+if 
(!T.isReferenceable(LangStandard::getLangStandardForKind(Self.LangOpts.LangStd).isCPlusPlus()))
+  return false;

Why this dance and not `Self.LangOpts.CPlusPlus`? (Same below.)



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5289
+if (UTT == UTT_IsCopyAssignable) {
+  return EvaluateBinaryTypeTrait(Self, BTT_IsAssignable, 
Self.BuildReferenceType(T, true, KeyLoc, T.getBaseTypeIdentifier()), 
AssigneeType, KeyLoc);
+}

It looks like this file could stand to be clang formatted.



Comment at: clang/test/SemaCXX/type-traits.cpp:737
 
+void is_bounded_array()
+{

Please add a test for VLAs to whichever function it should be tested under.



Comment at: clang/test/SemaCXX/type-traits.cpp:764
+  int t30[F(__is_bounded_array(void*))];
+  int t31[F(__is_bounded_array(cvoid*))];
+}

Any reason there's not a test with something like `int[10]` and `int[]`? (Same 
below.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116280

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


[PATCH] D123452: [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks for the patch1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123452

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


[PATCH] D123452: [Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

2022-04-11 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123452

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


[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-11 Thread Qiongsi Wu via Phabricator via cfe-commits
qiongsiwu1 created this revision.
qiongsiwu1 added reviewers: jsji, daltenty, nemanjai.
qiongsiwu1 added a project: clang.
Herald added subscribers: steven.zhang, pengfei, mgorny, dschuff.
Herald added a project: All.
qiongsiwu1 requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.

The goal of this patch is to improve distribution build's flexibility to 
include only applicable header files.

Currently, the `clang-resource-headers` target contains nearly all the files in 
clang/lib/Headers. Most of these files are platform specific (e.g. 
`immintrin.h` is x86 specific). A distribution build will have to either 
include all the headers for all the platforms, or not include any headers. For 
example, if a distribution build for `powerpc` includes the 
`clang-resource-headers` target, it will include all the `x86` specific 
headers, even-though the `x86` specific headers cannot be used.

This patch breaks up the `clang-resource-headers` list to a core list and 
platform specific lists. With the patch, a distribution build can now include 
the `ppc-resource-headers` to include the headers applicable to the `powerpc` 
platform.

Specifically, one can now have

  cmake ... LLVM_DISTRIBUTION_COMPONENTS="clang;ppc-resource-headers" ... 
../llvm

`ninja install-distribution` then installs the powerpc headers.

Similarly, one can do

  cmake ... LLVM_DISTRIBUTION_COMPONENTS="clang;x86-resource-headers" ... 
../llvm

to include headers applicable to the x86 platform in a distribution 
installation.

To implement this behaviour, the patch does two things

1. It breaks up the long files header file list to a core list and platform 
specific lists.
2. It adds numerous platform specific installation targets.

This may or may not be a good way to break up the long header list to add new 
targets, so I am all ears for suggestions/feedback! Also, we may need to add 
other reviewers. May I get some suggestions on that as well?

Thanks so much!


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123498

Files:
  clang/lib/Headers/CMakeLists.txt

Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -1,12 +1,95 @@
-set(files
-  adxintrin.h
-  altivec.h
-  ammintrin.h
-  amxintrin.h
+# core_files list contains the headers shared by all platforms.
+# Please consider adding new platform specific headers
+# to platform specific lists below.
+set(core_files
+  builtins.h
+  float.h
+  inttypes.h
+  iso646.h
+  limits.h
+  module.modulemap
+  stdalign.h
+  stdarg.h
+  stdatomic.h
+  stdbool.h
+  stddef.h
+  __stddef_max_align_t.h
+  stdint.h
+  stdnoreturn.h
+  tgmath.h
+  unwind.h
+  varargs.h
+  )
+
+set(arm_files
   arm_acle.h
   arm_cmse.h
   armintr.h
   arm64intr.h
+  )
+
+set(cuda_files
+  __clang_cuda_builtin_vars.h
+  __clang_cuda_math.h
+  __clang_cuda_cmath.h
+  __clang_cuda_complex_builtins.h
+  __clang_cuda_device_functions.h
+  __clang_cuda_intrinsics.h
+  __clang_cuda_texture_intrinsics.h
+  __clang_cuda_libdevice_declares.h
+  __clang_cuda_math_forward_declares.h
+  __clang_cuda_runtime_wrapper.h
+  )
+
+set(hexagon_files
+  hexagon_circ_brev_intrinsics.h
+  hexagon_protos.h
+  hexagon_types.h
+  hvx_hexagon_protos.h
+  )
+
+set(hip_files
+  __clang_hip_libdevice_declares.h
+  __clang_hip_cmath.h
+  __clang_hip_math.h
+  __clang_hip_runtime_wrapper.h
+  )
+
+set(mips_msa_files
+  msa.h
+  )
+
+set(opencl_files
+  opencl-c.h
+  opencl-c-base.h
+  )
+
+set(ppc_files
+  altivec.h
+  htmintrin.h
+  htmxlintrin.h
+  )
+
+set(systemz_files
+  s390intrin.h
+  vecintrin.h
+  )
+
+set(ve_files
+  velintrin.h
+  velintrin_gen.h
+  velintrin_approx.h
+  )
+
+set(webassembly_files
+  wasm_simd128.h
+  )
+
+set(x86_files
+# Intrinsics
+  ammintrin.h
+  adxintrin.h
+  amxintrin.h
   avx2intrin.h
   avx512bf16intrin.h
   avx512bwintrin.h
@@ -40,67 +123,34 @@
   avxvnniintrin.h
   bmi2intrin.h
   bmiintrin.h
-  builtins.h
-  __clang_cuda_builtin_vars.h
-  __clang_cuda_math.h
-  __clang_cuda_cmath.h
-  __clang_cuda_complex_builtins.h
-  __clang_cuda_device_functions.h
-  __clang_cuda_intrinsics.h
-  __clang_cuda_texture_intrinsics.h
-  __clang_cuda_libdevice_declares.h
-  __clang_cuda_math_forward_declares.h
-  __clang_cuda_runtime_wrapper.h
-  __clang_hip_libdevice_declares.h
-  __clang_hip_cmath.h
-  __clang_hip_math.h
-  __clang_hip_runtime_wrapper.h
   cetintrin.h
-  cet.h
   cldemoteintrin.h
-  clzerointrin.h
-  crc32intrin.h
-  cpuid.h
   clflushoptintrin.h
   clwbintrin.h
+  clzerointrin.h
+  crc32intrin.h
   emmintrin.h
   enqcmdintrin.h
   f16cintrin.h
-  float.h
-  fma4intrin.h
   fmaintrin.h
+  fma4intrin.h
   fxsrintrin.h
   gfniintrin.h
-  hexagon_circ_brev_intrinsics.h
-  hexagon_protos.h
-  hexagon_types.h
-  hvx_hexagon_protos.h
   hresetintrin.h
-  htmintrin.h
-  htmxlintrin.h
   ia32intrin.h
   immintrin.h
-  intrin.h
-  inttypes.h
   invpcidi

[PATCH] D123127: [AST] Add a new TemplateName for templates found via a using declaration.

2022-04-11 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 421891.
hokein marked 2 inline comments as done.
hokein added a comment.

address remaining comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123127

Files:
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/TemplateName.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/TemplateName.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/AST/ast-dump-using-template.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp
  clang/tools/libclang/CIndex.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/AST/TemplateNameTest.cpp

Index: clang/unittests/AST/TemplateNameTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/TemplateNameTest.cpp
@@ -0,0 +1,63 @@
+//===- unittests/AST/TemplateNameTest.cpp --- Tests for TemplateName --===//
+//
+// 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 "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace {
+using namespace ast_matchers;
+
+std::string printTemplateName(TemplateName TN, const PrintingPolicy &Policy,
+  TemplateName::Qualified Qual) {
+  std::string Result;
+  llvm::raw_string_ostream Out(Result);
+  TN.print(Out, Policy, Qual);
+  return Out.str();
+}
+
+TEST(TemplateName, PrintUsingTemplate) {
+  std::string Code = R"cpp(
+namespace std {
+  template  struct vector {};
+}
+namespace absl { using std::vector; }
+
+template class T> class X;
+
+using absl::vector;
+using A = X;
+  )cpp";
+  auto AST = tooling::buildASTFromCode(Code);
+  ASTContext &Ctx = AST->getASTContext();
+  // Match X in X.
+  auto Matcher = templateArgumentLoc().bind("id");
+
+  const auto *Template =
+  selectFirst("id", match(Matcher, Ctx));
+  assert(Template);
+  TemplateName TN = Template->getArgument().getAsTemplate();
+  EXPECT_EQ(TN.getKind(), TemplateName::UsingTemplate);
+  EXPECT_EQ(TN.getAsUsingShadowDecl()->getTargetDecl(), TN.getAsTemplateDecl());
+
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::Fully),
+"std::vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::AsWritten),
+"vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::None),
+"vector");
+}
+
+} // namespace
+} // namespace clang
Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -31,6 +31,7 @@
   SourceLocationTest.cpp
   StmtPrinterTest.cpp
   StructuralEquivalenceTest.cpp
+  TemplateNameTest.cpp
   TypePrinterTest.cpp
   )
 
Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -890,6 +890,18 @@
  functionDecl(hasDescendant(usingDecl(hasName("bar");
 }
 
+TEST_P(ImportDecl, ImportUsingTemplate) {
+  MatchVerifier Verifier;
+  testImport("namespace ns { template  struct S {}; }"
+ "template  class T> class X {};"
+ "void declToImport() {"
+ "using ns::S;  X xi; }",
+ Lang_CXX11, "", Lang_CXX11, Verifier,
+ functionDecl(
+ hasDescendant(varDecl(hasTypeLoc(templateSpecializationTypeLoc(
+ hasAnyTemplateArgumentLoc(templateArgumentLoc(;
+}
+
 TEST_P(ImportDecl, ImportUsingEnumDecl) {
   MatchVerifier Verifier;
   testImport("namespace foo { enum bar { baz, toto, quux }; }"
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1442,6 +1442,7 @@
 bool CursorVisitor::VisitTemplateName(TemplateName Name, SourceLocation Loc) {
   switch (Name.getKind()) {
   case Templ

[PATCH] D119720: [ARM] Pass for Cortex-A57 and Cortex-A72 Fused AES Erratum

2022-04-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: llvm/lib/Target/ARM/ARMFixCortexA57AES1742098Pass.cpp:12-19
+// The intention is this:
+// - Any 128-bit or 64-bit writes to the neon input register of an AES fused
+//   pair are safe (the inputs are to the AESE/AESD instruction).
+// - Any 32-bit writes to the input register are unsafe, but these may happen
+//   in another function, or only on some control flow paths. In these cases,
+//   conservatively insert the VORRq anyway.
+// - So, analyse both inputs to the AESE/AESD instruction, inserting a VORR if

This description would leave me still confused if I didn't happen to already 
know roughly what the plan was. It jumps in half way through the explanation 
that someone would need if they were coming to this pass cold. (E.g. it talks 
about "the VORRq" before having even mentioned //that// there is one, let alone 
//why// there is one.)

How about the suggested text as a rewording?



Comment at: llvm/lib/Target/ARM/ARMFixCortexA57AES1742098Pass.cpp:310
+
+// If there are no unsafe unsafe definitions...
+if (UnsafeCount == 0) {

nit: repeated word


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119720

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


Re: [PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-11 Thread Aaron Ballman via cfe-commits
Somehow this entire thread seems to have dropped the mailing lists and
the review in question, so top-posting to ensure the discussion at
least makes it to the mailing lists.

~Aaron

On Mon, Apr 11, 2022 at 9:10 AM Aaron Ballman  wrote:
>
> On Mon, Apr 11, 2022 at 8:25 AM Joerg Sonnenberger  wrote:
> >
> > Am Mon, Apr 11, 2022 at 07:42:15AM -0400 schrieb Aaron Ballman:
> > > On Mon, Apr 11, 2022 at 7:21 AM Joerg Sonnenberger  wrote:
> > > > You don't see the value of being able to instrument std::move? I don't
> > > > even mean in the sense of the operator new overload. Being able to patch
> > > > libc++ to add a tracking feature seems like an entirely sensible thing
> > > > to support.
> > >
> > > I'd want to hear from STL maintainers whether *they* think it's
> > > reasonable. Every STL maintainer I've ever talked to seems to think
> > > letting users add their own symbols to 'std' is highly problematic, so
> > > I'm not certain that it's a good idea to make that easier and give the
> > > appearance that we bless such a thing as a toolchain. (This goes
> > > beyond libc++ given that Clang also supports other STL implementations
> > > like libstdc++.)
> >
> > Again, this is not about adding symbols to 'std'. You make it impossible
> > to instrument std::move and friends in the name of performance for
> > unoptimized code. Without any mechanism to disable it. If I want to
> > create my own fork of libc++ or libstdc++ or whatever to have such
> > functionality, it should be possible.
>
> Should it? The STL is part of the implementation in C++, so I think
> it's perfectly reasonable to assume the burden is on you to fork the
> compiler as well if you have to.
>
> The root of my concern is: I don't want to expose an option that gives
> the impression it's okay to replace STL functions (especially in *all
> language modes*) given that it is explicitly UB and WG21 has a
> standing document on the subject (https://wg21.link/sd-8). That's not
> an interface I think we should support *unless STL maintainers
> explicitly agree that this is a reasonable policy in general*. (If you
> wanted this to be a CC1 option, that's a bit different to me because
> then it's not giving the same "this is normal, go right ahead and do
> it" feeling with it. My concerns are only with a user-facing option
> and are specifically because the situation you want to support is
> explicitly undefined behavior.)
>
> > I'm not even saying that the
> > semantic analysis here should detect that the std::move implementation
> > is actually std::move, which would side step this question as well.
> > We have a long history of optimization-by-symbol-name breaking
> > reasonable real world code. That's where -fno-builtin-* came from and
> > checks e.g. to allow implementing calloc in C without the compiler
> > turning the code of malloc+memset into a recursive call. I don't see
> > this change here being any different to the nature of those checks.
>
> I see that as different -- those interfaces are in the global
> namespace and thus available for the user to reuse in a freestanding
> environment with different semantics. Giving users a knob to support
> that situation seems eminently reasonable because it's not UB to
> replace those functions.
>
> That said, I'm happy to leave the decision to Richard as code owner.
> If he thinks this is worth maintaining a flag for, I can hold my nose.
>
> ~Aaron
>
> >
> > Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-11 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett updated this revision to Diff 421909.
DavidSpickett added a comment.

Added check that NONE does not return any feature names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123296

Files:
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -12,6 +12,7 @@
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/TargetParser.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 
@@ -1448,14 +1449,20 @@
 
 TEST(TargetParserTest, AArch64ExtensionFeatures) {
   std::vector Extensions = {
-  AArch64::AEK_CRC, AArch64::AEK_CRYPTO,  AArch64::AEK_FP,
-  AArch64::AEK_SIMD,AArch64::AEK_FP16,AArch64::AEK_PROFILE,
-  AArch64::AEK_RAS, AArch64::AEK_LSE, AArch64::AEK_RDM,
-  AArch64::AEK_DOTPROD, AArch64::AEK_SVE, AArch64::AEK_SVE2,
-  AArch64::AEK_SVE2AES, AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3,
-  AArch64::AEK_SVE2BITPERM, AArch64::AEK_RCPC,AArch64::AEK_FP16FML,
-  AArch64::AEK_SME, AArch64::AEK_SMEF64,  AArch64::AEK_SMEI64,
-  AArch64::AEK_PERFMON};
+  AArch64::AEK_CRC, AArch64::AEK_LSE,  AArch64::AEK_RDM,
+  AArch64::AEK_CRYPTO,  AArch64::AEK_SM4,  AArch64::AEK_SHA3,
+  AArch64::AEK_SHA2,AArch64::AEK_AES,  AArch64::AEK_DOTPROD,
+  AArch64::AEK_FP,  AArch64::AEK_SIMD, AArch64::AEK_FP16,
+  AArch64::AEK_FP16FML, AArch64::AEK_PROFILE,  AArch64::AEK_RAS,
+  AArch64::AEK_SVE, AArch64::AEK_SVE2, AArch64::AEK_SVE2AES,
+  AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3, AArch64::AEK_SVE2BITPERM,
+  AArch64::AEK_RCPC,AArch64::AEK_RAND, AArch64::AEK_MTE,
+  AArch64::AEK_SSBS,AArch64::AEK_SB,   AArch64::AEK_PREDRES,
+  AArch64::AEK_BF16,AArch64::AEK_I8MM, AArch64::AEK_F32MM,
+  AArch64::AEK_F64MM,   AArch64::AEK_TME,  AArch64::AEK_LS64,
+  AArch64::AEK_BRBE,AArch64::AEK_PAUTH,AArch64::AEK_FLAGM,
+  AArch64::AEK_SME, AArch64::AEK_SMEF64,   AArch64::AEK_SMEI64,
+  AArch64::AEK_HBC, AArch64::AEK_MOPS, AArch64::AEK_PERFMON};
 
   std::vector Features;
 
@@ -1463,34 +1470,65 @@
   for (auto Ext : Extensions)
 ExtVal |= Ext;
 
+  // INVALID and NONE have no feature names.
   EXPECT_FALSE(AArch64::getExtensionFeatures(AArch64::AEK_INVALID, Features));
   EXPECT_TRUE(!Features.size());
+  // We return True here beccause NONE is a valid choice.
+  EXPECT_TRUE(AArch64::getExtensionFeatures(AArch64::AEK_NONE, Features));
+  EXPECT_TRUE(!Features.size());
 
   AArch64::getExtensionFeatures(ExtVal, Features);
   EXPECT_EQ(Extensions.size(), Features.size());
 
   EXPECT_TRUE(llvm::is_contained(Features, "+crc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
   EXPECT_TRUE(llvm::is_contained(Features, "+crypto"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sm4"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha3"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha2"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+aes"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fp-armv8"));
   EXPECT_TRUE(llvm::is_contained(Features, "+neon"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fullfp16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+spe"));
   EXPECT_TRUE(llvm::is_contained(Features, "+ras"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-aes"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sm4"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sha3"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-bitperm"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rand"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+mte"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+ssbs"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sb"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+predres"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+bf16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+i8mm"));
+  EXPECT_TRUE(ll

[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-11 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett updated this revision to Diff 421910.
DavidSpickett added a comment.

Fix a spelling mistake.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123296

Files:
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -12,6 +12,7 @@
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/TargetParser.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 
@@ -1448,14 +1449,20 @@
 
 TEST(TargetParserTest, AArch64ExtensionFeatures) {
   std::vector Extensions = {
-  AArch64::AEK_CRC, AArch64::AEK_CRYPTO,  AArch64::AEK_FP,
-  AArch64::AEK_SIMD,AArch64::AEK_FP16,AArch64::AEK_PROFILE,
-  AArch64::AEK_RAS, AArch64::AEK_LSE, AArch64::AEK_RDM,
-  AArch64::AEK_DOTPROD, AArch64::AEK_SVE, AArch64::AEK_SVE2,
-  AArch64::AEK_SVE2AES, AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3,
-  AArch64::AEK_SVE2BITPERM, AArch64::AEK_RCPC,AArch64::AEK_FP16FML,
-  AArch64::AEK_SME, AArch64::AEK_SMEF64,  AArch64::AEK_SMEI64,
-  AArch64::AEK_PERFMON};
+  AArch64::AEK_CRC, AArch64::AEK_LSE,  AArch64::AEK_RDM,
+  AArch64::AEK_CRYPTO,  AArch64::AEK_SM4,  AArch64::AEK_SHA3,
+  AArch64::AEK_SHA2,AArch64::AEK_AES,  AArch64::AEK_DOTPROD,
+  AArch64::AEK_FP,  AArch64::AEK_SIMD, AArch64::AEK_FP16,
+  AArch64::AEK_FP16FML, AArch64::AEK_PROFILE,  AArch64::AEK_RAS,
+  AArch64::AEK_SVE, AArch64::AEK_SVE2, AArch64::AEK_SVE2AES,
+  AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3, AArch64::AEK_SVE2BITPERM,
+  AArch64::AEK_RCPC,AArch64::AEK_RAND, AArch64::AEK_MTE,
+  AArch64::AEK_SSBS,AArch64::AEK_SB,   AArch64::AEK_PREDRES,
+  AArch64::AEK_BF16,AArch64::AEK_I8MM, AArch64::AEK_F32MM,
+  AArch64::AEK_F64MM,   AArch64::AEK_TME,  AArch64::AEK_LS64,
+  AArch64::AEK_BRBE,AArch64::AEK_PAUTH,AArch64::AEK_FLAGM,
+  AArch64::AEK_SME, AArch64::AEK_SMEF64,   AArch64::AEK_SMEI64,
+  AArch64::AEK_HBC, AArch64::AEK_MOPS, AArch64::AEK_PERFMON};
 
   std::vector Features;
 
@@ -1463,34 +1470,65 @@
   for (auto Ext : Extensions)
 ExtVal |= Ext;
 
+  // INVALID and NONE have no feature names.
   EXPECT_FALSE(AArch64::getExtensionFeatures(AArch64::AEK_INVALID, Features));
   EXPECT_TRUE(!Features.size());
+  // We return True here because NONE is a valid choice.
+  EXPECT_TRUE(AArch64::getExtensionFeatures(AArch64::AEK_NONE, Features));
+  EXPECT_TRUE(!Features.size());
 
   AArch64::getExtensionFeatures(ExtVal, Features);
   EXPECT_EQ(Extensions.size(), Features.size());
 
   EXPECT_TRUE(llvm::is_contained(Features, "+crc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
   EXPECT_TRUE(llvm::is_contained(Features, "+crypto"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sm4"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha3"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha2"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+aes"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fp-armv8"));
   EXPECT_TRUE(llvm::is_contained(Features, "+neon"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fullfp16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+spe"));
   EXPECT_TRUE(llvm::is_contained(Features, "+ras"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-aes"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sm4"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sha3"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-bitperm"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rand"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+mte"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+ssbs"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sb"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+predres"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+bf16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+i8mm"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+f32mm

[clang] 55b6a31 - [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-11 Thread David Spickett via cfe-commits

Author: David Spickett
Date: 2022-04-11T13:42:24Z
New Revision: 55b6a3186cfa8b85a1defe05861d73f447e4c990

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

LOG: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

This takes the AARCH64_ARCH_EXT_NAME in AArch64TargetParser.def and uses
it to generate all the "if bit is set add this feature name" code.

Which gives us a bunch that we were missing. I've updated testing
to include those and reordered them to match the order in the .def.

The final part of the test will catch any missing extensions if
we somehow manage to not generate an if block for them.

This has changed the order of cc1's "-target-feature" output so I've
updated some tests in clang to reflect that.

Reviewed By: tmatheson

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

Added: 


Modified: 
clang/test/Preprocessor/aarch64-target-features.c
llvm/lib/Support/AArch64TargetParser.cpp
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/test/Preprocessor/aarch64-target-features.c 
b/clang/test/Preprocessor/aarch64-target-features.c
index ff7e06284a072..f82e89f4fc78d 100644
--- a/clang/test/Preprocessor/aarch64-target-features.c
+++ b/clang/test/Preprocessor/aarch64-target-features.c
@@ -274,30 +274,30 @@
 // RUN: %clang -target aarch64 -mcpu=thunderx2t99 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-THUNDERX2T99 %s
 // RUN: %clang -target aarch64 -mcpu=a64fx -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-A64FX %s
 // RUN: %clang -target aarch64 -mcpu=carmel -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-CARMEL %s
-// CHECK-MCPU-APPLE-A7: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8a" "-target-feature" "+fp-armv8" "-target-feature" 
"+neon" "-target-feature" "+crypto" "-target-feature" "+zcm" "-target-feature" 
"+zcz" "-target-feature" "+sha2" "-target-feature" "+aes"
-// CHECK-MCPU-APPLE-A10: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+fp-armv8" "-target-feature" "+neon" "-target-feature" 
"+crc" "-target-feature" "+crypto" "-target-feature" "+rdm" "-target-feature" 
"+zcm" "-target-feature" "+zcz" "-target-feature" "+sha2" "-target-feature" 
"+aes"
-// CHECK-MCPU-APPLE-A11: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8.2a" "-target-feature" "+fp-armv8" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+fullfp16" "-target-feature" "+ras" "-target-feature" "+lse" "-target-feature" 
"+rdm" "-target-feature" "+zcm" "-target-feature" "+zcz" "-target-feature" 
"+sha2" "-target-feature" "+aes"
-// CHECK-MCPU-APPLE-A12: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8.3a" "-target-feature" "+fp-armv8" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+fullfp16" "-target-feature" "+ras" "-target-feature" "+lse" "-target-feature" 
"+rdm" "-target-feature" "+rcpc" "-target-feature" "+zcm" "-target-feature" 
"+zcz" "-target-feature" "+sha2" "-target-feature" "+aes"
-// CHECK-MCPU-A34: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc"
-// CHECK-MCPU-APPLE-A13: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8.4a" "-target-feature" "+fp-armv8" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+dotprod" "-target-feature" "+fullfp16" "-target-feature" "+ras" 
"-target-feature" "+lse" "-target-feature" "+rdm" "-target-feature" "+rcpc" 
"-target-feature" "+zcm" "-target-feature" "+zcz" "-target-feature" "+fp16fml" 
"-target-feature" "+sm4" "-target-feature" "+sha3" "-target-feature" "+sha2" 
"-target-feature" "+aes"
-// CHECK-MCPU-A35: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto"
-// CHECK-MCPU-A53: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto"
-// CHECK-MCPU-A57: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto"
-// CHECK-MCPU-A72: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto"
-// CHECK-MCPU-CORTEX-A73: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8a" "-target-feature" "+fp-armv8" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
-// CHECK-MCPU-CORTEX-R82: "-cc1"{{.*}} "-triple" "aarch

[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-11 Thread David Spickett 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 rG55b6a3186cfa: [llvm][AArch64] Generate getExtensionFeatures 
from the list of extensions (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123296

Files:
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -12,6 +12,7 @@
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/TargetParser.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 
@@ -1448,14 +1449,20 @@
 
 TEST(TargetParserTest, AArch64ExtensionFeatures) {
   std::vector Extensions = {
-  AArch64::AEK_CRC, AArch64::AEK_CRYPTO,  AArch64::AEK_FP,
-  AArch64::AEK_SIMD,AArch64::AEK_FP16,AArch64::AEK_PROFILE,
-  AArch64::AEK_RAS, AArch64::AEK_LSE, AArch64::AEK_RDM,
-  AArch64::AEK_DOTPROD, AArch64::AEK_SVE, AArch64::AEK_SVE2,
-  AArch64::AEK_SVE2AES, AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3,
-  AArch64::AEK_SVE2BITPERM, AArch64::AEK_RCPC,AArch64::AEK_FP16FML,
-  AArch64::AEK_SME, AArch64::AEK_SMEF64,  AArch64::AEK_SMEI64,
-  AArch64::AEK_PERFMON};
+  AArch64::AEK_CRC, AArch64::AEK_LSE,  AArch64::AEK_RDM,
+  AArch64::AEK_CRYPTO,  AArch64::AEK_SM4,  AArch64::AEK_SHA3,
+  AArch64::AEK_SHA2,AArch64::AEK_AES,  AArch64::AEK_DOTPROD,
+  AArch64::AEK_FP,  AArch64::AEK_SIMD, AArch64::AEK_FP16,
+  AArch64::AEK_FP16FML, AArch64::AEK_PROFILE,  AArch64::AEK_RAS,
+  AArch64::AEK_SVE, AArch64::AEK_SVE2, AArch64::AEK_SVE2AES,
+  AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3, AArch64::AEK_SVE2BITPERM,
+  AArch64::AEK_RCPC,AArch64::AEK_RAND, AArch64::AEK_MTE,
+  AArch64::AEK_SSBS,AArch64::AEK_SB,   AArch64::AEK_PREDRES,
+  AArch64::AEK_BF16,AArch64::AEK_I8MM, AArch64::AEK_F32MM,
+  AArch64::AEK_F64MM,   AArch64::AEK_TME,  AArch64::AEK_LS64,
+  AArch64::AEK_BRBE,AArch64::AEK_PAUTH,AArch64::AEK_FLAGM,
+  AArch64::AEK_SME, AArch64::AEK_SMEF64,   AArch64::AEK_SMEI64,
+  AArch64::AEK_HBC, AArch64::AEK_MOPS, AArch64::AEK_PERFMON};
 
   std::vector Features;
 
@@ -1463,34 +1470,65 @@
   for (auto Ext : Extensions)
 ExtVal |= Ext;
 
+  // INVALID and NONE have no feature names.
   EXPECT_FALSE(AArch64::getExtensionFeatures(AArch64::AEK_INVALID, Features));
   EXPECT_TRUE(!Features.size());
+  // We return True here because NONE is a valid choice.
+  EXPECT_TRUE(AArch64::getExtensionFeatures(AArch64::AEK_NONE, Features));
+  EXPECT_TRUE(!Features.size());
 
   AArch64::getExtensionFeatures(ExtVal, Features);
   EXPECT_EQ(Extensions.size(), Features.size());
 
   EXPECT_TRUE(llvm::is_contained(Features, "+crc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
   EXPECT_TRUE(llvm::is_contained(Features, "+crypto"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sm4"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha3"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha2"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+aes"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fp-armv8"));
   EXPECT_TRUE(llvm::is_contained(Features, "+neon"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fullfp16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+spe"));
   EXPECT_TRUE(llvm::is_contained(Features, "+ras"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-aes"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sm4"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sha3"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-bitperm"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rand"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+mte"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+ssbs"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sb"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+predres"));
+  

[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Type.h:6535
+  const auto *F = Self.getAs();
+  return F == nullptr ||
+ (F->getMethodQuals().empty() && F->getRefQualifier() == RQ_None);

You can turn this into an assert that `F` is not null -- C++ doesn't have the 
notion of functions without a prototype.



Comment at: clang/include/clang/AST/Type.h:6488
+  const auto *F = Self.getAs();
+  return F == nullptr ||
+ (F->getMethodQuals().empty() && F->getRefQualifier() == RQ_None);

cjdb wrote:
> aaron.ballman wrote:
> > cjdb wrote:
> > > aaron.ballman wrote:
> > > > A function without a prototype is referenceable? (This is more of a 
> > > > "should this predicate do anything in C?" kind of question, I suppose.)
> > > Does C++ have a notion of non-prototyped functions? I don't think it 
> > > does? As such, I'm struggling to model this in a way that makes sense :(
> > > 
> > > Maybe that's evidence for NAD, maybe it isn't :shrug:
> > C++ doesn't have the notion of a function without a prototype (thankfully).
> > 
> > Should this function assert that it's not called in C mode at all? I don't 
> > think asking the question makes sense in C.
> I made a change in that this asserts when not in C++ mode.
The assert is fine by me, but I think you're going to need to add a 
`(void)IsCPlusPlus;` to the function (or a `[[maybe_unused]]` to the parameter) 
otherwise non-asserts builds may start to diagnose the unused parameter.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8595
+def err_make_signed_integral_only : Error<
+  "'%select{make_unsigned|make_signed}0' is only compatible with non-bool 
integers and enum types, but was given %1">;
 def ext_typecheck_cond_incompatible_pointers : ExtWarn<

cjdb wrote:
> aaron.ballman wrote:
> > cjdb wrote:
> > > aaron.ballman wrote:
> > > > This can be reformatted, I believe, but did you look around to see if 
> > > > an existing diagnostic would suffice?
> > > Do you have any tips on how to narrow my search? I don't really want to 
> > > //read// 11K lines of diagnostics.
> > I usually search for "typecheck" for type checking diagnostics. One that 
> > looks close is:
> > ```
> > def err_pragma_loop_invalid_argument_type : Error<
> >   "invalid argument of type %0; expected an integer type">;
> > ```
> > that could likely be changed to something along the lines of:
> > ```
> > def err_invalid_argument_type : Error<
> >   "invalid argument of type %0; expected an integer type %select{|other 
> > than 'bool'}1">;
> > ```
> > (I think enum types are always integer types and so they may not need to be 
> > called out in the diagnostic.)
> I'm not particularly fond of this one because it doesn't call out the 
> builtin's user-facing name. I suppose we could do this, but I'm not sure 
> where to draw the line:
> 
> ```
> def err_invalid_argument_type : Error<
>   "invalid argument %select{|for 'make_%select{signed|unsigned}2'}1, with 
> type %0; expected an integer type %select{|other than 'bool'}3">;
> ```
> 
> This means that users who misuse `std::make_[un]signed` will get a nice 
> diagnostic instead of one targeting `__make_[un]signed`, which helps them 
> work out where they can fix their code.
Eh, may as well go with a dedicated diagnostic at that point, that seems like 
it's making the diagnostic far less general.



Comment at: clang/lib/AST/ItaniumMangle.cpp:3928
 break;
+  case UnaryTransformType::AddConst:
+Out << "2ac";

rsmith wrote:
> cjdb wrote:
> > aaron.ballman wrote:
> > > Are these the suggested manglings from the Itanium mangling document, or 
> > > something you invented yourself?
> > > 
> > > Should there be corresponding Microsoft manglings or are those already 
> > > handled magically?
> > > 
> > > Also, test coverage for the manglings?
> > I copied the mangling from D67052 and then inferred for what's missing over 
> > there. I'll consult the Itanium mangling doc to ensure that they're 
> > correct. How can I check the corresponding Microsoft manglings are handled?
> This is mangling the trait as a vendor-specific type *qualifier*, so 
> `__add_lvalue_reference(T)` will demangle as `alref T` instead. The 
> underlying_type trait probably does this because it predates the Itanium ABI 
> having a mangling form for a vendor-specific type *specifier* with arguments. 
> Also, if we want this to demangle properly, we should follow the ABI 
> specification's recommendations and use the actual source name of the 
> builtin. So I think the ideal manglings (other than being kinda long, which 
> probably doesn't matter given that these are unlikely to show up in actual 
> mangled names) would be things like:
> 
> `u13__add_pointerI` ... inner type mangling ... `E`
> 
> It would probably be OK to change the mangling for `__enum_underlying_type` 
> to this form t

[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-11 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added a comment.

@qiongsiwu1 Please also add reviewers from other targets. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123498

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


[clang] 918c5a9 - [Clang] Avoid legacy PM in some tests (NFC)

2022-04-11 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-11T16:15:57+02:00
New Revision: 918c5a926090214bc6843854afb4750673b4c3ae

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

LOG: [Clang] Avoid legacy PM in some tests (NFC)

Either remove legacy PM run lines or change them to use new PM.

Added: 


Modified: 
clang/test/CodeGen/asan-destructor-kind.cpp
clang/test/CodeGen/cfi-icall-cross-dso.c
clang/test/CodeGen/cspgo-instrumentation_thinlto.c
clang/test/CodeGen/dllimport.c
clang/test/CodeGen/enable-split-lto-unit.ll
clang/test/CodeGen/hwasan-stack-safety-analysis.c
clang/test/CodeGen/inline2.c
clang/test/CodeGen/tbaa-for-vptr.cpp

Removed: 




diff  --git a/clang/test/CodeGen/asan-destructor-kind.cpp 
b/clang/test/CodeGen/asan-destructor-kind.cpp
index 8d70b663f67a2..50188067c68b3 100644
--- a/clang/test/CodeGen/asan-destructor-kind.cpp
+++ b/clang/test/CodeGen/asan-destructor-kind.cpp
@@ -6,23 +6,13 @@
 // CHECK-BAD-ARG: invalid value 'bad_arg' in 
'-fsanitize-address-destructor=bad_arg'
 
 // Default is global dtor
-// RUN: %clang_cc1 -fsanitize=address -emit-llvm -o - -triple 
x86_64-apple-macosx10.15 \
-// RUN:   -fno-legacy-pass-manager %s \
-// RUN:   | FileCheck %s --check-prefixes=CHECK-GLOBAL-DTOR
-//
-// RUN: %clang_cc1 -fsanitize=address -emit-llvm -o - -triple 
x86_64-apple-macosx10.15 \
-// RUN:   -flegacy-pass-manager %s \
+// RUN: %clang_cc1 -fsanitize=address -emit-llvm -o - -triple 
x86_64-apple-macosx10.15 %s \
 // RUN:   | FileCheck %s --check-prefixes=CHECK-GLOBAL-DTOR
 
 // Explictly ask for global dtor
 // RUN: %clang_cc1 -fsanitize=address \
 // RUN:   -fsanitize-address-destructor=global -emit-llvm -o - \
-// RUN:   -triple x86_64-apple-macosx10.15 -fno-legacy-pass-manager %s | \
-// RUN:   FileCheck %s --check-prefixes=CHECK-GLOBAL-DTOR
-//
-// RUN: %clang_cc1 -fsanitize=address \
-// RUN:   -fsanitize-address-destructor=global -emit-llvm -o - \
-// RUN:   -triple x86_64-apple-macosx10.15 -flegacy-pass-manager %s | \
+// RUN:   -triple x86_64-apple-macosx10.15 %s | \
 // RUN:   FileCheck %s --check-prefixes=CHECK-GLOBAL-DTOR
 
 // CHECK-GLOBAL-DTOR: llvm.global_dtor{{.+}}asan.module_dtor
@@ -31,12 +21,7 @@
 // Explictly ask for no dtors
 // RUN: %clang_cc1 -fsanitize=address \
 // RUN:   -fsanitize-address-destructor=none -emit-llvm -o - \
-// RUN:   -triple x86_64-apple-macosx10.15 -fno-legacy-pass-manager %s | \
-// RUN:   FileCheck %s --check-prefixes=CHECK-NONE-DTOR
-//
-// RUN: %clang_cc1 -fsanitize=address \
-// RUN:   -fsanitize-address-destructor=none -emit-llvm -o - \
-// RUN:   -triple x86_64-apple-macosx10.15 -flegacy-pass-manager %s | \
+// RUN:   -triple x86_64-apple-macosx10.15 %s | \
 // RUN:   FileCheck %s --check-prefixes=CHECK-NONE-DTOR
 
 int global;

diff  --git a/clang/test/CodeGen/cfi-icall-cross-dso.c 
b/clang/test/CodeGen/cfi-icall-cross-dso.c
index 02399e7b30dc1..deaf12d83fe28 100644
--- a/clang/test/CodeGen/cfi-icall-cross-dso.c
+++ b/clang/test/CodeGen/cfi-icall-cross-dso.c
@@ -1,25 +1,25 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-linux -O1 
-fno-experimental-new-pass-manager \
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-linux -O1 
-fno-inline \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso \
 // RUN:   -fsanitize-cfi-canonical-jump-tables -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK --check-prefix=CHECK-DIAG \
 // RUN:   --check-prefix=ITANIUM --check-prefix=ITANIUM-DIAG \
 // RUN:   %s
 
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-linux -O1 
-fno-experimental-new-pass-manager \
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-linux -O1 
-fno-inline \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso 
-fsanitize-trap=cfi-icall \
 // RUN:   -fsanitize-cfi-canonical-jump-tables -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK \
 // RUN:   --check-prefix=ITANIUM --check-prefix=ITANIUM-TRAP \
 // RUN:   %s
 
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-pc-windows-msvc -O1 
-fno-experimental-new-pass-manager \
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-pc-windows-msvc -O1 
-fno-inline \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso \
 // RUN:   -fsanitize-cfi-canonical-jump-tables -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK --check-prefix=CHECK-DIAG \
 // RUN:   --check-prefix=MS --check-prefix=MS-DIAG \
 // RUN:   %s
 
-// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-pc-windows-msvc -O1 
-fno-experimental-new-pass-manager \
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-pc-windows-msvc -O1 
-fno-inline \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso 
-fsanitize-trap=cfi-icall \

[PATCH] D123405: [dllexport] odr-use constexpr default args for constructor closures

2022-04-11 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

I think @thakis's review is sufficient. I am of course happy to follow up on 
any extra review with follow-up patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123405

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


[clang] 40ad667 - [dllexport] odr-use constexpr default args for constructor closures

2022-04-11 Thread Hans Wennborg via cfe-commits

Author: Hans Wennborg
Date: 2022-04-11T16:23:01+02:00
New Revision: 40ad6670138ab8130a426432b0e94544b5e03642

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

LOG: [dllexport] odr-use constexpr default args for constructor closures

InstantiateDefaultCtorDefaultArgs() is supposed to mark default
constructor args as odr-used, since those args will be used when
emitting the constructor closure.

However, constexpr vars were not getting odr-used since
DoMarkVarDeclReferenced() defers them in MaybeODRUseExprs, and the code
was calling CleanupVarDeclMarking() which discarded those uses instead
of processing them.

(This came up in Chromium, crbug.com/1312086)

Differential revision: https://reviews.llvm.org/D123405

Added: 


Modified: 
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/test/CodeGenCXX/dllexport-ctor-closure.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp 
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index a914ae2e7cb6b..925d6fa04c2c2 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -821,7 +821,7 @@ void 
Sema::InstantiateDefaultCtorDefaultArgs(CXXConstructorDecl *Ctor) {
   for (unsigned I = 0; I != NumParams; ++I) {
 (void)CheckCXXDefaultArgExpr(Attr->getLocation(), Ctor,
Ctor->getParamDecl(I));
-DiscardCleanupsInEvaluationContext();
+CleanupVarDeclMarking();
   }
 }
 

diff  --git a/clang/test/CodeGenCXX/dllexport-ctor-closure.cpp 
b/clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
index 4a639fc14d58c..50cc2237ae2e0 100644
--- a/clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
+++ b/clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
@@ -88,3 +88,10 @@ CtorClosureOutOfLine::CtorClosureOutOfLine(const 
HasImplicitDtor2 &v) {}
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void 
@"??1HasImplicitDtor1@@QAE@XZ"
 // CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FCtorClosureOutOfLine@@QAEXXZ"
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void 
@"??1HasImplicitDtor2@@QAE@XZ"
+
+struct SomeStruct {};
+constexpr SomeStruct kConstexprStruct;
+struct __declspec(dllexport) ConstexprDefaultArg {
+  ConstexprDefaultArg(SomeStruct = kConstexprStruct) {}
+};
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FConstexprDefaultArg@@QAEXXZ"



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


[PATCH] D123405: [dllexport] odr-use constexpr default args for constructor closures

2022-04-11 Thread Hans Wennborg 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 rG40ad6670138a: [dllexport] odr-use constexpr default args for 
constructor closures (authored by hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123405

Files:
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGenCXX/dllexport-ctor-closure.cpp


Index: clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
===
--- clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
+++ clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
@@ -88,3 +88,10 @@
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void 
@"??1HasImplicitDtor1@@QAE@XZ"
 // CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FCtorClosureOutOfLine@@QAEXXZ"
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void 
@"??1HasImplicitDtor2@@QAE@XZ"
+
+struct SomeStruct {};
+constexpr SomeStruct kConstexprStruct;
+struct __declspec(dllexport) ConstexprDefaultArg {
+  ConstexprDefaultArg(SomeStruct = kConstexprStruct) {}
+};
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void 
@"??_FConstexprDefaultArg@@QAEXXZ"
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -821,7 +821,7 @@
   for (unsigned I = 0; I != NumParams; ++I) {
 (void)CheckCXXDefaultArgExpr(Attr->getLocation(), Ctor,
Ctor->getParamDecl(I));
-DiscardCleanupsInEvaluationContext();
+CleanupVarDeclMarking();
   }
 }
 


Index: clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
===
--- clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
+++ clang/test/CodeGenCXX/dllexport-ctor-closure.cpp
@@ -88,3 +88,10 @@
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void @"??1HasImplicitDtor1@@QAE@XZ"
 // CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void @"??_FCtorClosureOutOfLine@@QAEXXZ"
 // CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void @"??1HasImplicitDtor2@@QAE@XZ"
+
+struct SomeStruct {};
+constexpr SomeStruct kConstexprStruct;
+struct __declspec(dllexport) ConstexprDefaultArg {
+  ConstexprDefaultArg(SomeStruct = kConstexprStruct) {}
+};
+// CHECK-LABEL: define weak_odr dso_local dllexport x86_thiscallcc void @"??_FConstexprDefaultArg@@QAEXXZ"
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -821,7 +821,7 @@
   for (unsigned I = 0; I != NumParams; ++I) {
 (void)CheckCXXDefaultArgExpr(Attr->getLocation(), Ctor,
Ctor->getParamDecl(I));
-DiscardCleanupsInEvaluationContext();
+CleanupVarDeclMarking();
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123447: [Clang] Fix unknown type attributes diagnosed twice with [[]] spelling

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

Thank you for the fix! Can you add a release note for it as well?

LGTM aside from a minor nit with some comment wording and a testing suggestion.




Comment at: clang/test/SemaCXX/warn-once-on-unknown-attr.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+void foo() {

Can you also add this RUN line?

`// RUN: %clang_cc1 -fsyntax-only -verify -std=c2x -x c %s`

Then we're verifying that we didn't do anything different for C.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123447

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


[PATCH] D123488: [clangd] IncludeCleaner: Add filtering mechanism

2022-04-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/Config.h:105
+
+/// IncludeCleaner will not diagnose usages of these headers matched by
+/// these regexes.

Config is supposed to be cheap to create.
The regex should be created during compilation and shared across all usages.

Maybe store criteria here as `vector>` here and have 
each function capture a `shared_ptr>` by value?



Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:524
+diag(Warning,
+ llvm::formatv("Incorrect regular expression: {0}", *HeaderPattern)
+ .str(),

nit: invalid, not incorrect (incorrect suggests it's a regular expression that 
expresses the wrong condition)



Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:529
+  }
+  Out.Apply.push_back([&CompiledRegex](const Params &, Config &C) {
+C.Diagnostics.Includes.IgnoreHeader.emplace_back(

you're capturing a reference to a local variable



Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:531
+C.Diagnostics.Includes.IgnoreHeader.emplace_back(
+std::move(CompiledRegex));
+  });

Each time the resulting fragment is evaluated to create a config, we're going 
to move out of `CompiledRegex`. After the first time, there's going to be 
nothing there to move

(apart from the local-variable thing)




Comment at: clang-tools-extra/clangd/ConfigFragment.h:237
+struct IncludesBlock {
+  /// Regexes that will be used to avoid diagnosing certain includes. These
+  /// regexes are anchored on the right and will be matched against the

... as unused or missing.

Second sentence is a bit technical.
"These can match any suffix of the header file in question."?



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:265
+  for (auto &Matcher : IgnoreHeader) {
+if (Matcher.match(Inc.Resolved)) {
+  dlog("{0} header is filterred out", FE->getName());

what are we doing about slashes?
As written, I think we're matching the regex against native paths, which 
doesn't really make sense for checked-in configs.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:266
+if (Matcher.match(Inc.Resolved)) {
+  dlog("{0} header is filterred out", FE->getName());
+  return false;

filterred -> filtered

not enough context in this dlog to be useful I think: filtered out from what?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123488

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-11 Thread Joerg Sonnenberger via Phabricator via cfe-commits
joerg added a comment.

The patch contains at least one user visible change that would be quite 
surprising: it is no longer possible to intentionally set a break point on 
`std::move`.

Thinking more about it, what about a slightly different implementation 
strategy? Provide a compiler built-in `__builtin_std_move`. If it is present, 
libc++ can alias it into `namespace std` using regular C++. Much of the 
name-matching and argument checking in various places disappears. The check to 
skip template instantiation can be done the same way. Over-all, it should be 
much less intrusive with the same performance benefits for an built-in-aware 
STL. It completely side-steps the question of ignoring the actual 
implementation `of std::move` in the source, because there is none.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

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


[PATCH] D123422: [AST] Cleanup on getting the underlying decl of using-shdow decl.

2022-04-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

This looks OK, though I'm not sure the value of encoding this assumption 
further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123422

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


[PATCH] D111548: [Clang] Add the `annotate_type` attribute

2022-04-11 Thread Martin Böhme via Phabricator via cfe-commits
mboehme updated this revision to Diff 421930.
mboehme marked 2 inline comments as done.
mboehme added a comment.

Various changes in response to review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111548

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenCXX/annotate-type.cpp
  clang/test/Sema/annotate-type.c
  clang/test/SemaCXX/annotate-type.cpp
  clang/unittests/AST/AttrTest.cpp

Index: clang/unittests/AST/AttrTest.cpp
===
--- clang/unittests/AST/AttrTest.cpp
+++ clang/unittests/AST/AttrTest.cpp
@@ -7,7 +7,10 @@
 //===--===//
 
 #include "clang/AST/Attr.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Basic/AttrKinds.h"
+#include "clang/Tooling/Tooling.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
@@ -15,10 +18,154 @@
 
 namespace {
 
+using clang::ast_matchers::constantExpr;
+using clang::ast_matchers::equals;
+using clang::ast_matchers::functionDecl;
+using clang::ast_matchers::has;
+using clang::ast_matchers::hasDescendant;
+using clang::ast_matchers::hasName;
+using clang::ast_matchers::integerLiteral;
+using clang::ast_matchers::match;
+using clang::ast_matchers::selectFirst;
+using clang::ast_matchers::stringLiteral;
+using clang::ast_matchers::varDecl;
+using clang::tooling::buildASTFromCode;
+using clang::tooling::buildASTFromCodeWithArgs;
+
 TEST(Attr, Doc) {
   EXPECT_THAT(Attr::getDocumentation(attr::Used).str(),
   testing::HasSubstr("The compiler must emit the definition even "
  "if it appears to be unused"));
 }
 
+const FunctionDecl *getFunctionNode(ASTUnit *AST, const std::string &Name) {
+  auto Result =
+  match(functionDecl(hasName(Name)).bind("fn"), AST->getASTContext());
+  EXPECT_EQ(Result.size(), 1u);
+  return Result[0].getNodeAs("fn");
+}
+
+const VarDecl *getVariableNode(ASTUnit *AST, const std::string &Name) {
+  auto Result = match(varDecl(hasName(Name)).bind("var"), AST->getASTContext());
+  EXPECT_EQ(Result.size(), 1u);
+  return Result[0].getNodeAs("var");
+}
+
+template 
+void AssertAnnotatedAs(TypeLoc TL, llvm::StringRef annotation,
+   ModifiedTypeLoc &ModifiedTL,
+   const AnnotateTypeAttr **AnnotateOut = nullptr) {
+  const auto AttributedTL = TL.getAs();
+  ASSERT_FALSE(AttributedTL.isNull());
+  ModifiedTL = AttributedTL.getModifiedLoc().getAs();
+  ASSERT_TRUE(ModifiedTL);
+
+  ASSERT_NE(AttributedTL.getAttr(), nullptr);
+  const auto *Annotate = dyn_cast(AttributedTL.getAttr());
+  ASSERT_NE(Annotate, nullptr);
+  EXPECT_EQ(Annotate->getAnnotation(), annotation);
+  if (AnnotateOut) {
+*AnnotateOut = Annotate;
+  }
+}
+
+TEST(Attr, AnnotateType) {
+
+  // Test that the AnnotateType attribute shows up in the right places and that
+  // it stores its arguments correctly.
+
+  auto AST = buildASTFromCode(R"cpp(
+void f(int* [[clang::annotate_type("foo", "arg1", 2)]] *,
+   int [[clang::annotate_type("bar")]]);
+
+int [[clang::annotate_type("int")]] * [[clang::annotate_type("ptr")]]
+  array[10] [[clang::annotate_type("arr")]];
+
+void (* [[clang::annotate_type("funcptr")]] fp)(void);
+
+struct S { int mem; };
+int [[clang::annotate_type("int")]]
+S::* [[clang::annotate_type("ptr_to_mem")]] ptr_to_member = &S::mem;
+)cpp");
+
+  {
+const FunctionDecl *Func = getFunctionNode(AST.get(), "f");
+
+// First parameter.
+const auto PointerTL = Func->getParamDecl(0)
+   ->getTypeSourceInfo()
+   ->getTypeLoc()
+   .getAs();
+ASSERT_FALSE(PointerTL.isNull());
+PointerTypeLoc PointerPointerTL;
+const AnnotateTypeAttr *Annotate;
+AssertAnnotatedAs(PointerTL.getPointeeLoc(), "foo", PointerPointerTL,
+  &Annotate);
+
+EXPECT_EQ(Annotate->args_size(), 2);
+const auto *StringLit = selectFirst(
+"str", match(constantExpr(hasDescendant(stringLiteral().bind("str"))),
+ *Annotate->args_begin()[0], AST->getASTContext()));
+ASSERT_NE(StringLit, nullptr);
+EXPECT_EQ(StringLit->getString(), "arg1");
+EXPECT_EQ(match(constantExpr(has(integerLiteral(equals(2)).bind("int"))),
+*Annotate->args_begin()[1], AST->getASTContext())
+  .size(),
+  1);
+
+// Second parameter.
+BuiltinTypeLoc IntTL;
+AssertAnnotatedAs(Func

[PATCH] D121915: [RISCV] CLZ Instruction

2022-04-11 Thread Chang Hu via Phabricator via cfe-commits
joker881 updated this revision to Diff 421931.
joker881 added a comment.
Herald added subscribers: sunshaoce, StephenFan.

[RISCV]CLZ instruction


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121915

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c


Index: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
===
--- clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
@@ -25,3 +25,28 @@
 long orc_b_64(long a) {
   return __builtin_riscv_orc_b_64(a);
 }
+
+
+// RV64ZBB-LABEL: @clz_32(
+// RV64ZBB-NEXT:  entry:
+// RV64ZBB-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// RV64ZBB-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// RV64ZBB-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// RV64ZBB-NEXT:[[TMP1:%.*]] = call i32 @llvm.riscv.clz.i32(i32 [[TMP0]])
+// RV64ZBB-NEXT:ret i32 [[TMP1]]
+//
+int clz_32(int a) {
+  return __builtin_riscv_clz_32(a);
+}
+
+// RV64ZBB-LABEL: @clz_64(
+// RV64ZBB-NEXT:  entry:
+// RV64ZBB-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
+// RV64ZBB-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
+// RV64ZBB-NEXT:[[TMP0:%.*]] = load i64, i64* [[A_ADDR]], align 8
+// RV64ZBB-NEXT:[[TMP1:%.*]] = call i64 @llvm.riscv.clz.i64(i64 [[TMP0]])
+// RV64ZBB-NEXT:ret i64 [[TMP1]]
+//
+long clz_64(long a) {
+  return __builtin_riscv_clz_64(a);
+}
Index: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
===
--- clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
@@ -13,3 +13,14 @@
 int orc_b_32(int a) {
   return __builtin_riscv_orc_b_32(a);
 }
+// RV32ZBB-LABEL: @clz_32(
+// RV32ZBB-NEXT:  entry:
+// RV32ZBB-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// RV32ZBB-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// RV32ZBB-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// RV32ZBB-NEXT:[[TMP1:%.*]] = call i32 @llvm.riscv.clz.i32(i32 [[TMP0]])
+// RV32ZBB-NEXT:ret i32 [[TMP1]]
+//
+int clz_32(int a) {
+  return __builtin_riscv_clz_32(a);
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -18906,7 +18906,11 @@
 case RISCV::BI__builtin_riscv_orc_b_64:
   ID = Intrinsic::riscv_orc_b;
   break;
-
+case RISCV::BI__builtin_riscv_clz_32:
+case RISCV::BI__builtin_riscv_clz_64:{
+  Function *F = CGM.getIntrinsic(Intrinsic::ctlz, Ops[0]->getType());
+  return Builder.CreateCall(F, {Ops[0], Builder.getInt1(false)});
+  }
 // Zbc
 case RISCV::BI__builtin_riscv_clmul:
   ID = Intrinsic::riscv_clmul;
Index: clang/include/clang/Basic/BuiltinsRISCV.def
===
--- clang/include/clang/Basic/BuiltinsRISCV.def
+++ clang/include/clang/Basic/BuiltinsRISCV.def
@@ -18,7 +18,8 @@
 // Zbb extension
 TARGET_BUILTIN(__builtin_riscv_orc_b_32, "ZiZi", "nc", "zbb")
 TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", "zbb,64bit")
-
+TARGET_BUILTIN(__builtin_riscv_clz_32, "ZiZi", "nc", "zbb")
+TARGET_BUILTIN(__builtin_riscv_clz_64, "WiWi", "nc", "zbb,64bit")
 // Zbc or Zbkc extension
 TARGET_BUILTIN(__builtin_riscv_clmul, "LiLiLi", "nc", "zbc|zbkc")
 TARGET_BUILTIN(__builtin_riscv_clmulh, "LiLiLi", "nc", "zbc|zbkc")


Index: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
===
--- clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
@@ -25,3 +25,28 @@
 long orc_b_64(long a) {
   return __builtin_riscv_orc_b_64(a);
 }
+
+
+// RV64ZBB-LABEL: @clz_32(
+// RV64ZBB-NEXT:  entry:
+// RV64ZBB-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// RV64ZBB-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// RV64ZBB-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// RV64ZBB-NEXT:[[TMP1:%.*]] = call i32 @llvm.riscv.clz.i32(i32 [[TMP0]])
+// RV64ZBB-NEXT:ret i32 [[TMP1]]
+//
+int clz_32(int a) {
+  return __builtin_riscv_clz_32(a);
+}
+
+// RV64ZBB-LABEL: @clz_64(
+// RV64ZBB-NEXT:  entry:
+// RV64ZBB-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
+// RV64ZBB-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
+// RV64ZBB-NEXT:[[TMP0:%.*]] = load i64, i64* [[A_ADDR]], align 8
+// RV64ZBB-NEXT:[[TMP1:%.*]] = call i64 @llvm.riscv.clz.i64(i64 [[TMP0]])
+// RV64ZBB-NEXT:ret i64 [[TMP1]]
+//
+long clz_64(long a) {
+  return __builtin_riscv_clz_64(a);
+}
Index: clang/test/CodeGen/RISCV/rvb-in

[PATCH] D122069: [Object] Add binary format for bundling offloading metadata

2022-04-11 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122069

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


[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Daniel Grumberg via Phabricator via cfe-commits
dang updated this revision to Diff 421932.
dang added a comment.

Address code review feedback.

Introduce `has_function_signature` type trait to distinguish records that have a
function signatures.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/ExtractAPI/objc_category.m
  clang/test/ExtractAPI/objc_interface.m

Index: clang/test/ExtractAPI/objc_interface.m
===
--- clang/test/ExtractAPI/objc_interface.m
+++ clang/test/ExtractAPI/objc_interface.m
@@ -182,6 +182,38 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"parameters": [
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Property"
+  }
+],
+"name": "Property"
+  }
+],
+"returns": [
+  {
+"kind": "keyword",
+"spelling": "id"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Super(cm)getWithProperty:"
@@ -288,6 +320,61 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"parameters": [
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Property"
+  }
+],
+"name": "Property"
+  },
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Thing"
+  }
+],
+"name": "Thing"
+  }
+],
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Super(im)setProperty:andOtherThing:"
@@ -551,6 +638,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:C",
+"spelling": "char"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Derived(im)getIvar"
Index: clang/test/ExtractAPI/objc_category.m
===
--- clang/test/ExtractAPI/objc_category.m
+++ clang/test/ExtractAPI/objc_category.m
@@ -148,6 +148,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Interface(im)InstanceMethod"
@@ -212,6 +221,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Interface(cm)ClassMethod"
Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp

[PATCH] D121375: [clang] NFC, move the utility function CompilerInvocation::setLangDefaults to LangOptions.h

2022-04-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.



Comment at: clang/include/clang/Basic/LangStandard.h:141
   static Kind getLangKind(StringRef Name);
+  static Kind getLangKind(clang::Language Lang, const llvm::Triple &T);
+

this makes it sound like a simple getter/lookup, which it absolutely is not!

`getDefaultLanguageStandard`? And separate it out from the simple getters?

(The meaningless distinction in the other function names between "standard" and 
"kind", and the "lang" abbreviation are both pretty unfortunate here, we don't 
need to fix them but let's not propagate them further)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121375

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


[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Daniel Grumberg via Phabricator via cfe-commits
dang added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:495
 
+if (const auto *Method = dyn_cast(Member.get()))
+  serializeObject(*MemberRecord, "functionSignature",

zixuw wrote:
> I'd prefer not to use `dyn_cast` as `MemberTy` here is a concrete type. So 
> maybe a type trait `has_function_signature` and a `if constexpr`?
`if constexpr` is c++17 which we don't support yet? Anyway I added the type 
trait and implemented this a bit lower down the "stack" (in serializeAPIRecord) 
as there are multiple record types that have signatures. This is done using tag 
dispatch based on the trait.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

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


[PATCH] D111548: [Clang] Add the `annotate_type` attribute

2022-04-11 Thread Martin Böhme via Phabricator via cfe-commits
mboehme marked 4 inline comments as done.
mboehme added a comment.

In D111548#3439039 , @aaron.ballman 
wrote:

> Also, you should add a release note about the new attribute

Done.

and check the Precommit CI pipeline failure out:

> Failed Tests (1):
>
>   Clang :: CodeGenCXX/annotate-type.cpp

Fixed.




Comment at: clang/include/clang/Basic/AttrDocs.td:6409-6411
+- The attribute will not cause any additional data to be output to LLVM IR,
+  object files or debug information. It is only intended to be consumed using
+  Clang APIs by source-level static analysis tools such as Clang-Tidy.

aaron.ballman wrote:
> It seems to me that because we found reasons for `annotate` to be lowered to 
> LLVM IR, we'll find reasons to lower `annotate_type` eventually. I worry that 
> if we document this, we'll never be able to modify the attribute to output 
> information to LLVM IR because people will rely on it not doing so and be 
> broken by a change. Are we sure we want to commit to this as part of the 
> design?
Good point. I've done what I think you're implying, namely that we should 
remove the comments saying that the attribute won't have any any effect on the 
LLVM IR?



Comment at: clang/lib/AST/TypePrinter.cpp:1686
+  // would require retrieving the attribute arguments, which we don't have 
here.
+  if (T->getAttrKind() == attr::AnnotateType)
+return;

aaron.ballman wrote:
> mboehme wrote:
> > xazax.hun wrote:
> > > Would it make sense to print something without the arguments? I wonder 
> > > which behavior would be less confusing.
> > TBH I'm not sure. Is TypePrinter used only to produce debug output or is it 
> > required that the output of TypePrinter will parse again correctly?
> > 
> > The reason I'm asking is because `annotate_type` has a mandatory first 
> > argument; if we need the output to be parseable, we would have to print 
> > some dummy string, e.g. `[[clang::annotate_type("arguments_omitted")]]`. 
> > This seems a bit strange, but maybe it's still worth doing. OTOH, if the 
> > output is used only for debugging, I guess we could print something like 
> > `[[clang::annotate_type(...)]]`, which doesn't parse but by that very 
> > nature makes it clear that we don't have all the information here.
> > 
> > I guess both of these options could have limited use -- they would at least 
> > make it clear that there is an annotation on the type, though without the 
> > arguments, we can't know what the actual annotation is.
> > 
> > Would appreciate some more input on the wider context here.
> Yeah, the trouble is that you need a `TypeLoc` in order to get back to the 
> actual attribute information that stores the arguments. But the type printer 
> is printing types not specific instances of types at the location they're 
> used.
> 
> The goal with the pretty printers is to print something back that the user 
> actually wrote, but it's not always possible and so this is sort of a 
> best-effort.
So what's your position -- should I not print the attribute at all (which is 
what I'm doing right now) or should I print it as something like 
`[[clang::annotate_type(...)]]`?



Comment at: clang/lib/Sema/SemaAttr.cpp:396-408
+if (E->getType()->isArrayType())
+  E = ImpCastExprToType(E, Context.getPointerType(E->getType()),
+clang::CK_ArrayToPointerDecay)
+  .get();
+if (E->getType()->isFunctionType())
+  E = ImplicitCastExpr::Create(Context,
+   Context.getPointerType(E->getType()),

aaron.ballman wrote:
> This seems an awful lot like doing `DefaultFunctionArrayLValueConversion()` 
> here -- can you call that to do the heavy lifting?
> 
> Oh, I see we're just shuffling code around. Feel free to ignore or make as an 
> NFC change if you'd prefer.
By "NFC change", you mean I could submit this separately as an NFC change?

Since this change is already part of this patch, I think I'd prefer to just 
keep it in here, if that's OK?



Comment at: clang/test/SemaCXX/annotate-type.cpp:2
+// RUN: %clang_cc1 %s -std=c++17 -fsyntax-only -verify
+
+struct S1 {

aaron.ballman wrote:
> Can you also add some test coverage for applying the attribute to a 
> declaration instead of a type or not giving it any arguments? Also, should 
> test arguments which are not a constant expression.
I've added tests as you suggested, though I put most of them in 
Sema/annotate-type.c, as they're not specific to C++.

Thanks for prompting me to do this -- the tests caused me to notice and fix a 
number of bugs.

I haven't managed to diagnose the case when the attribute appears at the 
beginning of the declaration. It seems to me that, at the point where I've 
added the check, this case is indistinguishable from an attribute that appears 
on the type. In both cases, the `TAL` is `T

[PATCH] D122874: [clang] Add GNU spelling for no_unqiue_address attribute

2022-04-11 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

I actually think that `[[no_unique_address]]` and 
`__attribute__((no_unique_address))` should be equivalent. Similarly, we should 
be able to do `[[msvc::no_unique_address]]` and 
`__attribute__((msvc::no_unique_address))`, and both should be equivalent. 
Which one we pick for use in libc++ is a different issue, and we do it through 
a macro anyway so that we could easily change it in the future if we wanted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122874

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


[clang-tools-extra] 001e88a - [clangd] Performance improvements and cleanup

2022-04-11 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2022-04-11T17:15:25+02:00
New Revision: 001e88ac83b5c3a4d4f4e61480953ebcabc82b88

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

LOG: [clangd] Performance improvements and cleanup

- Inline SymbolID hashing to header
- Don't collect references for symbols without a SymbolID
- Store referenced symbols, rather than separately storing decls and
  macros.
- Don't defer ref collection to end of translation unit
- Perform const_cast when updating reference counts (~0.5% saving)
- Introduce caching for getSymbolID in SymbolCollector. (~30% saving)
- Don't modify symbolslab if there's no definition location
- Don't lex the whole file to deduce spelled tokens, just lex the
  relevant piece (~8%)

Overall this achieves ~38% reduction in time spent inside
SymbolCollector compared to baseline (on my machine :)).

I'd expect the last optimization to affect dynamic index a lot more, I
was testing with clangd-indexer on clangd subfolder of LLVM. As
clangd-indexer runs indexing of whole TU at once, we indeed see almost
every token from every source included in the TU (hence lexing full
files vs just lexing referenced tokens are almost the same), whereas
during dynamic indexing we mostly index main file symbols, but we would
touch the files defining/declaring those symbols, and lex complete files
for nothing, rather than just the token location.

The last optimization is also a functional change (added test),
previously we used raw tokens from syntax::tokenize, which didn't
canonicalize trigraphs/newlines in identifiers, wheres
Lexer::getSpelling canonicalizes them.

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

Added: 


Modified: 
clang-tools-extra/clangd/index/SymbolCollector.cpp
clang-tools-extra/clangd/index/SymbolCollector.h
clang-tools-extra/clangd/index/SymbolID.cpp
clang-tools-extra/clangd/index/SymbolID.h
clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/SymbolCollector.cpp 
b/clang-tools-extra/clangd/index/SymbolCollector.cpp
index 770477220e9be..6153b35edcfdb 100644
--- a/clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ b/clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -21,11 +21,14 @@
 #include "clang/AST/DeclBase.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/DeclarationName.h"
+#include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Index/IndexSymbol.h"
 #include "clang/Lex/Preprocessor.h"
-#include "clang/Tooling/Syntax/Tokens.h"
+#include "clang/Lex/Token.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
@@ -171,6 +174,22 @@ const Decl *getRefContainer(const Decl *Enclosing,
   return Enclosing;
 }
 
+// Check if there is an exact spelling of \p ND at \p Loc.
+bool isSpelled(SourceLocation Loc, const NamedDecl &ND) {
+  auto Name = ND.getDeclName();
+  const auto NameKind = Name.getNameKind();
+  if (NameKind != DeclarationName::Identifier &&
+  NameKind != DeclarationName::CXXConstructorName)
+return false;
+  const auto &AST = ND.getASTContext();
+  const auto &SM = AST.getSourceManager();
+  const auto &LO = AST.getLangOpts();
+  clang::Token Tok;
+  if (clang::Lexer::getRawToken(Loc, Tok, SM, LO))
+return false;
+  auto StrName = Name.getAsString();
+  return clang::Lexer::getSpelling(Tok, SM, LO) == StrName;
+}
 } // namespace
 
 // Encapsulates decisions about how to record header paths in the index,
@@ -545,17 +564,17 @@ bool SymbolCollector::handleDeclOccurrence(
   if (!ND)
 return true;
 
+  auto ID = getSymbolIDCached(ND);
+  if (!ID)
+return true;
+
   // Mark D as referenced if this is a reference coming from the main file.
   // D may not be an interesting symbol, but it's cheaper to check at the end.
   auto &SM = ASTCtx->getSourceManager();
   if (Opts.CountReferences &&
   (Roles & static_cast(index::SymbolRole::Reference)) &&
   SM.getFileID(SM.getSpellingLoc(Loc)) == SM.getMainFileID())
-ReferencedDecls.insert(ND);
-
-  auto ID = getSymbolID(ND);
-  if (!ID)
-return true;
+ReferencedSymbols.insert(ID);
 
   // ND is the canonical (i.e. first) declaration. If it's in the main file
   // (which is not a header), then no public declaration was visible, so assume
@@ -576,13 +595,6 @@ bool SymbolCollector::handleDeclOccurrence(
   processRelations(*ND, ID, Relations);
 
   bool CollectRef = static_cast(Opts.RefFilter & toRefKind(Roles));
-  bool IsOnlyRef =
-  !(Roles & (static_cast(index::SymbolRole::Declaration) |
- static_cast(index::SymbolRole::Defini

[PATCH] D122215: [WebAssembly] Initial support for reference types in clang

2022-04-11 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 421936.
pmatos added a comment.
Herald added subscribers: asavonic, jholewinski.

Moved the attribute handling to the border between clang and llvm.
In the frontend, there's no special handling of address spaces for funcref, but
this is added when converting the values to LLVM types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/WebAssemblyReferenceTypes.def
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/module.modulemap
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGen/WebAssembly/wasm-externref.c
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/CodeGen/builtins-wasm.c
  clang/test/CodeGenCXX/wasm-reftypes-mangle.cpp
  clang/test/CodeGenCXX/wasm-reftypes-typeinfo.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/ValueTypes.cpp
  llvm/lib/IR/Type.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
@@ -404,11 +404,17 @@
 }
 
 //===--===//
-// The following functions are called from lib/CodeGen/Passes.cpp to modify
-// the CodeGen pass sequence.
+// The following functions are called from lib/CodeGen/TargetPassConfig.cpp
+// to modify the CodeGen pass sequence.
 //===--===//
 
 void WebAssemblyPassConfig::addIRPasses() {
+  // Run mem2reg to remove alloca references - needed for reference types
+  // FIXME: this should only be added when the subtarget has reference types 
+  // enabled but the subtarget is dependent on the function being compiled to 
+  // which we don't have access atm.
+  addPass(createPromoteMemoryToRegisterPass());
+
   // Add signatures to prototype-less function declarations
   addPass(createWebAssemblyAddMissingPrototypes());
 
Index: llvm/lib/IR/Type.cpp
===
--- llvm/lib/IR/Type.cpp
+++ llvm/lib/IR/Type.cpp
@@ -304,6 +304,18 @@
   return getInt64Ty(C)->getPointerTo(AS);
 }
 
+Type *Type::getWasm_ExternrefTy(LLVMContext &C) {
+  // pointer to opaque struct in addrspace(10)
+  static PointerType *Ty = PointerType::get(StructType::get(C), 10);
+  return Ty;
+}
+
+Type *Type::getWasm_FuncrefTy(LLVMContext &C) {
+  // pointer to i8 addrspace(20)
+  static PointerType *Ty = PointerType::get(Type::getInt8Ty(C), 20);
+  return Ty;
+}
+
 //===--===//
 //   IntegerType Implementation
 //===--===//
Index: llvm/lib/CodeGen/ValueTypes.cpp
===
--- llvm/lib/CodeGen/ValueTypes.cpp
+++ llvm/lib/CodeGen/ValueTypes.cpp
@@ -201,12 +201,8 @@
   case MVT::x86mmx:  return Type::getX86_MMXTy(Context);
   case MVT::x86amx:  return Type::getX86_AMXTy(Context);
   case MVT::i64x8:   return IntegerType::get(Context, 512);
-  case MVT::externref:
-// pointer to opaque struct in addrspace(10)
-return PointerType::get(StructType::create(Context), 10);
-  case MVT::funcref:
-// pointer to i8 addrspace(20)
-return PointerType::get(Type::getInt8Ty(Context), 20);
+  case MVT::externref: return Type::getWas

[PATCH] D122215: [WebAssembly] Initial support for reference types in clang

2022-04-11 Thread Paulo Matos via Phabricator via cfe-commits
pmatos planned changes to this revision.
pmatos added a comment.

This still requires some changes, as there are a few unhandled cases where 
funcref attribute is not handled properly at the edge.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 421939.
cor3ntin added a comment.

Add a test for `\o'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/Lexer.h
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/FixIt/fixit-unicode-named-escape-sequences.c
  clang/test/Lexer/char-escapes-delimited.c
  clang/test/Lexer/unicode.c
  clang/test/Parser/cxx11-user-defined-literals.cpp
  clang/test/Preprocessor/ucn-pp-identifier.c
  clang/test/Sema/ucn-identifiers.c
  llvm/CMakeLists.txt
  llvm/include/llvm/ADT/StringExtras.h
  llvm/include/llvm/Support/ScopedPrinter.h
  llvm/include/llvm/Support/Unicode.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/ScopedPrinter.cpp
  llvm/lib/Support/StringExtras.cpp
  llvm/lib/Support/UnicodeNameToCodepoint.cpp
  llvm/lib/Support/UnicodeNameToCodepointGenerated.cpp
  llvm/unittests/Support/UnicodeTest.cpp
  llvm/utils/UnicodeData/CMakeLists.txt
  llvm/utils/UnicodeData/UnicodeNameMappingGenerator.cpp

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


[PATCH] D122931: [CMake][compiler-rt] Support for using in-tree libc++

2022-04-11 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

I like this, however IMO it would be better to instead have something like

  COMPILER_RT_CXX_LIBRARY="libc++|system-libc++|libstdc++|..."

That way, this can be extended to support other C++ libraries without having to 
add new boolean options, and without forcing folks to use ad-hoc 
`CMAKE_CXX_FLAGS` in their builds. WDYT?




Comment at: compiler-rt/CMakeLists.txt:513-515
+# Don't use libcxx if LLVM_ENABLE_PROJECTS does not enable it.
+set(COMPILER_RT_LIBCXX_PATH ${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR})
+set(COMPILER_RT_LIBCXXABI_PATH ${LLVM_EXTERNAL_LIBCXXABI_SOURCE_DIR})

I'm not sure I follow here -- we don't support using 
`LLVM_ENABLE_PROJECTS=libcxx` anymore.



Comment at: compiler-rt/CMakeLists.txt:517-534
+foreach(path IN ITEMS ${LLVM_MAIN_SRC_DIR}/projects/libcxx
+  ${LLVM_MAIN_SRC_DIR}/runtimes/libcxx
+  ${LLVM_MAIN_SRC_DIR}/../libcxx
+  ${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR})
+  if(IS_DIRECTORY ${path})
+set(COMPILER_RT_LIBCXX_PATH ${path})
+break()

Is there any reason why this can't be hardcoded to 
`${LLVM_MAIN_SRC_DIR}/.../libcxx`? Why do we need to handle the other layouts?

Edit: Oh, I see, this was only moved around. I assume you prefer making these 
other changes in separate patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122931

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


[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood added a comment.

In D123479#3442062 , @njames93 wrote:

> Would it not be better if these parens were stripped in the fixit as they are 
> unnecessary in the enum value decl?

I prefer checks to do one thing only in a straightforward manner.

It's easier to place things before and after the macro expansion rather than 
modify the contents
of the expansion.

It doesn't feel like the responsibility of this check is to decide which 
parentheses are necessary or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123479

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: aaron.ballman, tahonermann, clang-language-wg.
aaron.ballman added subscribers: tstellar, lattner.
aaron.ballman added a comment.

Thank you for this functionality! I did a pretty quick pass over it and have 
some comments.




Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:130-131
 
 def ext_delimited_escape_sequence : Extension<
-  "delimited escape sequences are a Clang extension">,
+  "%select{delimited|named}0 escape sequences are a Clang extension">,
   InGroup>;

cor3ntin wrote:
> tahonermann wrote:
> > I don't see much value in combining these diagnostics since these are 
> > distinct features. The `ext_delimited_escape_sequence` name seems odd for 
> > named escape sequences too (even if both features use `{` and `}` as 
> > delimiters).
> I'm used to @aaron.ballman encouraging me to keep the number of diagnostics 
> under control, but I'm fine keeping them separate 
While Tom's right that they're distinct features, diagnostics aren't tied 
directly to a feature in Clang; we try to reuse existing diagnostic text as 
much as possible. My preference is to keep them combined so we reduce the 
number of strings we build into the executable (and we make life easier for 
eventual localization of the diagnostics).



Comment at: clang/lib/Lex/Lexer.cpp:3139
   Diag(SlashLoc, diag::warn_ucn_not_valid_in_c89);
-return 0;
+return {};
   }

FWIW, I think using `llvm::None` instead of `{}` is more clear to readers (I 
doubt we're consistent with this in the code base though).

(Same comment applies other places that we're making an empty `Optional`.)



Comment at: clang/lib/Lex/Lexer.cpp:3226
+llvm::Optional Lexer::tryReadNamedUCN(const char *&StartPtr,
+const char *, Token *Result) {
+  unsigned CharSize;





Comment at: clang/lib/Lex/Lexer.cpp:3237-3239
+  if (C != '{') {
+if (Diagnose)
+  Diag(StartPtr, diag::warn_ucn_escape_incomplete);

Is this a case where we might want a fixit because the user did `\N` when they 
meant to do `\n`?

(Should we look for `\N(` and fixit that to `\N{`?)



Comment at: clang/lib/Lex/Lexer.cpp:3290
+// and we should not make invalid suggestions.
+  }
+

I think it'd be more clear to set `Res = LooseMatch->CodePoint;` before exiting 
here so that after this block, you can always assume there's a valid code point 
(this helps if we later want to add more logic after this point, too).



Comment at: clang/lib/Lex/Lexer.cpp:3292-3294
+  if (Diagnose && PP && !LooseMatch) {
+Diag(BufferPtr, diag::ext_delimited_escape_sequence) << /*named*/ 1;
+  }





Comment at: clang/lib/Lex/Lexer.cpp:3305
+  }
+  return Res ? *Res : LooseMatch->CodePoint;
+}

Then this can become `return *Res;`



Comment at: clang/lib/Lex/Lexer.cpp:3315-3317
+CodePointOpt = tryReadNumericUCN(StartPtr, SlashLoc, Result);
+
+  else if (Kind == 'N')





Comment at: clang/lib/Lex/Lexer.cpp:3325-3327
+  if (Result) {
+Result->setFlag(Token::HasUCN);
+  }

I think this should live inside the other `tryRead*` functions once we know the 
token is definitely a UCN, in case someone finds a reason to want to call one 
of those concretely but not call `tryReadUCN()` to do so.



Comment at: clang/lib/Lex/LiteralSupport.cpp:238
+ diag::err_delimited_escape_missing_brace)
+<< std::string(1, 'o');
 

Can you use `"o"` instead of constructing a `std::string` for it?



Comment at: clang/lib/Lex/LiteralSupport.cpp:362
+  assert(Delim != Input.end());
+  auto Res = llvm::sys::unicode::nameToCodepointLooseMatching(
+  StringRef(I, std::distance(I, Delim)));

Please spell out the type for `Res` as it's not obvious from context what it is.



Comment at: clang/lib/Lex/LiteralSupport.cpp:400-406
   const char *UcnBegin = ThisTokBuf;
-
   // Skip the '\u' char's.
   ThisTokBuf += 2;
-
-  bool Delimited = false;
-  bool EndDelimiterFound = false;
   bool HasError = false;
 
+  Delimited = false;
+  bool EndDelimiterFound = false;

Might as well clean this up a bit more



Comment at: clang/lib/Lex/LiteralSupport.cpp:488
+
+  auto Res = llvm::sys::unicode::nameToCodepointLooseMatching(Name);
+  if (Res) {

Please spell the type out.



Comment at: clang/lib/Lex/LiteralSupport.cpp:500
+  unsigned Distance = 0;
+  auto Matches = llvm::sys::unicode::nearestMatchesForCodepointName(Name, 5);
+  assert(!Matches.empty() && "No unicode characters found");

Same here.



Comment at: clang/lib/Lex/LiteralSupport.cpp:501

Re: [PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-11 Thread Aaron Ballman via cfe-commits
On Mon, Apr 11, 2022 at 10:50 AM Joerg Sonnenberger via Phabricator
 wrote:
>
> joerg added a comment.
>
> The patch contains at least one user visible change that would be quite 
> surprising: it is no longer possible to intentionally set a break point on 
> `std::move`.

Thank you, that is a really good point. It would be a surprise to set
a breakpoint on the code I can see in debug mode (-O0 -g) and never
hit the breakpoint.

> Thinking more about it, what about a slightly different implementation 
> strategy? Provide a compiler built-in `__builtin_std_move`. If it is present, 
> libc++ can alias it into `namespace std` using regular C++. Much of the 
> name-matching and argument checking in various places disappears. The check 
> to skip template instantiation can be done the same way. Over-all, it should 
> be much less intrusive with the same performance benefits for an 
> built-in-aware STL. It completely side-steps the question of ignoring the 
> actual implementation `of std::move` in the source, because there is none.

This is a pretty neat idea that seems worth exploring; it certainly
makes me more comfortable than adding comment line options that
suggest users can reliably modify things in namespace std. Thanks for
the suggestion!

~Aaron

>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D123345/new/
>
> https://reviews.llvm.org/D123345
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D121915: [RISCV] CLZ Instruction

2022-04-11 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:18910
+case RISCV::BI__builtin_riscv_clz_32:
+case RISCV::BI__builtin_riscv_clz_64:{
+  Function *F = CGM.getIntrinsic(Intrinsic::ctlz, Ops[0]->getType());

Add a space before the opening curly brace



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:18913
+  return Builder.CreateCall(F, {Ops[0], Builder.getInt1(false)});
+  }
 // Zbc

Fix the clang-format warning here



Comment at: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c:21
+// RV32ZBB-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// RV32ZBB-NEXT:[[TMP1:%.*]] = call i32 @llvm.riscv.clz.i32(i32 [[TMP0]])
+// RV32ZBB-NEXT:ret i32 [[TMP1]]

There is no llvm.riscv.clz.i32 intrinsic. Was this test not updated?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121915

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Chris Lattner via Phabricator via cfe-commits
lattner added a comment.

Yeah, we should discuss this, thanks for raising this Aaron.  I'm not sure 
exactly what is being pulled in: @cor3ntin can you please email a summary of 
the situation to bo...@llvm.org and we'll discuss it and run it by Heather as 
needed?  Thanks

-Chris


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

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


[PATCH] D107636: [analyzer][solver] Compute adjustment for unsupported symbols as well

2022-04-11 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.
Herald added a project: All.

I checked the tests file on the latest sources. It passes even without your 
changes. Maybe this patch is already outdated.




Comment at: clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp:82-86
   if (IsExpectedEqual) {
 return assumeSymNE(State, CanonicalEquality, Zero, Zero);
   }
 
   return assumeSymEQ(State, CanonicalEquality, Zero, Zero);

Do we need the same changes here as below?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107636

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


[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-11 Thread Thomas Lively via Phabricator via cfe-commits
tlively added a comment.

No concerns about the WebAssembly changes. Will the default installation for 
folks who don't touch `LLVM_DISTRIBUTION_COMPONENTS` change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123498

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


[PATCH] D122243: [analyzer][NFC] Introduce the checker package separator character

2022-04-11 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov accepted this revision.
ASDenysPetrov added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122243

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


[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Zixu Wang via Phabricator via cfe-commits
zixuw added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:495
 
+if (const auto *Method = dyn_cast(Member.get()))
+  serializeObject(*MemberRecord, "functionSignature",

dang wrote:
> zixuw wrote:
> > I'd prefer not to use `dyn_cast` as `MemberTy` here is a concrete type. So 
> > maybe a type trait `has_function_signature` and a `if constexpr`?
> `if constexpr` is c++17 which we don't support yet? Anyway I added the type 
> trait and implemented this a bit lower down the "stack" (in 
> serializeAPIRecord) as there are multiple record types that have signatures. 
> This is done using tag dispatch based on the trait.
Hmm.. That's a bummer. Didn't realize that when I made the suggestion. I 
actually don't have that strong an opinion regarding the `dyn_cast`.
What do you think? Do you think it's still worth going through all these to get 
the type trait working?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

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


[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-11 Thread Qiongsi Wu via Phabricator via cfe-commits
qiongsiwu1 added a comment.

In D123498#3443108 , @tlively wrote:

> No concerns about the WebAssembly changes. Will the default installation for 
> folks who don't touch `LLVM_DISTRIBUTION_COMPONENTS` change?

Thanks Thomas! No, the default installations that use `clang-resource-headers` 
(e.g. here 
)
 do not change. This PR //adds// new targets without changing the contents of 
the existing `clang-resource-headers` target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123498

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


[PATCH] D121375: [clang] NFC, move the utility function CompilerInvocation::setLangDefaults to LangOptions.h

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM once @sammccall 's new comments are addressed!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121375

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 421956.
cor3ntin marked 17 inline comments as done.
cor3ntin added a comment.

Address Aaron's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/Lexer.h
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/FixIt/fixit-unicode-named-escape-sequences.c
  clang/test/Lexer/char-escapes-delimited.c
  clang/test/Lexer/unicode.c
  clang/test/Parser/cxx11-user-defined-literals.cpp
  clang/test/Preprocessor/ucn-pp-identifier.c
  clang/test/Sema/ucn-identifiers.c
  llvm/CMakeLists.txt
  llvm/include/llvm/ADT/StringExtras.h
  llvm/include/llvm/Support/ScopedPrinter.h
  llvm/include/llvm/Support/Unicode.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/ScopedPrinter.cpp
  llvm/lib/Support/StringExtras.cpp
  llvm/lib/Support/UnicodeNameToCodepoint.cpp
  llvm/lib/Support/UnicodeNameToCodepointGenerated.cpp
  llvm/unittests/Support/UnicodeTest.cpp
  llvm/utils/UnicodeData/CMakeLists.txt
  llvm/utils/UnicodeData/UnicodeNameMappingGenerator.cpp

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 421958.
cor3ntin added a comment.

Cleanup generated code header comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/Lexer.h
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/FixIt/fixit-unicode-named-escape-sequences.c
  clang/test/Lexer/char-escapes-delimited.c
  clang/test/Lexer/unicode.c
  clang/test/Parser/cxx11-user-defined-literals.cpp
  clang/test/Preprocessor/ucn-pp-identifier.c
  clang/test/Sema/ucn-identifiers.c
  llvm/CMakeLists.txt
  llvm/include/llvm/ADT/StringExtras.h
  llvm/include/llvm/Support/ScopedPrinter.h
  llvm/include/llvm/Support/Unicode.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/ScopedPrinter.cpp
  llvm/lib/Support/StringExtras.cpp
  llvm/lib/Support/UnicodeNameToCodepoint.cpp
  llvm/lib/Support/UnicodeNameToCodepointGenerated.cpp
  llvm/unittests/Support/UnicodeTest.cpp
  llvm/utils/UnicodeData/CMakeLists.txt
  llvm/utils/UnicodeData/UnicodeNameMappingGenerator.cpp

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


[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Daniel Grumberg via Phabricator via cfe-commits
dang marked an inline comment as done.
dang added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:495
 
+if (const auto *Method = dyn_cast(Member.get()))
+  serializeObject(*MemberRecord, "functionSignature",

zixuw wrote:
> dang wrote:
> > zixuw wrote:
> > > I'd prefer not to use `dyn_cast` as `MemberTy` here is a concrete type. 
> > > So maybe a type trait `has_function_signature` and a `if constexpr`?
> > `if constexpr` is c++17 which we don't support yet? Anyway I added the type 
> > trait and implemented this a bit lower down the "stack" (in 
> > serializeAPIRecord) as there are multiple record types that have 
> > signatures. This is done using tag dispatch based on the trait.
> Hmm.. That's a bummer. Didn't realize that when I made the suggestion. I 
> actually don't have that strong an opinion regarding the `dyn_cast`.
> What do you think? Do you think it's still worth going through all these to 
> get the type trait working?
I think it is still worth it, so that we can emit function signatures in 
APIRecord as multiple types of records need them (and the list of records will 
keep growing). This could be a useful way of dealing with things like 
availability information as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

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


[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-11 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.
This revision is now accepted and ready to land.

this LGTM from a systemz perspective! thanks for refactoring




Comment at: clang/lib/Headers/CMakeLists.txt:173
   __wmmintrin_pclmul.h
   x86gprintrin.h
   x86intrin.h

nit: There are some x86 headers here that appear to be x86 only. Should these 
be moved to x86_files list?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123498

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


[PATCH] D123468: [Driver] Simplify hasFlag pattern with addOptInFlag/addOptOutFlag helpers

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

Nice! LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123468

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


[PATCH] D123398: [VFS] RedirectingFileSystem only replace path if not already mapped

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D123398#3439946 , @bnbarham wrote:

> Does `clang/test/VFS/external-names-multi-overlay.c` need to be formatted or 
> is it fine? It uses split-file so I'd really like to avoid the format here 
> (makes it pretty silly).

Seems fine to ignore. If it bothers you I think you can add a comment to 
silence it (I'm not sure how to spell it, but probably something similar to `// 
clang-format off`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123398

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


[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Zixu Wang via Phabricator via cfe-commits
zixuw accepted this revision.
zixuw added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

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


[PATCH] D123398: [VFS] RedirectingFileSystem only replace path if not already mapped

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123398

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/Lex/LiteralSupport.cpp:238
+ diag::err_delimited_escape_missing_brace)
+<< std::string(1, 'o');
 

aaron.ballman wrote:
> Can you use `"o"` instead of constructing a `std::string` for it?
Why do simple when you can do complicated?



Comment at: clang/lib/Lex/LiteralSupport.cpp:501
+  auto Matches = llvm::sys::unicode::nearestMatchesForCodepointName(Name, 5);
+  assert(!Matches.empty() && "No unicode characters found");
+

aaron.ballman wrote:
> Just double checking that the assertion here is valid and the function can 
> never return an empty set.
you should always get some result yes, at it find all the characters with the 
smallest edit distance



Comment at: llvm/include/llvm/ADT/StringExtras.h:329
 
+std::string to_hexString(uint64_t Value, bool UpperCase = true);
+

aaron.ballman wrote:
> `utohexstr()` already exists on line 152 -- any reason we can't reuse that?
I guess I missed that. Why do we have 2 functions doing the same thing?
How do you want me to clean that up?
I think we should have a separate nfc patch to clean that afterwards


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

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


[PATCH] D123064: [Clang][C++23] P2071 Named universal character escapes

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: llvm/include/llvm/ADT/StringExtras.h:329
 
+std::string to_hexString(uint64_t Value, bool UpperCase = true);
+

cor3ntin wrote:
> aaron.ballman wrote:
> > `utohexstr()` already exists on line 152 -- any reason we can't reuse that?
> I guess I missed that. Why do we have 2 functions doing the same thing?
> How do you want me to clean that up?
> I think we should have a separate nfc patch to clean that afterwards
In this patch, I'd replace your new calls to `to_hexString()` with calls to 
`utohexstr()` and then in an NFC change, I'd get rid of `to_hexString()` 
entirely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123064

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


[PATCH] D123526: [clang][ExtractAPI][NFC] Fix sed delimiter in test

2022-04-11 Thread Zixu Wang via Phabricator via cfe-commits
zixuw created this revision.
Herald added a reviewer: dang.
Herald added a project: All.
zixuw requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fix path replacement in sed (properly this time) using lit
regex_replacement.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123526

Files:
  clang/test/ExtractAPI/enum.c
  clang/test/ExtractAPI/global_record.c
  clang/test/ExtractAPI/global_record_multifile.c
  clang/test/ExtractAPI/known_files_only.c
  clang/test/ExtractAPI/known_files_only_hmap.c
  clang/test/ExtractAPI/language.c
  clang/test/ExtractAPI/macro_undefined.c
  clang/test/ExtractAPI/macros.c
  clang/test/ExtractAPI/objc_category.m
  clang/test/ExtractAPI/objc_interface.m
  clang/test/ExtractAPI/objc_protocol.m
  clang/test/ExtractAPI/struct.c
  clang/test/ExtractAPI/typedef.c
  clang/test/ExtractAPI/typedef_anonymous_record.c
  clang/test/ExtractAPI/typedef_chain.c

Index: clang/test/ExtractAPI/typedef_chain.c
===
--- clang/test/ExtractAPI/typedef_chain.c
+++ clang/test/ExtractAPI/typedef_chain.c
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api --product-name=TypedefChain -target arm64-apple-macosx \
 // RUN: -x objective-c-header %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/typedef_anonymous_record.c
===
--- clang/test/ExtractAPI/typedef_anonymous_record.c
+++ clang/test/ExtractAPI/typedef_anonymous_record.c
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api --product-name=TypedefChain -target arm64-apple-macosx \
 // RUN: -x objective-c-header %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/typedef.c
===
--- clang/test/ExtractAPI/typedef.c
+++ clang/test/ExtractAPI/typedef.c
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api --product-name=Typedef -target arm64-apple-macosx \
 // RUN: -x objective-c-header %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/struct.c
===
--- clang/test/ExtractAPI/struct.c
+++ clang/test/ExtractAPI/struct.c
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api -target arm64-apple-macosx \
 // RUN: %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/objc_protocol.m
===
--- clang/test/ExtractAPI/objc_protocol.m
+++ clang/test/ExtractAPI/objc_protocol.m
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api -x objective-c-header -target arm64-apple-macosx \
 // RUN: %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/objc_interface.m
===
--- clang/test/ExtractAPI/objc_interface.m
+++ clang/test/ExtractAPI/objc_interface.m
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: split-file %s %t
-// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
-// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
 // RUN: %clang -extract-api -x objective-c-header -target arm64-apple-macosx \
 // RUN: %t/input.h -o %t/output.json | FileCheck -allow-empty %s
 
Index: clang/test/ExtractAPI/objc_category.m
===
--- clang/test/ExtractAPI/objc_category.m
+++ clang/test/ExtractAPI/objc_cat

[clang] 236b6a0 - [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Daniel Grumberg via cfe-commits

Author: Daniel Grumberg
Date: 2022-04-11T19:05:24+01:00
New Revision: 236b6a0eb41a163510e65664e2160f599287326b

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

LOG: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

- Split GlobalRecord into two distinct types to be able to introduce
has_function_signature type trait.
- Add has_function_signature type trait.
- Serialize function signatures as part of serializeAPIRecord for
records that are known to have a function signature.

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

Added: 


Modified: 
clang/include/clang/ExtractAPI/API.h
clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
clang/lib/ExtractAPI/API.cpp
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
clang/test/ExtractAPI/objc_category.m
clang/test/ExtractAPI/objc_interface.m

Removed: 




diff  --git a/clang/include/clang/ExtractAPI/API.h 
b/clang/include/clang/ExtractAPI/API.h
index 57b6a2ee5a43c..6a9429704d45e 100644
--- a/clang/include/clang/ExtractAPI/API.h
+++ b/clang/include/clang/ExtractAPI/API.h
@@ -77,7 +77,8 @@ struct APIRecord {
 
   /// Discriminator for LLVM-style RTTI (dyn_cast<> et al.)
   enum RecordKind {
-RK_Global,
+RK_GlobalFunction,
+RK_GlobalVariable,
 RK_EnumConstant,
 RK_Enum,
 RK_StructField,
@@ -112,31 +113,40 @@ struct APIRecord {
   virtual ~APIRecord() = 0;
 };
 
-/// The kind of a global record.
-enum class GVKind : uint8_t {
-  Unknown = 0,
-  Variable = 1,
-  Function = 2,
-};
+/// This holds information associated with global functions.
+struct GlobalFunctionRecord : APIRecord {
+  FunctionSignature Signature;
 
-/// This holds information associated with global variables or functions.
-struct GlobalRecord : APIRecord {
-  GVKind GlobalKind;
+  GlobalFunctionRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+   const AvailabilityInfo &Availability,
+   LinkageInfo Linkage, const DocComment &Comment,
+   DeclarationFragments Declaration,
+   DeclarationFragments SubHeading,
+   FunctionSignature Signature)
+  : APIRecord(RK_GlobalFunction, Name, USR, Loc, Availability, Linkage,
+  Comment, Declaration, SubHeading),
+Signature(Signature) {}
 
-  /// The function signature of the record if it is a function.
-  FunctionSignature Signature;
+  static bool classof(const APIRecord *Record) {
+return Record->getKind() == RK_GlobalFunction;
+  }
 
-  GlobalRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
-   const AvailabilityInfo &Availability, LinkageInfo Linkage,
-   const DocComment &Comment, DeclarationFragments Declaration,
-   DeclarationFragments SubHeading, GVKind Kind,
-   FunctionSignature Signature)
-  : APIRecord(RK_Global, Name, USR, Loc, Availability, Linkage, Comment,
-  Declaration, SubHeading),
-GlobalKind(Kind), Signature(Signature) {}
+private:
+  virtual void anchor();
+};
+
+/// This holds information associated with global functions.
+struct GlobalVariableRecord : APIRecord {
+  GlobalVariableRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+   const AvailabilityInfo &Availability,
+   LinkageInfo Linkage, const DocComment &Comment,
+   DeclarationFragments Declaration,
+   DeclarationFragments SubHeading)
+  : APIRecord(RK_GlobalVariable, Name, USR, Loc, Availability, Linkage,
+  Comment, Declaration, SubHeading) {}
 
   static bool classof(const APIRecord *Record) {
-return Record->getKind() == RK_Global;
+return Record->getKind() == RK_GlobalVariable;
   }
 
 private:
@@ -446,33 +456,31 @@ struct TypedefRecord : APIRecord {
   virtual void anchor();
 };
 
+/// Check if a record type has a function signature mixin.
+///
+/// This is denoted by the record type having a ``Signature`` field of type
+/// FunctionSignature.
+template 
+struct has_function_signature : public std::false_type {};
+template <>
+struct has_function_signature : public std::true_type {};
+template <>
+struct has_function_signature : public std::true_type {};
+
 /// APISet holds the set of API records collected from given inputs.
 class APISet {
 public:
-  /// Create and add a GlobalRecord of kind \p Kind into the API set.
-  ///
-  /// Note: the caller is responsible for keeping the StringRef \p Name and
-  /// \p USR alive. APISet::copyString provides a way to copy strings into
-  /// APISet itself, and APISet::recordUSR(const Decl *D) is a helper method
-  /// to generat

[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-11 Thread Daniel Grumberg via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
dang marked an inline comment as done.
Closed by commit rG236b6a0eb41a: [clang][extract-api] Emit 
"functionSignature" in SGF for ObjC methods. (authored by dang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123304

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/ExtractAPI/objc_category.m
  clang/test/ExtractAPI/objc_interface.m

Index: clang/test/ExtractAPI/objc_interface.m
===
--- clang/test/ExtractAPI/objc_interface.m
+++ clang/test/ExtractAPI/objc_interface.m
@@ -182,6 +182,38 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"parameters": [
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Property"
+  }
+],
+"name": "Property"
+  }
+],
+"returns": [
+  {
+"kind": "keyword",
+"spelling": "id"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Super(cm)getWithProperty:"
@@ -288,6 +320,61 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"parameters": [
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Property"
+  }
+],
+"name": "Property"
+  },
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ") "
+  },
+  {
+"kind": "internalParam",
+"spelling": "Thing"
+  }
+],
+"name": "Thing"
+  }
+],
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Super(im)setProperty:andOtherThing:"
@@ -551,6 +638,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:C",
+"spelling": "char"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Derived(im)getIvar"
Index: clang/test/ExtractAPI/objc_category.m
===
--- clang/test/ExtractAPI/objc_category.m
+++ clang/test/ExtractAPI/objc_category.m
@@ -148,6 +148,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Interface(im)InstanceMethod"
@@ -212,6 +221,15 @@
   "spelling": ";"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Inte

[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

In D123479#3442968 , 
@LegalizeAdulthood wrote:

> In D123479#3442062 , @njames93 
> wrote:
>
>> Would it not be better if these parens were stripped in the fixit as they 
>> are unnecessary in the enum value decl?

To me, that would be ideal, but not strictly necessary (and perhaps doesn't 
scale super well across all fix-its) because the code is still correct with the 
parens, just a bit ugly. We have other similar situations with fix-its (like 
formatting).

> I prefer checks to do one thing only in a straightforward manner.
>
> It's easier to place things before and after the macro expansion rather than 
> modify the contents
> of the expansion.
>
> It doesn't feel like the responsibility of this check is to decide which 
> parentheses are necessary or not.

Hmm, I'm more on the fence. On the one hand, yes. On the other hand, there's no 
automatic cleanup to remove parentheses in clang-format (and there's no way I 
would trust clang-format if it added one, frankly). This check is suggesting a 
fix-it and a fix-it that keeps the parentheses means the user may feel 
compelled to go and manually change their code anyway, which largely removes 
the benefit of having a fix-it in the first place. That said, the fix-it 
produces correct code, and we could add a readability-redundant-parentheses 
check to clang-tidy if we cared deeply about redundant parens. We've had at 
least one attempt at that I could remember (and I hazily recall there may have 
been a second attempt), so there's some interest in that. That would solve the 
problem in a more general way than expecting each author of a fix-it to 
consider parens individually.

Regardless, this is incremental progress and it solves a real bug. LGTM aside 
from reflowing a comment.




Comment at: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp:351-354
+for (; Begin < MacroTokens.size() / 2; ++Begin, --End) {
+  if (!MacroTokens[Begin].is(tok::TokenKind::l_paren) ||
+  !MacroTokens[End].is(tok::TokenKind::r_paren))
+break;

Start at both ends and work towards the middle. This is clever, I like this!



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst:20-23
+  The above expressions may also be surrounded by a single matching pair of
+  parentheses.
+  More complicated integral constant expressions are not currently recognized
+  by this check.

Reflowing the comment to 80 cols


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123479

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


[PATCH] D123104: [Modules] Use looked-up filename when looking for module maps

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D123104#3439261 , @bnbarham wrote:

> Looks like there's more changes required for modulemap-collision.m to 
> actually pass. I'll try figure those out when I have the time.

Capturing `clang -check` error since the build log won't be available forever:

  error: 'warning' diagnostics seen but not expected: 
  
File 
/var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/test/Modules/Output/modulemap-collision.m.tmp/build/module.private.modulemap
 Line 1: private submodule 'A.Private' in private module map, expected 
top-level module
  
  error: 'note' diagnostics seen but not expected: 
  
File 
/var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/test/Modules/Output/modulemap-collision.m.tmp/build/module.private.modulemap
 Line 1: rename 'A.Private' to ensure it can be found by name

I wonder if 
https://github.com/apple/llvm-project/commit/67c70038bcc0d771e2e39c875ad7d69e329c7fc4
 could be related. A long shot (I can't see how that could be it!), but the 
other not-upstreamed patches look even less relevant.




Comment at: clang/test/Modules/modulemap-collision.m:12
+// RUN: sed -e "s:DUMMY_DIR:%t:g" %S/Inputs/all-product-headers.yaml > 
%t/build/all-product-headers.yaml
+// RUN: %clang_cc1 -fsyntax-only -ivfsoverlay 
%t/build/all-product-headers.yaml -F%t/build -fmodules -fimplicit-module-maps 
-fmodules-cache-path=tmp -x objective-c %s -verify
+

Just noticed `-fmodules-cache-path=tmp`, which seems like it should be 
`=%t/cache` instead... but I doubt that's the cause of the failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123104

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


[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood marked 2 inline comments as done.
LegalizeAdulthood added a comment.

In D123479#3443401 , @aaron.ballman 
wrote:

> In D123479#3442968 , 
> @LegalizeAdulthood wrote:
>
>> In D123479#3442062 , @njames93 
>> wrote:
>>
>>> Would it not be better if these parens were stripped in the fixit as they 
>>> are unnecessary in the enum value decl?
>
> To me, that would be ideal, but not strictly necessary (and perhaps doesn't 
> scale super well across all fix-its) because the code is still correct with 
> the parens, just a bit ugly. We have other similar situations with fix-its 
> (like formatting).
>
>> I prefer checks to do one thing only in a straightforward manner.
>>
>> It's easier to place things before and after the macro expansion rather than 
>> modify the contents
>> of the expansion.
>>
>> It doesn't feel like the responsibility of this check is to decide which 
>> parentheses are necessary or not.
>
> Hmm, I'm more on the fence.

Me too.  I am just not a fan of an automated check doing "other things" to my 
code
that aren't advertised in the description.  This is a macro-to-enum check not a 
redundant-parens
check.

BTW, many IDEs highlight unnecessary parentheses and have "quick fixes" to 
remove them,
ReSharper for C++ is one such IDE add-on that does this.

I'd prefer there to be a readability-redundant-parentheses check that removes 
unnecessary
parentheses across the board everywhere, rather than it being a weird 
side-effect of turning
my macros into enums.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123479

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


[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood updated this revision to Diff 421990.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D123479

Files:
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
  clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
  clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
@@ -137,6 +137,41 @@
 // CHECK-FIXES-NEXT: SUFFIX5 = +1ULL
 // CHECK-FIXES-NEXT: };
 
+// A limited form of constant expression is recognized: a parenthesized
+// literal or a parenthesized literal with the unary operators +, - or ~.
+#define PAREN1 (-1)
+#define PAREN2 (1)
+#define PAREN3 (+1)
+#define PAREN4 (~1)
+// CHECK-MESSAGES: :[[@LINE-4]]:1: warning: replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN1' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN2' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN3' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN4' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: PAREN1 = (-1),
+// CHECK-FIXES-NEXT: PAREN2 = (1),
+// CHECK-FIXES-NEXT: PAREN3 = (+1),
+// CHECK-FIXES-NEXT: PAREN4 = (~1)
+// CHECK-FIXES-NEXT: };
+
+// More complicated parenthesized expressions are excluded.
+// Expansions that are not surrounded by parentheses are excluded.
+// Nested matching parentheses are stripped.
+#define COMPLEX_PAREN1 (x+1)
+#define COMPLEX_PAREN2 (x+1
+#define COMPLEX_PAREN3 (())
+#define COMPLEX_PAREN4 ()
+#define COMPLEX_PAREN5 (+1)
+#define COMPLEX_PAREN6 ((+1))
+// CHECK-MESSAGES: :[[@LINE-2]]:1: warning: replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: macro 'COMPLEX_PAREN5' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: macro 'COMPLEX_PAREN6' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: COMPLEX_PAREN5 = (+1),
+// CHECK-FIXES-NEXT: COMPLEX_PAREN6 = ((+1))
+// CHECK-FIXES-NEXT: };
+
 // Macros appearing in conditional expressions can't be replaced
 // by enums.
 #define USE_FOO 1
Index: clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
+++ clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
@@ -14,10 +14,12 @@
 
 Potential macros for replacement must meet the following constraints:
 
-- Macros must expand only to integral literal tokens.  The unary operators
-  plus, minus and tilde are recognized to allow for positive, negative
-  and bitwise negated integers.  More complicated integral constant
-  expressions are not currently recognized by this check.
+- Macros must expand only to integral literal tokens or simple expressions
+  of literal tokens.  The unary operators plus, minus and tilde are
+  recognized to allow for positive, negative and bitwise negated integers.
+  The above expressions may also be surrounded by a single matching pair of
+  parentheses.  More complicated integral constant expressions are not
+  recognized by this check.
 - Macros must be defined on sequential source file lines, or with
   only comment lines in between macro definitions.
 - Macros must all be defined in the same source file.
@@ -43,6 +45,7 @@
   #define GREEN 0x00FF00
   #define BLUE  0xFF
 
+  #define TM_NONE (-1) // No method selected.
   #define TM_ONE 1// Use tailored method one.
   #define TM_TWO 2// Use tailored method two.  Method two
   // is preferable to method one.
@@ -59,6 +62,7 @@
   };
 
   enum {
+  TM_NONE = (-1), // No method selected.
   TM_ONE = 1,// Use tailored method one.
   TM_TWO = 2,// Use tailored method two.  Method two
   // is preferable to method one.
Index: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
@@ -324,18 +324,51 @@
 return;
 
   const MacroInfo *Info = MD->getMacroInfo();
-  if (Info->isFunctionLike() || Info->isBuiltinMacro() ||
-  Info->tokens().empty() || Info->tokens().size() > 2)
+  ArrayRef MacroTokens = Info->tokens();
+  if (Info->isFunctionLike() || Info->isBuiltinMacro() || Mac

[PATCH] D123104: [Modules] Use looked-up filename when looking for module maps

2022-04-11 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added subscribers: jansvoboda11, vsapsai, Bigcheese.
dexonsmith added a comment.

In D123104#3443448 , @dexonsmith 
wrote:

> I wonder if 
> https://github.com/apple/llvm-project/commit/67c70038bcc0d771e2e39c875ad7d69e329c7fc4
>  could be related. A long shot (I can't see how that could be it!), but the 
> other not-upstreamed patches look even less relevant.

In case it is related, note the thread ending at 
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170807/200915.html, 
which explains why it was reverted from upstream in 
4164dd9167f2f049e2a5e1bd3970a6bb45889462 and describes an alternative fix. 
@Bigcheese @jansvoboda11 @vsapsai, perhaps something to be aware of.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123104

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


[PATCH] D123479: [clang-tidy] Support parenthesized literals in modernize-macro-to-enum

2022-04-11 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood updated this revision to Diff 421991.
LegalizeAdulthood added a comment.

- Update documentation to reflect multiple pairs of matching parens


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

https://reviews.llvm.org/D123479

Files:
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
  clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
  clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
@@ -137,6 +137,41 @@
 // CHECK-FIXES-NEXT: SUFFIX5 = +1ULL
 // CHECK-FIXES-NEXT: };
 
+// A limited form of constant expression is recognized: a parenthesized
+// literal or a parenthesized literal with the unary operators +, - or ~.
+#define PAREN1 (-1)
+#define PAREN2 (1)
+#define PAREN3 (+1)
+#define PAREN4 (~1)
+// CHECK-MESSAGES: :[[@LINE-4]]:1: warning: replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN1' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN2' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN3' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: macro 'PAREN4' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: PAREN1 = (-1),
+// CHECK-FIXES-NEXT: PAREN2 = (1),
+// CHECK-FIXES-NEXT: PAREN3 = (+1),
+// CHECK-FIXES-NEXT: PAREN4 = (~1)
+// CHECK-FIXES-NEXT: };
+
+// More complicated parenthesized expressions are excluded.
+// Expansions that are not surrounded by parentheses are excluded.
+// Nested matching parentheses are stripped.
+#define COMPLEX_PAREN1 (x+1)
+#define COMPLEX_PAREN2 (x+1
+#define COMPLEX_PAREN3 (())
+#define COMPLEX_PAREN4 ()
+#define COMPLEX_PAREN5 (+1)
+#define COMPLEX_PAREN6 ((+1))
+// CHECK-MESSAGES: :[[@LINE-2]]:1: warning: replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: macro 'COMPLEX_PAREN5' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: macro 'COMPLEX_PAREN6' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: COMPLEX_PAREN5 = (+1),
+// CHECK-FIXES-NEXT: COMPLEX_PAREN6 = ((+1))
+// CHECK-FIXES-NEXT: };
+
 // Macros appearing in conditional expressions can't be replaced
 // by enums.
 #define USE_FOO 1
Index: clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
+++ clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
@@ -14,10 +14,12 @@
 
 Potential macros for replacement must meet the following constraints:
 
-- Macros must expand only to integral literal tokens.  The unary operators
-  plus, minus and tilde are recognized to allow for positive, negative
-  and bitwise negated integers.  More complicated integral constant
-  expressions are not currently recognized by this check.
+- Macros must expand only to integral literal tokens or simple expressions
+  of literal tokens.  The unary operators plus, minus and tilde are
+  recognized to allow for positive, negative and bitwise negated integers.
+  The above expressions may also be surrounded by matching pairs of
+  parentheses.  More complicated integral constant expressions are not
+  recognized by this check.
 - Macros must be defined on sequential source file lines, or with
   only comment lines in between macro definitions.
 - Macros must all be defined in the same source file.
@@ -43,6 +45,7 @@
   #define GREEN 0x00FF00
   #define BLUE  0xFF
 
+  #define TM_NONE (-1) // No method selected.
   #define TM_ONE 1// Use tailored method one.
   #define TM_TWO 2// Use tailored method two.  Method two
   // is preferable to method one.
@@ -59,6 +62,7 @@
   };
 
   enum {
+  TM_NONE = (-1), // No method selected.
   TM_ONE = 1,// Use tailored method one.
   TM_TWO = 2,// Use tailored method two.  Method two
   // is preferable to method one.
Index: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
@@ -324,18 +324,51 @@
 return;
 
   const MacroInfo *Info = MD->getMacroInfo();
-  if (Info->isFunctionLike() || Info->isBuiltinMacro() ||
-  Info->tokens().empty() || Info->tokens().size() > 2)
+  ArrayRef MacroTokens = Info->tokens();
+  if (Info->isFunctionLike() 

[PATCH] D123533: [clang][extract-api] Add support for true anonymous enums

2022-04-11 Thread Daniel Grumberg via Phabricator via cfe-commits
dang created this revision.
dang added reviewers: zixuw, ributzka, QuietMisdreavus.
Herald added a project: All.
dang requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Anonymous enums without a typedef should have a "(anonymous)" identifier.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123533

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/enum.c

Index: clang/test/ExtractAPI/enum.c
===
--- clang/test/ExtractAPI/enum.c
+++ clang/test/ExtractAPI/enum.c
@@ -30,6 +30,10 @@
   West
 };
 
+enum {
+  Constant = 1
+};
+
 //--- reference.output.json.in
 {
   "metadata": {
@@ -100,6 +104,11 @@
   "kind": "memberOf",
   "source": "c:@E@Direction@West",
   "target": "c:@E@Direction"
+},
+{
+  "kind": "memberOf",
+  "source": "c:@Ea@Constant@Constant",
+  "target": "c:@Ea@Constant"
 }
   ],
   "symbols": [
@@ -641,6 +650,94 @@
 "Direction",
 "West"
   ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "enum"
+},
+{
+  "kind": "text",
+  "spelling": ": "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:i",
+  "spelling": "unsigned int"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@Constant"
+  },
+  "kind": {
+"displayName": "Enumeration",
+"identifier": "c.enum"
+  },
+  "location": {
+"position": {
+  "character": 1,
+  "line": 17
+},
+"uri": "file:///Users/dgrumberg/VersionControlledDocuments/oss/llvm-project/build/tools/clang/test/ExtractAPI/Output/enum.c.tmp/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "(anonymous)"
+  }
+],
+"title": "(anonymous)"
+  },
+  "pathComponents": [
+"(anonymous)"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "identifier",
+  "spelling": "Constant"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@Constant@Constant"
+  },
+  "kind": {
+"displayName": "Enumeration Case",
+"identifier": "c.enum.case"
+  },
+  "location": {
+"position": {
+  "character": 3,
+  "line": 18
+},
+"uri": "file:///Users/dgrumberg/VersionControlledDocuments/oss/llvm-project/build/tools/clang/test/ExtractAPI/Output/enum.c.tmp/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "Constant"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "Constant"
+  }
+],
+"title": "Constant"
+  },
+  "pathComponents": [
+"(anonymous)",
+"Constant"
+  ]
 }
   ]
 }
Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -215,9 +215,11 @@
   return true;
 
 // Collect symbol information.
-StringRef Name = Decl->getName();
+std::string NameString = Decl->getQualifiedNameAsString();
+StringRef Name(NameString);
 if (Name.empty())
   Name = getTypedefName(Decl);
+
 StringRef USR = API.recordUSR(Decl);
 PresumedLoc Loc =
 Context.getSourceManager().getPresumedLoc(Decl->getLocation());
@@ -233,8 +235,9 @@
 DeclarationFragments SubHeading =
 DeclarationFragmentsBuilder::getSubHeading(Decl);
 
-EnumRecord *EnumRecord = API.addEnum(Name, USR, Loc, Availability, Comment,
- Declaration, SubHeading);
+EnumRecord *EnumRecord =
+API.addEnum(API.copyString(Name), USR, Loc, Availability, Comment,
+Declaration, SubHeading);
 
 // Now collect information about the enumerators in this enum.
 recordEnumConstants(EnumRecord, Decl->enumerators());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D122673: Add kcfi_unchecked attribute

2022-04-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122673#3414650 , @samitolvanen 
wrote:

> Note that this was split from D119296 .
>
> In the previous discussion, @joaomoreira  pointed out that this is very 
> similar to `nocf_check` and proposed reusing that attribute. In an offline 
> discussion, @pcc  was concerned that an attribute may not be the right 
> approach here and suggested  a `__builtin_kcfi_unchecked(function(args))` 
> built-in function to avoid changing the type system.
>
> I would appreciate hearing your thoughts.

I tend to be very wary of modifying the type system with attributes -- 
questions always arise of what the type system effects are of the attribute. 
e.g., does it impact overload sets or template specialization? Name mangling? 
If it doesn't have type system impacts... why does it need to be in the type 
system at all? This also matters because adding more bits to types can have 
unintended side effects like accidentally reducing the depth of template 
instantiations we can process (because of the extra memory pressure). So while 
I'm not certain what you and @pcc  talked about, it does seem like an approach 
at least worth thinking about, especially because this patch needs to bump the 
size of `Type`.




Comment at: clang/include/clang/AST/Type.h:1832
canon.isNull() ? QualType(this_(), 0) : canon) {
-static_assert(sizeof(*this) <= 8 + sizeof(ExtQualsTypeCommonBase),
+static_assert(sizeof(*this) <= 16 + sizeof(ExtQualsTypeCommonBase),
   "changing bitfields changed sizeof(Type)!");

Needing to bump this limit worries me. It's correct for the changes, but it 
means that `Type` just because even more expensive and so I wonder how this 
will impact compile time performance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122673

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


[PATCH] D123534: [dwarf] Emit a DIGlobalVariable for constant strings.

2022-04-11 Thread Mitch Phillips via Phabricator via cfe-commits
hctim created this revision.
hctim added reviewers: echristo, cmtice.
Herald added a project: All.
hctim requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressSanitizer
off of internal debug info for symbolization onto the DWARF standard
(and doing a clean-up in the process). Currently, ASan reports the line
information for constant strings if a memory safety bug happens around
them. We want to keep this behaviour, so we need to emit debuginfo for
these variables as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123534

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/debug-info-variables.c
  clang/test/VFS/external-names.c

Index: clang/test/VFS/external-names.c
===
--- clang/test/VFS/external-names.c
+++ clang/test/VFS/external-names.c
@@ -30,8 +30,8 @@
 // Debug info
 
 // RUN: %clang_cc1 -I %t -ivfsoverlay %t.external.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG-EXTERNAL %s
-// CHECK-DEBUG-EXTERNAL: !DISubprogram({{.*}}file: ![[Num:[0-9]+]]
-// CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{..?}}external-names.h"
+// CHECK-DEBUG-EXTERNAL: ![[Num:[0-9]+]] = !DIFile(filename: "{{[^"]*}}Inputs{{..?}}external-names.h"
+// CHECK-DEBUG-EXTERNAL: !DISubprogram({{.*}}file: ![[Num]]
 
 // RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG %s
 // CHECK-DEBUG-NOT: Inputs
Index: clang/test/CodeGen/debug-info-variables.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-variables.c
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -debug-info-kind=standalone -S -emit-llvm -o - | FileCheck %s
+
+// CHECK: DIGlobalVariable(name: "global"
+int global = 42;
+
+// CHECK: DIGlobalVariable({{.*}}line: [[@LINE+2]]
+const char* s() {
+  return "1234567890";
+}
+
+// CHECK: DILocalVariable(name: "p"
+// CHECK: DILocalVariable(name: "q"
+// CHECK: DILocalVariable(name: "r"
+int sum(int p, int q) {
+  int r = p + q;
+  return r;
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5624,6 +5624,12 @@
   }
 
   auto GV = GenerateStringLiteral(C, LT, *this, GlobalVariableName, Alignment);
+
+  CGDebugInfo *DI = getModuleDebugInfo();
+  if (DI && getCodeGenOpts().hasReducedDebugInfo())
+DI->AddStringLiteralDebugInfo(GV, GlobalVariableName, S->getStrTokenLoc(0),
+  S->getByteLength());
+
   if (Entry)
 *Entry = GV;
 
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -533,6 +533,10 @@
   /// Emit an @import declaration.
   void EmitImportDecl(const ImportDecl &ID);
 
+  /// Create and attach debuginfo to a the provided string literal GV.
+  void AddStringLiteralDebugInfo(llvm::GlobalVariable *GV, StringRef Name,
+ const SourceLocation &Loc, unsigned Length);
+
   /// Emit C++ namespace alias.
   llvm::DIImportedEntity *EmitNamespaceAlias(const NamespaceAliasDecl &NA);
 
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -5118,7 +5118,7 @@
 return Name;
   codegenoptions::DebugTemplateNamesKind TemplateNamesKind =
   CGM.getCodeGenOpts().getDebugSimpleTemplateNames();
-  
+
   if (!CGM.getCodeGenOpts().hasReducedDebugInfo())
 TemplateNamesKind = codegenoptions::DebugTemplateNamesKind::Full;
 
@@ -5445,6 +5445,21 @@
   ImportedDeclCache[GD.getCanonicalDecl().getDecl()].reset(ImportDI);
 }
 
+void CGDebugInfo::AddStringLiteralDebugInfo(llvm::GlobalVariable *GV,
+StringRef Name,
+const SourceLocation &Loc,
+unsigned Length) {
+  PresumedLoc PLoc = CGM.getContext().getSourceManager().getPresumedLoc(Loc);
+  if (!PLoc.isValid())
+return;
+
+  llvm::DIGlobalVariableExpression *Debug =
+  DBuilder.createGlobalVariableExpression(
+  nullptr, Name, Name, getOrCreateFile(Loc), getLineNumber(Loc),
+  DBuilder.createStringType(Name, Length), true);
+  GV->addDebugInfo(Debug);
+}
+
 llvm::DIScope *CGDebugInfo::getCurrentContextDescriptor(const Decl *D) {
   if (!LexicalBlockStack.empty())
 return Le

  1   2   >