[PATCH] D90212: [AMDGPU] Add missing support for targets

2020-10-27 Thread Tony Tye via Phabricator via cfe-commits
t-tye created this revision.
t-tye added reviewers: kzhuravl, scott.linder, tpr.
Herald added subscribers: llvm-commits, cfe-commits, kerbowa, rupprecht, 
hiraditya, dstuttard, yaxunl, nhaehnle, jvesely, emaste.
Herald added a reviewer: espindola.
Herald added a reviewer: jhenderson.
Herald added projects: clang, LLVM.
t-tye requested review of this revision.
Herald added subscribers: MaskRay, wdng.

- Add missing tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90212

Files:
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test

Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -73,6 +73,9 @@
 # RUN: yaml2obj %s -o %t -DCPU=GFX1031
 # RUN: llvm-readobj -h %t | FileCheck %s --match-full-lines -DFILE=%t -DCPU=GFX1031 -DFLAGS=0x37
 
+# RUN: yaml2obj %s -o %t -DCPU=GFX1032
+# RUN: llvm-readobj -h %t | FileCheck %s --match-full-lines -DFILE=%t -DCPU=GFX1032 -DFLAGS=0x38
+
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
Index: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
===
--- llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
@@ -1,115 +1,171 @@
 # RUN: yaml2obj --docnum=1 %s -o %t.o.1
 # RUN: llvm-readobj -S --file-headers %t.o.1 | FileCheck --check-prefixes=ELF-ALL,ELF-R600 %s
 # RUN: obj2yaml %t.o.1 | FileCheck --check-prefixes=YAML-R600 %s
+
 # RUN: yaml2obj --docnum=2 %s -o %t.o.2
 # RUN: llvm-readobj -S --file-headers %t.o.2 | FileCheck --check-prefixes=ELF-ALL,ELF-R630 %s
 # RUN: obj2yaml %t.o.2 | FileCheck --check-prefixes=YAML-R630 %s
+
 # RUN: yaml2obj --docnum=3 %s -o %t.o.3
 # RUN: llvm-readobj -S --file-headers %t.o.3 | FileCheck --check-prefixes=ELF-ALL,ELF-RS880 %s
 # RUN: obj2yaml %t.o.3 | FileCheck --check-prefixes=YAML-RS880 %s
+
 # RUN: yaml2obj --docnum=4 %s -o %t.o.4
 # RUN: llvm-readobj -S --file-headers %t.o.4 | FileCheck --check-prefixes=ELF-ALL,ELF-RV670 %s
 # RUN: obj2yaml %t.o.4 | FileCheck --check-prefixes=YAML-RV670 %s
+
 # RUN: yaml2obj --docnum=5 %s -o %t.o.5
 # RUN: llvm-readobj -S --file-headers %t.o.5 | FileCheck --check-prefixes=ELF-ALL,ELF-RV710 %s
 # RUN: obj2yaml %t.o.5 | FileCheck --check-prefixes=YAML-RV710 %s
+
 # RUN: yaml2obj --docnum=6 %s -o %t.o.6
 # RUN: llvm-readobj -S --file-headers %t.o.6 | FileCheck --check-prefixes=ELF-ALL,ELF-RV730 %s
 # RUN: obj2yaml %t.o.6 | FileCheck --check-prefixes=YAML-RV730 %s
+
 # RUN: yaml2obj --docnum=7 %s -o %t.o.7
 # RUN: llvm-readobj -S --file-headers %t.o.7 | FileCheck --check-prefixes=ELF-ALL,ELF-RV770 %s
 # RUN: obj2yaml %t.o.7 | FileCheck --check-prefixes=YAML-RV770 %s
+
 # RUN: yaml2obj --docnum=8 %s -o %t.o.8
 # RUN: llvm-readobj -S --file-headers %t.o.8 | FileCheck --check-prefixes=ELF-ALL,ELF-CEDAR %s
 # RUN: obj2yaml %t.o.8 | FileCheck --check-prefixes=YAML-CEDAR %s
+
 # RUN: yaml2obj --docnum=9 %s -o %t.o.9
 # RUN: llvm-readobj -S --file-headers %t.o.9 | FileCheck --check-prefixes=ELF-ALL,ELF-CYPRESS %s
 # RUN: obj2yaml %t.o.9 | FileCheck --check-prefixes=YAML-CYPRESS %s
+
 # RUN: yaml2obj --docnum=10 %s -o %t.o.10
 # RUN: llvm-readobj -S --file-headers %t.o.10 | FileCheck --check-prefixes=ELF-ALL,ELF-JUNIPER %s
 # RUN: obj2yaml %t.o.10 | FileCheck --check-prefixes=YAML-JUNIPER %s
+
 # RUN: yaml2obj --docnum=11 %s -o %t.o.11
 # RUN: llvm-readobj -S --file-headers %t.o.11 | FileCheck --check-prefixes=ELF-ALL,ELF-REDWOOD %s
 # RUN: obj2yaml %t.o.11 | FileCheck --check-prefixes=YAML-REDWOOD %s
+
 # RUN: yaml2obj --docnum=12 %s -o %t.o.12
 # RUN: llvm-readobj -S --file-headers %t.o.12 | FileCheck --check-prefixes=ELF-ALL,ELF-SUMO %s
 # RUN: obj2yaml %t.o.12 | FileCheck --check-prefixes=YAML-SUMO %s
+
 # RUN: yaml2obj --docnum=13 %s -o %t.o.13
 # RUN: llvm-readobj -S --file-headers %t.o.13 | FileCheck --check-prefixes=ELF-ALL,ELF-BARTS %s
 # RUN: obj2yaml %t.o.13 | FileCheck --check-prefixes=YAML-BARTS %s
+
 # RUN: yaml2obj --docnum=14 %s -o %t.o.14
 # RUN: llvm-readobj -S --file-headers %t.o.14 | FileCheck --check-prefixes=ELF-ALL,ELF-CAICOS %s
 # RUN: obj2yaml %t.o.14 | FileCheck --check-prefixes=YAML-CAICOS %s
+
 # RUN: yaml2obj --docnum=15 %s -o %t.o.15
 # RUN: llvm-readobj -S --file-headers %t.o.15 | FileCheck --check-prefixes=ELF-ALL,ELF-CAYMAN %s
 # RUN: obj2yaml %t.o.15 | FileCheck --check-prefixes=YAML-CAYMAN %s
+
 # RUN: yaml2obj --docnum=16 %s -o %t.o.16
 # RUN: llvm-readobj -S --file-headers %t.o.16 | FileCheck --check-prefixes=ELF-ALL,ELF-TURKS %s
 # RUN: obj2yaml %t.o.16 | FileCheck --check-prefixes=YAML-TURKS %s
+
 # RUN: yaml2obj --docnum=17 %s -o %t.o.17
 # RUN: llvm-readobj -S --file-headers %t.o.17 | FileCheck 

[clang] c6a05eb - [Syntax] Disallow invalid Node operations

2020-10-27 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2020-10-27T08:36:35+01:00
New Revision: c6a05eb62f2ab392eba4e7a056e95c821587ae47

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

LOG: [Syntax] Disallow invalid Node operations

Copy/move break invariants (move could be fixed).
Node/Tree should have no public constructors, they're abstract.
Destructor is private to enforce arena allocation.

(Making the constructor of all subclasses private doesn't seem worthwhile)

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

Added: 


Modified: 
clang/include/clang/Tooling/Syntax/Tree.h

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Tree.h 
b/clang/include/clang/Tooling/Syntax/Tree.h
index 5840a86199eb..c6430452a94d 100644
--- a/clang/include/clang/Tooling/Syntax/Tree.h
+++ b/clang/include/clang/Tooling/Syntax/Tree.h
@@ -76,10 +76,20 @@ enum class NodeRole : uint8_t;
 /// A node in a syntax tree. Each node is either a Leaf (representing tokens) 
or
 /// a Tree (representing language constructrs).
 class Node {
-public:
+protected:
   /// Newly created nodes are detached from a tree, parent and sibling links 
are
   /// set when the node is added as a child to another one.
   Node(NodeKind Kind);
+  /// Nodes are allocated on Arenas; the destructor is never called.
+  ~Node() = default;
+
+public:
+  /// Nodes cannot simply be copied without violating tree invariants.
+  Node(const Node &) = delete;
+  Node &operator=(const Node &) = delete;
+  /// Idiomatically, nodes are allocated on an Arena and never moved.
+  Node(Node &&) = delete;
+  Node &operator=(Node &&) = delete;
 
   NodeKind getKind() const { return static_cast(Kind); }
   NodeRole getRole() const { return static_cast(Role); }
@@ -153,7 +163,6 @@ class Leaf final : public Node {
 /// A node that has children and represents a syntactic language construct.
 class Tree : public Node {
 public:
-  using Node::Node;
   static bool classof(const Node *N);
 
   Node *getFirstChild() { return FirstChild; }
@@ -170,6 +179,7 @@ class Tree : public Node {
   }
 
 protected:
+  using Node::Node;
   /// Find the first node with a corresponding role.
   Node *findChild(NodeRole R);
 



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


[PATCH] D90163: [Syntax] Disallow invalid Node operations

2020-10-27 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc6a05eb62f2a: [Syntax] Disallow invalid Node operations 
(authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90163

Files:
  clang/include/clang/Tooling/Syntax/Tree.h


Index: clang/include/clang/Tooling/Syntax/Tree.h
===
--- clang/include/clang/Tooling/Syntax/Tree.h
+++ clang/include/clang/Tooling/Syntax/Tree.h
@@ -76,10 +76,20 @@
 /// A node in a syntax tree. Each node is either a Leaf (representing tokens) 
or
 /// a Tree (representing language constructrs).
 class Node {
-public:
+protected:
   /// Newly created nodes are detached from a tree, parent and sibling links 
are
   /// set when the node is added as a child to another one.
   Node(NodeKind Kind);
+  /// Nodes are allocated on Arenas; the destructor is never called.
+  ~Node() = default;
+
+public:
+  /// Nodes cannot simply be copied without violating tree invariants.
+  Node(const Node &) = delete;
+  Node &operator=(const Node &) = delete;
+  /// Idiomatically, nodes are allocated on an Arena and never moved.
+  Node(Node &&) = delete;
+  Node &operator=(Node &&) = delete;
 
   NodeKind getKind() const { return static_cast(Kind); }
   NodeRole getRole() const { return static_cast(Role); }
@@ -153,7 +163,6 @@
 /// A node that has children and represents a syntactic language construct.
 class Tree : public Node {
 public:
-  using Node::Node;
   static bool classof(const Node *N);
 
   Node *getFirstChild() { return FirstChild; }
@@ -170,6 +179,7 @@
   }
 
 protected:
+  using Node::Node;
   /// Find the first node with a corresponding role.
   Node *findChild(NodeRole R);
 


Index: clang/include/clang/Tooling/Syntax/Tree.h
===
--- clang/include/clang/Tooling/Syntax/Tree.h
+++ clang/include/clang/Tooling/Syntax/Tree.h
@@ -76,10 +76,20 @@
 /// A node in a syntax tree. Each node is either a Leaf (representing tokens) or
 /// a Tree (representing language constructrs).
 class Node {
-public:
+protected:
   /// Newly created nodes are detached from a tree, parent and sibling links are
   /// set when the node is added as a child to another one.
   Node(NodeKind Kind);
+  /// Nodes are allocated on Arenas; the destructor is never called.
+  ~Node() = default;
+
+public:
+  /// Nodes cannot simply be copied without violating tree invariants.
+  Node(const Node &) = delete;
+  Node &operator=(const Node &) = delete;
+  /// Idiomatically, nodes are allocated on an Arena and never moved.
+  Node(Node &&) = delete;
+  Node &operator=(Node &&) = delete;
 
   NodeKind getKind() const { return static_cast(Kind); }
   NodeRole getRole() const { return static_cast(Role); }
@@ -153,7 +163,6 @@
 /// A node that has children and represents a syntactic language construct.
 class Tree : public Node {
 public:
-  using Node::Node;
   static bool classof(const Node *N);
 
   Node *getFirstChild() { return FirstChild; }
@@ -170,6 +179,7 @@
   }
 
 protected:
+  using Node::Node;
   /// Find the first node with a corresponding role.
   Node *findChild(NodeRole R);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D89936: clang-tidy: adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo updated this revision to Diff 300911.
Hiralo marked an inline comment as done.
Hiralo added a comment.

Incorporated review comments and updated patch.
(a) renamed var 'ClangTidyConfig' with 'ConfigFile'
(b) renamed function 'tryReadConfigFile(AbsoluteFilePath, true);' to 
'readConfigFile(ConfigPath)'
(c) renamed command-line option to '--config-file'
(d) made --config-file and --checks mutually exclusive
(e) make --config-file and --config mutually exclusive
(f) removed extra checks -- making absolute-path, isFile and isLink checks


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

https://reviews.llvm.org/D89936

Files:
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp

Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -73,12 +73,13 @@
 )"),
cl::init(""), cl::cat(ClangTidyCategory));
 
-static cl::opt ClangTidyConfig("clang-tidy-config", cl::desc(R"(
-Specify full path of .clang-tidy config file.
-For example, --clang-tidy-config=/some/path/myTidyConfig
+static cl::opt ConfigFile("config-file", cl::desc(R"(
+Specify full path of .clang-tidy or custom config file.
+For example, --config-file=/some/path/myTidyConfig
+Note: this option is mutually exclusive to --config and --checks options.
 )"),
-cl::init(""),
-cl::cat(ClangTidyCategory));
+   cl::init(""),
+   cl::cat(ClangTidyCategory));
 
 static cl::opt WarningsAsErrors("warnings-as-errors", cl::desc(R"(
 Upgrades warnings to errors. Same format as
@@ -286,7 +287,7 @@
 
   ClangTidyOptions DefaultOptions;
   DefaultOptions.Checks = DefaultChecks;
-  DefaultOptions.ClangTidyConfig = "";
+  DefaultOptions.ConfigFile = "";
   DefaultOptions.WarningsAsErrors = "";
   DefaultOptions.HeaderFilterRegex = HeaderFilter;
   DefaultOptions.SystemHeaders = SystemHeaders;
@@ -299,8 +300,8 @@
   ClangTidyOptions OverrideOptions;
   if (Checks.getNumOccurrences() > 0)
 OverrideOptions.Checks = Checks;
-  if (ClangTidyConfig.getNumOccurrences() > 0)
-OverrideOptions.ClangTidyConfig = ClangTidyConfig;
+  if (ConfigFile.getNumOccurrences() > 0)
+OverrideOptions.ConfigFile = ConfigFile;
   if (WarningsAsErrors.getNumOccurrences() > 0)
 OverrideOptions.WarningsAsErrors = WarningsAsErrors;
   if (HeaderFilter.getNumOccurrences() > 0)
@@ -312,6 +313,19 @@
   if (UseColor.getNumOccurrences() > 0)
 OverrideOptions.UseColor = UseColor;
 
+  if (!ConfigFile.empty()) {
+if (!Config.empty()) {
+  llvm::errs() << "Error: --config-file and --config are mutually "
+  "exclusive. Specify only one.\n";
+  return nullptr;
+}
+if (!Checks.empty()) {
+  llvm::errs() << "Error: --config-file and --checks are mutually "
+  "exclusive. Specify only one.\n";
+  return nullptr;
+}
+  }
+
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {
Index: clang-tools-extra/clang-tidy/ClangTidyOptions.h
===
--- clang-tools-extra/clang-tidy/ClangTidyOptions.h
+++ clang-tools-extra/clang-tidy/ClangTidyOptions.h
@@ -65,7 +65,7 @@
   llvm::Optional Checks;
 
   /// Clang-tidy-config
-  llvm::Optional ClangTidyConfig;
+  llvm::Optional ConfigFile;
 
   /// WarningsAsErrors filter.
   llvm::Optional WarningsAsErrors;
@@ -230,8 +230,10 @@
   /// Try to read configuration files from \p Directory using registered
   /// \c ConfigHandlers.
   llvm::Optional tryReadConfigFile(llvm::StringRef Directory);
-  llvm::Optional tryReadConfigFile(llvm::StringRef Path,
-  bool IsFile);
+
+  /// Try to read configuration files using registered
+  /// \c ConfigHandlers.
+  llvm::Optional readConfigFile(llvm::StringRef Path);
 
   llvm::StringMap CachedOptions;
   ClangTidyOptions OverrideOptions;
Index: clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
+++ clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
@@ -109,7 +109,7 @@
 ClangTidyOptions ClangTidyOptions::getDefaults() {
   ClangTidyOptions Options;
   Options.Checks = "";
-  Options.ClangTidyConfig = "";
+  Options.ConfigFile = "";
   Options.WarningsAsErrors = "";
   Options.HeaderFilterRegex = "";
   Options.SystemHeaders = false;
@@ -307,42 +307,19 @@
   << "...\n");
   assert(FS && "FS must be set.");
 
-  llvm::SmallString<1024> AbsoluteFilePath(FileName);
- 

[PATCH] D88381: [Flang][Driver] Add PrintPreprocessed FrontendAction

2020-10-27 Thread sameeran joshi via Phabricator via cfe-commits
sameeranjoshi added a comment.

A few `nits:` and mostly style comments inline:




Comment at: flang/include/flang/Frontend/CompilerInvocation.h:12
 #include "flang/Frontend/FrontendOptions.h"
+#include "flang/Parser/parsing.h"
 #include "clang/Basic/Diagnostic.h"

awarzynski wrote:
> sameeranjoshi wrote:
> > `Nit:` I believe `clang-format` is missing.
> I did apply it and this line looks OK to me - what's missing?
See point 2[1] below the code block.
Ideally clang comes alphabetically first.

[1] 
https://github.com/llvm/llvm-project/blob/master/flang/docs/C++style.md#files



Comment at: flang/include/flang/Frontend/FrontendActions.h:9
 
 #ifndef LLVM_FLANG_FRONTEND_FRONTENDACTIONS_H
 #define LLVM_FLANG_FRONTEND_FRONTENDACTIONS_H

Why is this not following the style guide mentioned at [1] point 2.

[1] 
https://github.com/llvm/llvm-project/blob/master/flang/docs/C++style.md#files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88381

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


[PATCH] D89936: clang-tidy: adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added a comment.

In D89936#2353048 , @DmitryPolukhin 
wrote:

> ...I think this diff needs some improvements

Thanks @DmitryPolukhin for your valuable comments/feedback.
Please review updated patch.

> + test for new option.

I am planning to add following test-case...

diff --git 
a/clang-tools-extra/test/clang-tidy/infrastructure/read_file_config.cpp 
b/clang-tools-extra/test/clang-tidy/infrastructure/read_file_config.cpp
...
 // RUN: clang-tidy -checks="-*,clang-analyzer-*" %T/read-file-config/test.cpp 
| grep "warning: .*\[clang-analyzer-deadcode.DeadStores\]$"
+// RUN: clang-tidy -config-file=%T/read-file-config/.clang-tidy 
%T/read-file-config/test.cpp | grep "warning: 
.*\[clang-analyzer-deadcode.DeadStores\]$"



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

https://reviews.llvm.org/D89936

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


[clang-tools-extra] 2ef2841 - [clangd] Fix proto deps, for real this time.

2020-10-27 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2020-10-27T09:15:42+01:00
New Revision: 2ef2841c0d0b49a76ea9026f37207a473d7d1332

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

LOG: [clangd] Fix proto deps, for real this time.

This is ugly (layering violation) but we can clean it up once we know it
works in CI.

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/CMakeLists.txt 
b/clang-tools-extra/clangd/index/remote/CMakeLists.txt
index 971af205f45d..554288df0bcb 100644
--- a/clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ b/clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -1,12 +1,13 @@
 if (CLANGD_ENABLE_REMOTE)
   generate_protos(RemoteIndexServiceProto "Service.proto" GRPC)
   generate_protos(RemoteIndexProto "Index.proto")
-  target_link_libraries(RemoteIndexServiceProto
-
-PUBLIC
-RemoteIndexProto
-)
-  add_dependencies(RemoteIndexServiceProto RemoteIndexProto)
+  # Ensure dependency headers are generated before dependent protos are built.
+  # FIXME: this should be encapsulated in generate_protos.
+  # FIXME: CMake docs say OBJECT_DEPENDS isn't needed, but I can't get the
+  #recommended add_dependencies() approach to work.
+  set_source_files_properties(
+${CMAKE_CURRENT_BINARY_DIR}/Service.pb.cc
+PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/Index.pb.h)
   include_directories(${CMAKE_CURRENT_BINARY_DIR})
   include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../)
 



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


[PATCH] D88609: Use uint64_t for branch weights instead of uint32_t

2020-10-27 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

Updated mlir test also to include this change.
https://reviews.llvm.org/rG0fc1aa22ee6ac337a5d51fa5666c9cd61da61b07


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88609

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


[PATCH] D90010: clang-tidy: Reduce number of stderr write calls

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added a comment.

JFYI: using --quiet avoids call to following write calls...so that is useful.
write(2, "Suppressed ", 11) = 11
write(2, "10703", 5) = 5
write(2, " warnings (", 11) = 11
write(2, "10703", 5) = 5
write(2, " in non-user code", 17) = 17
write(2, ").\n", 3) = 3
write(2, "Use -header-filter=.* to display"..., 136) = 136

But still we have following stderr write calls, not sure which code emits...
write(2, "10712", 5) = 5
write(2, " warning", 8) = 8
write(2, "s", 1) = 1
write(2, " generated", 10) = 10
write(2, ".\n", 2) = 2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90010

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


[PATCH] D90010: clang-tidy: Reduce number of stderr write calls

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added a comment.

Another observation w.r.t. stdout...

For example, consider following sample program:

#include 
#include 

using namespace std;
static long long A = 0ull;

void f(const std::string& a) {

  std::cout << a << std::endl;

}

int main() {
}


When running clang-tidy on this... we can see about 343 stdout write calls...
e.g. 
write(1, "\33[1m", 4)   = 4
write(1, "/some/path/a.cc", 14)  = 14
write(1, ":", 1)= 1
write(1, "4", 1)= 1
write(1, ":", 1)= 1
write(1, "1", 1)= 1
write(1, ":", 1)= 1
write(1, " ", 1)= 1
write(1, "\33[0m", 4)   = 4
write(1, "\33[0;1;35m", 9)  = 9
write(1, "warning", 7)  = 7
write(1, ": ", 2)   = 2
write(1, "\33[0m", 4)   = 4
write(1, "\33[1m", 4)   = 4
write(1, "do not use namespace using-direc"..., 100) = 100
write(1, "\33[0m", 4)   = 4
write(1, "\n", 1)   = 1
write(1, "using namespace std;", 20)= 20
write(1, "\n", 1)   = 1
write(1, "\33[0;1;32m", 9)  = 9
write(1, "^", 1)= 1
write(1, "\n", 1)   = 1
write(1, "\33[0m", 4)   = 4
write(1, "\33[1m", 4)   = 4
...

Shouldn't clang-tidy stdout with reasonable buffer-size (e.g. 128 or 512 or 
1024) ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90010

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


[clang] 2c2dc7c - [clang][RecoveryExpr] Add tests for ObjectiveC.

2020-10-27 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2020-10-27T09:42:19+01:00
New Revision: 2c2dc7c392a3f28d4dbec3018e3137d5d4f8c6c8

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

LOG: [clang][RecoveryExpr] Add tests for ObjectiveC.

to demonstrate it works for some cases.

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

Added: 
clang/test/AST/ast-dump-recovery.m

Modified: 


Removed: 




diff  --git a/clang/test/AST/ast-dump-recovery.m 
b/clang/test/AST/ast-dump-recovery.m
new file mode 100644
index ..5ca866a0282f
--- /dev/null
+++ b/clang/test/AST/ast-dump-recovery.m
@@ -0,0 +1,18 @@
+// RUN: not %clang_cc1 -triple x86_64-unknown-unknown -frecovery-ast 
-frecovery-ast-type -ast-dump %s | FileCheck -strict-whitespace %s
+
+@interface Foo
+- (void)method:(int)n;
+@end
+
+void k(Foo *foo) {
+  // CHECK:   ObjCMessageExpr {{.*}} 'void' contains-errors
+  // CHECK-CHECK:  |-ImplicitCastExpr {{.*}} 'Foo *' 
+  // CHECK-CHECK:  | `-DeclRefExpr {{.*}} 'foo'
+  // CHECK-CHECK:  `-RecoveryExpr {{.*}}
+  [foo method:undef];
+
+  // CHECK:  ImplicitCastExpr {{.*}} '' contains-errors
+  // CHECK-NEXT: `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   `-DeclRefExpr {{.*}} 'foo'
+  foo.undef;
+}



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


[PATCH] D90140: [clang][RecoveryExpr] Add tests for ObjectiveC.

2020-10-27 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang/test/AST/ast-dump-recovery.m:8
+void k(Foo *foo) {
+  // CHECK:   ObjCMessageExpr {{.*}} 'void' contains-errors
+  // CHECK-CHECK:  |-ImplicitCastExpr {{.*}} 'Foo *' 

sammccall wrote:
> this contains the resolved selector so go-to-def on `method` will work, 
> right? Really cool :-)
yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90140

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


[PATCH] D90140: [clang][RecoveryExpr] Add tests for ObjectiveC.

2020-10-27 Thread Haojian Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2c2dc7c392a3: [clang][RecoveryExpr] Add tests for 
ObjectiveC. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90140

Files:
  clang/test/AST/ast-dump-recovery.m


Index: clang/test/AST/ast-dump-recovery.m
===
--- /dev/null
+++ clang/test/AST/ast-dump-recovery.m
@@ -0,0 +1,18 @@
+// RUN: not %clang_cc1 -triple x86_64-unknown-unknown -frecovery-ast 
-frecovery-ast-type -ast-dump %s | FileCheck -strict-whitespace %s
+
+@interface Foo
+- (void)method:(int)n;
+@end
+
+void k(Foo *foo) {
+  // CHECK:   ObjCMessageExpr {{.*}} 'void' contains-errors
+  // CHECK-CHECK:  |-ImplicitCastExpr {{.*}} 'Foo *' 
+  // CHECK-CHECK:  | `-DeclRefExpr {{.*}} 'foo'
+  // CHECK-CHECK:  `-RecoveryExpr {{.*}}
+  [foo method:undef];
+
+  // CHECK:  ImplicitCastExpr {{.*}} '' contains-errors
+  // CHECK-NEXT: `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   `-DeclRefExpr {{.*}} 'foo'
+  foo.undef;
+}


Index: clang/test/AST/ast-dump-recovery.m
===
--- /dev/null
+++ clang/test/AST/ast-dump-recovery.m
@@ -0,0 +1,18 @@
+// RUN: not %clang_cc1 -triple x86_64-unknown-unknown -frecovery-ast -frecovery-ast-type -ast-dump %s | FileCheck -strict-whitespace %s
+
+@interface Foo
+- (void)method:(int)n;
+@end
+
+void k(Foo *foo) {
+  // CHECK:   ObjCMessageExpr {{.*}} 'void' contains-errors
+  // CHECK-CHECK:  |-ImplicitCastExpr {{.*}} 'Foo *' 
+  // CHECK-CHECK:  | `-DeclRefExpr {{.*}} 'foo'
+  // CHECK-CHECK:  `-RecoveryExpr {{.*}}
+  [foo method:undef];
+
+  // CHECK:  ImplicitCastExpr {{.*}} '' contains-errors
+  // CHECK-NEXT: `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   `-DeclRefExpr {{.*}} 'foo'
+  foo.undef;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 2618247 - Correct examples after d3205bbca3e0002d76282878986993e7e7994779

2020-10-27 Thread via cfe-commits

Author: Tyker
Date: 2020-10-27T09:49:33+01:00
New Revision: 2618247c61c25cf9bd4cb315ee51cff2b3ab3add

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

LOG: Correct examples after d3205bbca3e0002d76282878986993e7e7994779

Added: 


Modified: 
clang/examples/AnnotateFunctions/AnnotateFunctions.cpp

Removed: 




diff  --git a/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp 
b/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp
index 1724704fe124..d872020c2d8a 100644
--- a/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp
+++ b/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp
@@ -32,8 +32,8 @@ class AnnotateFunctionsConsumer : public ASTConsumer {
   return true;
 for (auto D : DG)
   if (FunctionDecl *FD = dyn_cast(D))
-FD->addAttr(AnnotateAttr::CreateImplicit(FD->getASTContext(),
- "example_annotation"));
+FD->addAttr(AnnotateAttr::CreateImplicit(
+FD->getASTContext(), "example_annotation", nullptr, 0));
 return true;
   }
 };



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


[PATCH] D90213: [PowerPC] [Clang] Enable float128 feature on P9 by default

2020-10-27 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf created this revision.
qiucf added reviewers: echristo, stefanp, nemanjai, jsji, steven.zhang, PowerPC.
Herald added subscribers: cfe-commits, dexonsmith, shchenz, kbarton.
Herald added a project: clang.
qiucf requested review of this revision.

As Power9 introduced hardware support for IEEE quad-precision FP type, the 
feature should be enabled by default on Power9 or newer targets.

And as I saw, GCC also enables the feature for all VSX-enabled targets (Power7 
and Power8). If we want to align with GCC behaviors about FP128, we'd also do 
that after fixing f128 libcalls' calling convention issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90213

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-f128-support-check.c


Index: clang/test/Driver/ppc-f128-support-check.c
===
--- clang/test/Driver/ppc-f128-support-check.c
+++ clang/test/Driver/ppc-f128-support-check.c
@@ -1,7 +1,7 @@
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN:   -mcpu=pwr9 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=power9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN:   -mcpu=power9 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -313,6 +313,9 @@
 .Case("pwr9", true)
 .Case("pwr8", true)
 .Default(false);
+  Features["float128"] = llvm::StringSwitch(CPU)
+.Case("pwr9", true)
+.Default(false);
 
   Features["spe"] = llvm::StringSwitch(CPU)
 .Case("8548", true)


Index: clang/test/Driver/ppc-f128-support-check.c
===
--- clang/test/Driver/ppc-f128-support-check.c
+++ clang/test/Driver/ppc-f128-support-check.c
@@ -1,7 +1,7 @@
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN:   -mcpu=pwr9 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=power9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN:   -mcpu=power9 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -313,6 +313,9 @@
 .Case("pwr9", true)
 .Case("pwr8", true)
 .Default(false);
+  Features["float128"] = llvm::StringSwitch(CPU)
+.Case("pwr9", true)
+.Default(false);
 
   Features["spe"] = llvm::StringSwitch(CPU)
 .Case("8548", true)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D88645: [Annotation] Allows annotation to carry some additional constant arguments.

2020-10-27 Thread Tyker via Phabricator via cfe-commits
Tyker added a comment.

In D88645#2353152 , @thakis wrote:

> Looks like this broke tests: http://45.33.8.238/linux/31159/step_12.txt
>
> Please take a look, and revert for now if it takes a while to fix.

this is fixed by 4afa077899b 


In D88645#2354196 , @john.brawn wrote:

> This also causes the AnnotateFunctions example to no longer build:
>
>   
> /home/jb/work/llvm-project/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp:
>  In member function ‘virtual bool 
> {anonymous}::AnnotateFunctionsConsumer::HandleTopLevelDecl(clang::DeclGroupRef)’:
>   
> /home/jb/work/llvm-project/clang/examples/AnnotateFunctions/AnnotateFunctions.cpp:36:70:
>  error: no matching function for call to 
> ‘clang::AnnotateAttr::CreateImplicit(clang::ASTContext&, const char [19])’
> "example_annotation"));
> ^
>
> it looks like it needs to be adjusted for the extra variadic arg that the 
> attribute now has.

this is fixed by 2618247c61c 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88645

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


[PATCH] D90215: [CMake] Support inter-proto dependencies in generate_protos.

2020-10-27 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kbobyrev.
Herald added subscribers: llvm-commits, cfe-commits, usaxena95, kadircet, 
arphaman, mgorny.
Herald added projects: clang, LLVM.
sammccall requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90215

Files:
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  llvm/cmake/modules/FindGRPC.cmake


Index: llvm/cmake/modules/FindGRPC.cmake
===
--- llvm/cmake/modules/FindGRPC.cmake
+++ llvm/cmake/modules/FindGRPC.cmake
@@ -84,8 +84,9 @@
 # Proto headers are generated in ${CMAKE_CURRENT_BINARY_DIR}.
 # Libraries that use these headers should adjust the include path.
 # If the "GRPC" argument is given, services are also generated.
+# The DEPENDS list should name *.proto source files that are imported.
 function(generate_protos LibraryName ProtoFile)
-  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "")
+  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "DEPENDS")
   get_filename_component(ProtoSourceAbsolutePath 
"${CMAKE_CURRENT_SOURCE_DIR}/${ProtoFile}" ABSOLUTE)
   get_filename_component(ProtoSourcePath ${ProtoSourceAbsolutePath} PATH)
   get_filename_component(Basename ${ProtoSourceAbsolutePath} NAME_WLE)
@@ -111,4 +112,22 @@
   add_clang_library(${LibraryName} ${GeneratedProtoSource}
 PARTIAL_SOURCES_INTENDED
 LINK_LIBS grpc++ protobuf)
+
+  # Ensure dependency headers are generated before dependent protos are built.
+  # FIXME: CMake docs suggest OBJECT_DEPENDS isn't needed, but I can't get the
+  #recommended add_dependencies() approach to work.
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h
+STRING(REGEX REPLACE "\\.proto$" ".pb.h" ImportedHeader "${ImportedProto}")
+# Foo.pb.h -> ${CMAKE_CURRENT_BINARY_DIR}/Foo.pb.h
+get_filename_component(ImportedHeader "${ImportedHeader}"
+  ABSOLUTE
+  BASE_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+# Compilation of each generated source depends on ${BINARY}/Foo.pb.h.
+foreach(Generated IN LISTS GeneratedProtoSource)
+  set_source_files_properties("${Generated}"
+PROPERTIES OBJECT_DEPENDS "${ImportedHeader}")
+endforeach(Generated)
+  endforeach(ImportedProto)
 endfunction()
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -1,13 +1,8 @@
 if (CLANGD_ENABLE_REMOTE)
-  generate_protos(RemoteIndexServiceProto "Service.proto" GRPC)
   generate_protos(RemoteIndexProto "Index.proto")
-  # Ensure dependency headers are generated before dependent protos are built.
-  # FIXME: this should be encapsulated in generate_protos.
-  # FIXME: CMake docs say OBJECT_DEPENDS isn't needed, but I can't get the
-  #recommended add_dependencies() approach to work.
-  set_source_files_properties(
-${CMAKE_CURRENT_BINARY_DIR}/Service.pb.cc
-PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/Index.pb.h)
+  generate_protos(RemoteIndexServiceProto "Service.proto"
+DEPENDS "Index.proto"
+GRPC)
   include_directories(${CMAKE_CURRENT_BINARY_DIR})
   include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../)
 


Index: llvm/cmake/modules/FindGRPC.cmake
===
--- llvm/cmake/modules/FindGRPC.cmake
+++ llvm/cmake/modules/FindGRPC.cmake
@@ -84,8 +84,9 @@
 # Proto headers are generated in ${CMAKE_CURRENT_BINARY_DIR}.
 # Libraries that use these headers should adjust the include path.
 # If the "GRPC" argument is given, services are also generated.
+# The DEPENDS list should name *.proto source files that are imported.
 function(generate_protos LibraryName ProtoFile)
-  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "")
+  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "DEPENDS")
   get_filename_component(ProtoSourceAbsolutePath "${CMAKE_CURRENT_SOURCE_DIR}/${ProtoFile}" ABSOLUTE)
   get_filename_component(ProtoSourcePath ${ProtoSourceAbsolutePath} PATH)
   get_filename_component(Basename ${ProtoSourceAbsolutePath} NAME_WLE)
@@ -111,4 +112,22 @@
   add_clang_library(${LibraryName} ${GeneratedProtoSource}
 PARTIAL_SOURCES_INTENDED
 LINK_LIBS grpc++ protobuf)
+
+  # Ensure dependency headers are generated before dependent protos are built.
+  # FIXME: CMake docs suggest OBJECT_DEPENDS isn't needed, but I can't get the
+  #recommended add_dependencies() approach to work.
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h
+STRING(REGEX REPLACE "\\.proto$" ".pb.h" ImportedHeader "${ImportedProto}")
+# Foo.pb.h -> ${CMAKE_CURRENT_BINARY_DIR}/Foo.pb.h
+get_filename_component(ImportedHeader "${ImportedHeader}"
+  ABS

[PATCH] D84345: [AMDGPU] Set the default globals address space to 1

2020-10-27 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added a comment.
Herald added a subscriber: dexonsmith.

ping @arsenm . I'd really like to land D70947  
so that I can upstream further changes and that review is blocked on this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84345

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


[PATCH] D89851: [clangd] Separate final_result into a different message

2020-10-27 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-tools-extra/clangd/index/remote/Index.proto:15
 
+message FinalResult { optional bool has_more = 1; }
+

this deserves a comment: "Common final result for streaming requests."



Comment at: clang-tools-extra/clangd/index/remote/Index.proto:15
 
+message FinalResult { optional bool has_more = 1; }
+

sammccall wrote:
> this deserves a comment: "Common final result for streaming requests."
this isn't specific to Lookup, so shouldn't go between LookupRequest and 
LookupReply, rather either at the very top or below all the request/reply 
messages.



Comment at: clang-tools-extra/clangd/index/remote/Index.proto:22
 Symbol stream_result = 1;
-bool final_result = 2;
+FinalResult result = 2;
   }

I think stream_result/result suggests that `result` is "primary" which isn't 
the case.
I think the old names stream_result/final_result were clearer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89851

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


[PATCH] D90215: [CMake] Support inter-proto dependencies in generate_protos.

2020-10-27 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: llvm/cmake/modules/FindGRPC.cmake:117
+  # Ensure dependency headers are generated before dependent protos are built.
+  # FIXME: CMake docs suggest OBJECT_DEPENDS isn't needed, but I can't get the
+  #recommended add_dependencies() approach to work.

nit: I would move the fixme near to the `set_source_files_properties`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90215

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


[PATCH] D90215: [CMake] Support inter-proto dependencies in generate_protos.

2020-10-27 Thread Sam McCall via Phabricator via cfe-commits
sammccall updated this revision to Diff 300930.
sammccall marked an inline comment as done.
sammccall added a comment.

Move FIXME to more specific place


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90215

Files:
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  llvm/cmake/modules/FindGRPC.cmake


Index: llvm/cmake/modules/FindGRPC.cmake
===
--- llvm/cmake/modules/FindGRPC.cmake
+++ llvm/cmake/modules/FindGRPC.cmake
@@ -84,8 +84,9 @@
 # Proto headers are generated in ${CMAKE_CURRENT_BINARY_DIR}.
 # Libraries that use these headers should adjust the include path.
 # If the "GRPC" argument is given, services are also generated.
+# The DEPENDS list should name *.proto source files that are imported.
 function(generate_protos LibraryName ProtoFile)
-  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "")
+  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "DEPENDS")
   get_filename_component(ProtoSourceAbsolutePath 
"${CMAKE_CURRENT_SOURCE_DIR}/${ProtoFile}" ABSOLUTE)
   get_filename_component(ProtoSourcePath ${ProtoSourceAbsolutePath} PATH)
   get_filename_component(Basename ${ProtoSourceAbsolutePath} NAME_WLE)
@@ -111,4 +112,22 @@
   add_clang_library(${LibraryName} ${GeneratedProtoSource}
 PARTIAL_SOURCES_INTENDED
 LINK_LIBS grpc++ protobuf)
+
+  # Ensure dependency headers are generated before dependent protos are built.
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h
+STRING(REGEX REPLACE "\\.proto$" ".pb.h" ImportedHeader "${ImportedProto}")
+# Foo.pb.h -> ${CMAKE_CURRENT_BINARY_DIR}/Foo.pb.h
+get_filename_component(ImportedHeader "${ImportedHeader}"
+  ABSOLUTE
+  BASE_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+# Compilation of each generated source depends on ${BINARY}/Foo.pb.h.
+foreach(Generated IN LISTS GeneratedProtoSource)
+  # FIXME: CMake docs suggest OBJECT_DEPENDS isn't needed, but I can't get
+  #the recommended add_dependencies() approach to work.
+  set_source_files_properties("${Generated}"
+PROPERTIES OBJECT_DEPENDS "${ImportedHeader}")
+endforeach(Generated)
+  endforeach(ImportedProto)
 endfunction()
Index: clang-tools-extra/clangd/index/remote/CMakeLists.txt
===
--- clang-tools-extra/clangd/index/remote/CMakeLists.txt
+++ clang-tools-extra/clangd/index/remote/CMakeLists.txt
@@ -1,13 +1,8 @@
 if (CLANGD_ENABLE_REMOTE)
-  generate_protos(RemoteIndexServiceProto "Service.proto" GRPC)
   generate_protos(RemoteIndexProto "Index.proto")
-  # Ensure dependency headers are generated before dependent protos are built.
-  # FIXME: this should be encapsulated in generate_protos.
-  # FIXME: CMake docs say OBJECT_DEPENDS isn't needed, but I can't get the
-  #recommended add_dependencies() approach to work.
-  set_source_files_properties(
-${CMAKE_CURRENT_BINARY_DIR}/Service.pb.cc
-PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/Index.pb.h)
+  generate_protos(RemoteIndexServiceProto "Service.proto"
+DEPENDS "Index.proto"
+GRPC)
   include_directories(${CMAKE_CURRENT_BINARY_DIR})
   include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../)
 


Index: llvm/cmake/modules/FindGRPC.cmake
===
--- llvm/cmake/modules/FindGRPC.cmake
+++ llvm/cmake/modules/FindGRPC.cmake
@@ -84,8 +84,9 @@
 # Proto headers are generated in ${CMAKE_CURRENT_BINARY_DIR}.
 # Libraries that use these headers should adjust the include path.
 # If the "GRPC" argument is given, services are also generated.
+# The DEPENDS list should name *.proto source files that are imported.
 function(generate_protos LibraryName ProtoFile)
-  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "")
+  cmake_parse_arguments(PARSE_ARGV 2 PROTO "GRPC" "" "DEPENDS")
   get_filename_component(ProtoSourceAbsolutePath "${CMAKE_CURRENT_SOURCE_DIR}/${ProtoFile}" ABSOLUTE)
   get_filename_component(ProtoSourcePath ${ProtoSourceAbsolutePath} PATH)
   get_filename_component(Basename ${ProtoSourceAbsolutePath} NAME_WLE)
@@ -111,4 +112,22 @@
   add_clang_library(${LibraryName} ${GeneratedProtoSource}
 PARTIAL_SOURCES_INTENDED
 LINK_LIBS grpc++ protobuf)
+
+  # Ensure dependency headers are generated before dependent protos are built.
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h
+STRING(REGEX REPLACE "\\.proto$" ".pb.h" ImportedHeader "${ImportedProto}")
+# Foo.pb.h -> ${CMAKE_CURRENT_BINARY_DIR}/Foo.pb.h
+get_filename_component(ImportedHeader "${ImportedHeader}"
+  ABSOLUTE
+  BASE_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+# Compilation of each generated source depends on ${BINARY}/Foo.pb.h.
+foreach(Generated IN LIS

[PATCH] D89046: [AST] Build recovery expression by default for all language.

2020-10-27 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 300931.
hokein marked an inline comment as done.
hokein added a comment.
Herald added a subscriber: dexonsmith.

rebase and address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89046

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/builtins-ppc-error.c
  clang/test/CodeGen/builtins-systemz-zvector-error.c
  clang/test/CodeGen/builtins-systemz-zvector2-error.c
  clang/test/CodeGen/builtins-systemz-zvector3-error.c
  clang/test/Index/complete-switch.c
  clang/test/OpenMP/begin_declare_variant_messages.c
  clang/test/OpenMP/declare_variant_messages.c
  clang/test/Parser/objc-foreach-syntax.m
  clang/test/Sema/__try.c
  clang/test/Sema/enum.c
  clang/test/Sema/typo-correction.c

Index: clang/test/Sema/typo-correction.c
===
--- clang/test/Sema/typo-correction.c
+++ clang/test/Sema/typo-correction.c
@@ -14,9 +14,9 @@
   // expected-error {{use of undeclared identifier 'b'}}
 
 int foobar;  // expected-note {{'foobar' declared here}}
-a = goobar ?: 4;  // expected-warning {{type specifier missing, defaults to 'int'}} \
-  // expected-error {{use of undeclared identifier 'goobar'; did you mean 'foobar'?}} \
-  // expected-error {{initializer element is not a compile-time constant}}
+new_a = goobar ?: 4; // expected-warning {{type specifier missing, defaults to 'int'}} \
+  // expected-error {{use of undeclared identifier 'goobar'; did you mean 'foobar'?}} \
+  // expected-error {{initializer element is not a compile-time constant}}
 
 struct ContainerStuct {
   enum { SOME_ENUM }; // expected-note {{'SOME_ENUM' declared here}}
@@ -50,10 +50,10 @@
   cabs(errij);  // expected-error {{use of undeclared identifier 'errij'}}
 }
 
-extern long afunction(int); // expected-note {{'afunction' declared here}}
+extern long afunction(int);
 void fn2() {
-  f(THIS_IS_AN_ERROR, // expected-error {{use of undeclared identifier 'THIS_IS_AN_ERROR'}}
-afunction(afunction_));  // expected-error {{use of undeclared identifier 'afunction_'; did you mean 'afunction'?}}
+  f(THIS_IS_AN_ERROR,   // expected-error {{use of undeclared identifier 'THIS_IS_AN_ERROR'}}
+afunction(afunction_)); // expected-error {{use of undeclared identifier 'afunction_'}}
 }
 
 int d = X ? d : L; // expected-error 2 {{use of undeclared identifier}}
Index: clang/test/Sema/enum.c
===
--- clang/test/Sema/enum.c
+++ clang/test/Sema/enum.c
@@ -100,7 +100,8 @@
 // PR7911
 extern enum PR7911T PR7911V; // expected-warning{{ISO C forbids forward references to 'enum' types}}
 void PR7911F() {
-  switch (PR7911V); // expected-error {{statement requires expression of integer type}}
+  switch (PR7911V) // expected-error {{statement requires expression of integer type}}
+;
 }
 
 char test5[__has_feature(enumerator_attributes) ? 1 : -1];
Index: clang/test/Sema/__try.c
===
--- clang/test/Sema/__try.c
+++ clang/test/Sema/__try.c
@@ -50,9 +50,9 @@
 }  // expected-error{{expected '__except' or '__finally' block}}
 
 void TEST() {
-  __except ( FilterExpression() ) { // expected-warning{{implicit declaration of function '__except' is invalid in C99}} \
-// expected-error{{too few arguments to function call, expected 1, have 0}}
-
+  __except (FilterExpression()) { // expected-warning{{implicit declaration of function '__except' is invalid in C99}} \
+// expected-error{{too few arguments to function call, expected 1, have 0}} \
+// expected-error{{expected ';' after expression}}
   }
 }
 
Index: clang/test/Parser/objc-foreach-syntax.m
===
--- clang/test/Parser/objc-foreach-syntax.m
+++ clang/test/Parser/objc-foreach-syntax.m
@@ -21,5 +21,8 @@
 
 
 static int test7(id keys) {
-  for (id key; in keys) ;  // expected-error {{use of undeclared identifier 'in'}}
+  // FIXME: would be nice to suppress the secondary diagnostics.
+  for (id key; in keys) ;  // expected-error {{use of undeclared identifier 'in'}} \
+   // expected-error {{expected ';' in 'for' statement specifier}} \
+   // expected-warning {{expression result unused}}
 }
Index: clang/test/OpenMP/declare_variant_messages.c
===
--- clang/test/OpenMP/declare_variant_messages.c
+++ clang/test/OpenMP/declare_variant_messages.c
@@ -10,7 +10,7 @@
 #pragma omp declare variant // expected-error {{expected '(' after 'declare variant'}}
 #pragma omp declare variant( // expected-error {{expected expression}} expected-error {{expected ')'}} expected-note {{to ma

[PATCH] D89046: [AST] Build recovery expression by default for all language.

2020-10-27 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-error.c:51
 void testCTF(int index) {
-  vec_ctf(vsi, index); //expected-error {{argument to 
'__builtin_altivec_vcfsx' must be a constant integer}}
-  vec_ctf(vui, index); //expected-error {{argument to 
'__builtin_altivec_vcfsx' must be a constant integer}}
+  vec_ctf(vsi, index); //expected-error {{argument to 
'__builtin_altivec_vcfsx' must be a constant integer}} expected-error 
{{argument to '__builtin_altivec_vcfux' must be a constant integer}}
+  vec_ctf(vui, index); //expected-error {{argument to 
'__builtin_altivec_vcfsx' must be a constant integer}} expected-error 
{{argument to '__builtin_altivec_vcfux' must be a constant integer}}

sammccall wrote:
> hmm, this doesn't exactly look right to me - we know the type of `vsi` so we 
> should only be considering the signed case I thought.
> 
> However the existing diagnostic for `vui` indicates that it's considering the 
> **signed** case, so I guess this is already broken/bad.
yeah, we should know this is the signed case.

after the macro expansion, the code looks like 

```
_Generic((vsi), vector int
   : (vector float)__builtin_altivec_vcfsx((vector int)(vsi), (index)), 
vector unsigned int
   : (vector float)__builtin_altivec_vcfux((vector unsigned int)(vsi), 
(index))); 
```

it is a `GenericSelectionExpr` which contains a switch-like structure (see the 
AST below), so when we traverse it, we will traverse both 
`__builtin_altivec_vcfsx` and `__builtin_altivec_vcfux`.

```
`-GenericSelectionExpr 0x9527238  '__vector float' 
contains-errors
|-ImplicitCastExpr 0x9527220  '__vector int' 

| `-ParenExpr 0x9526980  '__vector int' lvalue
|   `-DeclRefExpr 0x9526960  '__vector int' lvalue Var 0x9526568 
'vsi' '__vector int' non_odr_use_unevaluated
|-VectorType 0x91923c0 '__vector int' altivec 4
| `-BuiltinType 0x91296e0 'int'
|-case  '__vector int' selected
| |-VectorType 0x91923c0 '__vector int' altivec 4
| | `-BuiltinType 0x91296e0 'int'
| `-CStyleCastExpr 0x9526db8  '__vector float' 
contains-errors 
|   `-RecoveryExpr 0x9526d70  '' 
contains-errors lvalue
| |-DeclRefExpr 0x9526bc0  '' Function 
0x95269e8 '__builtin_altivec_vcfsx' '__attribute__((__vector_size__(4 * 
sizeof(float float (__attribute__((__vector_size__(4 * sizeof(int int, 
int)'
| |-CStyleCastExpr 0x9526c68  '__vector int' 
| | `-ImplicitCastExpr 0x9526c50  '__vector int' 
 part_of_explicit_cast
| |   `-ParenExpr 0x9526c30  '__vector int' lvalue
| | `-DeclRefExpr 0x9526be0  '__vector int' lvalue Var 
0x9526568 'vsi' '__vector int'
| `-ParenExpr 0x9526cb0  'const int' lvalue
|   `-DeclRefExpr 0x9526c90  'const int' lvalue ParmVar 
0x95267c8 'index' 'const int'
`-case  '__vector unsigned int'
  |-VectorType 0x9192700 '__vector unsigned int' altivec 4
  | `-BuiltinType 0x9129780 'unsigned int'
  `-CStyleCastExpr 0x95271f8  '__vector float' 
contains-errors 
`-RecoveryExpr 0x95271b0  '' 
contains-errors lvalue
  |-DeclRefExpr 0x9527000  '' Function 
0x9526e28 '__builtin_altivec_vcfux' '__attribute__((__vector_size__(4 * 
sizeof(float float (__attribute__((__vector_size__(4 * sizeof(unsigned 
int unsigned int, int)'
  |-CStyleCastExpr 0x95270a8  '__vector unsigned int' 

  | `-ImplicitCastExpr 0x9527090  '__vector int' 
 part_of_explicit_cast
  |   `-ParenExpr 0x9527070  '__vector int' lvalue
  | `-DeclRefExpr 0x9527020  '__vector int' lvalue Var 
0x9526568 'vsi' '__vector int'
  `-ParenExpr 0x95270f0  'const int' lvalue
`-DeclRefExpr 0x95270d0  'const int' lvalue ParmVar 
0x95267c8 'index' 'const int'
```


> However the existing diagnostic for vui indicates that it's considering the 
> signed case, so I guess this is already broken/bad.

hmm, `vsi` and `vui` have the same type `vector signed int`, so I think there 
is a typo for `vui`, it should be `vector unsigned int`?



Comment at: clang/test/Index/complete-switch.c:9
 
-// RUN: not %clang_cc1 -fsyntax-only -code-completion-at=%s:4:10 %s | 
FileCheck %s -allow-empty
+// RUN: not %clang_cc1 -fsyntax-only -Xclang -fno-recovery-ast 
-code-completion-at=%s:4:10 %s | FileCheck %s -allow-empty
 // CHECK-NOT: COMPLETION: foo

sammccall wrote:
> nit: no need for xclang, this is cc1 already
> 
> I guess this is a crash test (and it also doesn't crash with recovery ast)?
yes, the crash was caused by accesing a null-like ast node. With recovery ast, 
it is not true any more. 



Comment at: clang/test/Sema/__try.c:55
+// expected-error{{too few arguments to function call, expected 1, have 
0}} \
+// expected-error{{expected ';' after expression}}
   }

sammccall wrote:
> this seems bad, am I missing something?
agree, `__except` makes it very confusing

[PATCH] D90121: clang-format: Add a consumer to diagnostics engine

2020-10-27 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Thank you! Your fix looks good for clang-format.

I'm also not familiar with `DiagnosticsEngine`. It would be nice to follow-up 
with folks on that on either removing the defaulted ctor params and possibly 
adding assert-s in the ctor itself, or else updating the bits that assert that 
the client is not a `nullptr` to something that behaves reasonably in this 
case. There could be a good reason why the code is as-is; it would be nice if 
that is documented at the ctor or class level.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90121

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


[PATCH] D69844: [clang][Basic] Integrate SourceLocation with FoldingSet, NFCI

2020-10-27 Thread Mikhail Maltsev 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 rG443ab4d2e012: [clang][Basic] Integrate SourceLocation with 
FoldingSet, NFCI (authored by miyuki).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69844

Files:
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp

Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2193,8 +2193,8 @@
   for (SourceRange range : Ranges) {
 if (!range.isValid())
   continue;
-hash.AddInteger(range.getBegin().getRawEncoding());
-hash.AddInteger(range.getEnd().getRawEncoding());
+hash.Add(range.getBegin());
+hash.Add(range.getEnd());
   }
 }
 
@@ -2216,8 +2216,8 @@
   for (SourceRange range : Ranges) {
 if (!range.isValid())
   continue;
-hash.AddInteger(range.getBegin().getRawEncoding());
-hash.AddInteger(range.getEnd().getRawEncoding());
+hash.Add(range.getBegin());
+hash.Add(range.getEnd());
   }
 }
 
Index: clang/lib/Basic/SourceLocation.cpp
===
--- clang/lib/Basic/SourceLocation.cpp
+++ clang/lib/Basic/SourceLocation.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/PrettyStackTrace.h"
 #include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -45,6 +46,11 @@
   return llvm::DenseMapInfo::getHashValue(ID);
 }
 
+void llvm::FoldingSetTrait::Profile(
+const SourceLocation &X, llvm::FoldingSetNodeID &ID) {
+  ID.AddInteger(X.ID);
+}
+
 void SourceLocation::print(raw_ostream &OS, const SourceManager &SM)const{
   if (!isValid()) {
 OS << "";
Index: clang/lib/Analysis/PathDiagnostic.cpp
===
--- clang/lib/Analysis/PathDiagnostic.cpp
+++ clang/lib/Analysis/PathDiagnostic.cpp
@@ -1083,9 +1083,9 @@
 //===--===//
 
 void PathDiagnosticLocation::Profile(llvm::FoldingSetNodeID &ID) const {
-  ID.AddInteger(Range.getBegin().getRawEncoding());
-  ID.AddInteger(Range.getEnd().getRawEncoding());
-  ID.AddInteger(Loc.getRawEncoding());
+  ID.Add(Range.getBegin());
+  ID.Add(Range.getEnd());
+  ID.Add(static_cast(Loc));
 }
 
 void PathDiagnosticPiece::Profile(llvm::FoldingSetNodeID &ID) const {
@@ -1095,8 +1095,8 @@
   ID.AddInteger((unsigned) getDisplayHint());
   ArrayRef Ranges = getRanges();
   for (const auto &I : Ranges) {
-ID.AddInteger(I.getBegin().getRawEncoding());
-ID.AddInteger(I.getEnd().getRawEncoding());
+ID.Add(I.getBegin());
+ID.Add(I.getEnd());
   }
 }
 
Index: clang/include/clang/Basic/SourceLocation.h
===
--- clang/include/clang/Basic/SourceLocation.h
+++ clang/include/clang/Basic/SourceLocation.h
@@ -26,6 +26,9 @@
 
 template  struct DenseMapInfo;
 
+class FoldingSetNodeID;
+template  struct FoldingSetTrait;
+
 } // namespace llvm
 
 namespace clang {
@@ -87,6 +90,7 @@
   friend class ASTReader;
   friend class ASTWriter;
   friend class SourceManager;
+  friend struct llvm::FoldingSetTrait;
 
   unsigned ID = 0;
 
@@ -501,6 +505,11 @@
 }
   };
 
+  // Allow calling FoldingSetNodeID::Add with SourceLocation object as parameter
+  template <> struct FoldingSetTrait {
+static void Profile(const clang::SourceLocation &X, FoldingSetNodeID &ID);
+  };
+
   // Teach SmallPtrSet how to handle SourceLocation.
   template<>
   struct PointerLikeTypeTraits {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 443ab4d - [clang][Basic] Integrate SourceLocation with FoldingSet, NFCI

2020-10-27 Thread Mikhail Maltsev via cfe-commits

Author: Mikhail Maltsev
Date: 2020-10-27T10:43:39Z
New Revision: 443ab4d2e01246bf93cd410db945dc9ab6adf1b3

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

LOG: [clang][Basic] Integrate SourceLocation with FoldingSet, NFCI

This patch removes the necessity to access the SourceLocation internal
representation in several places that use FoldingSet objects.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Basic/SourceLocation.h
clang/lib/Analysis/PathDiagnostic.cpp
clang/lib/Basic/SourceLocation.cpp
clang/lib/StaticAnalyzer/Core/BugReporter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/SourceLocation.h 
b/clang/include/clang/Basic/SourceLocation.h
index 88ecb7c586d9..fc722b1d563d 100644
--- a/clang/include/clang/Basic/SourceLocation.h
+++ b/clang/include/clang/Basic/SourceLocation.h
@@ -26,6 +26,9 @@ namespace llvm {
 
 template  struct DenseMapInfo;
 
+class FoldingSetNodeID;
+template  struct FoldingSetTrait;
+
 } // namespace llvm
 
 namespace clang {
@@ -87,6 +90,7 @@ class SourceLocation {
   friend class ASTReader;
   friend class ASTWriter;
   friend class SourceManager;
+  friend struct llvm::FoldingSetTrait;
 
   unsigned ID = 0;
 
@@ -501,6 +505,11 @@ namespace llvm {
 }
   };
 
+  // Allow calling FoldingSetNodeID::Add with SourceLocation object as 
parameter
+  template <> struct FoldingSetTrait {
+static void Profile(const clang::SourceLocation &X, FoldingSetNodeID &ID);
+  };
+
   // Teach SmallPtrSet how to handle SourceLocation.
   template<>
   struct PointerLikeTypeTraits {

diff  --git a/clang/lib/Analysis/PathDiagnostic.cpp 
b/clang/lib/Analysis/PathDiagnostic.cpp
index f80b99b99806..b42f47fb68c5 100644
--- a/clang/lib/Analysis/PathDiagnostic.cpp
+++ b/clang/lib/Analysis/PathDiagnostic.cpp
@@ -1083,9 +1083,9 @@ unsigned PathDiagnostic::full_size() {
 
//===--===//
 
 void PathDiagnosticLocation::Profile(llvm::FoldingSetNodeID &ID) const {
-  ID.AddInteger(Range.getBegin().getRawEncoding());
-  ID.AddInteger(Range.getEnd().getRawEncoding());
-  ID.AddInteger(Loc.getRawEncoding());
+  ID.Add(Range.getBegin());
+  ID.Add(Range.getEnd());
+  ID.Add(static_cast(Loc));
 }
 
 void PathDiagnosticPiece::Profile(llvm::FoldingSetNodeID &ID) const {
@@ -1095,8 +1095,8 @@ void PathDiagnosticPiece::Profile(llvm::FoldingSetNodeID 
&ID) const {
   ID.AddInteger((unsigned) getDisplayHint());
   ArrayRef Ranges = getRanges();
   for (const auto &I : Ranges) {
-ID.AddInteger(I.getBegin().getRawEncoding());
-ID.AddInteger(I.getEnd().getRawEncoding());
+ID.Add(I.getBegin());
+ID.Add(I.getEnd());
   }
 }
 

diff  --git a/clang/lib/Basic/SourceLocation.cpp 
b/clang/lib/Basic/SourceLocation.cpp
index 2ff17973323e..fde139932c40 100644
--- a/clang/lib/Basic/SourceLocation.cpp
+++ b/clang/lib/Basic/SourceLocation.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/PrettyStackTrace.h"
 #include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -45,6 +46,11 @@ unsigned SourceLocation::getHashValue() const {
   return llvm::DenseMapInfo::getHashValue(ID);
 }
 
+void llvm::FoldingSetTrait::Profile(
+const SourceLocation &X, llvm::FoldingSetNodeID &ID) {
+  ID.AddInteger(X.ID);
+}
+
 void SourceLocation::print(raw_ostream &OS, const SourceManager &SM)const{
   if (!isValid()) {
 OS << "";

diff  --git a/clang/lib/StaticAnalyzer/Core/BugReporter.cpp 
b/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
index ebad1d1b67b4..bf38891b370a 100644
--- a/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ b/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2193,8 +2193,8 @@ void BasicBugReport::Profile(llvm::FoldingSetNodeID& 
hash) const {
   for (SourceRange range : Ranges) {
 if (!range.isValid())
   continue;
-hash.AddInteger(range.getBegin().getRawEncoding());
-hash.AddInteger(range.getEnd().getRawEncoding());
+hash.Add(range.getBegin());
+hash.Add(range.getEnd());
   }
 }
 
@@ -2216,8 +2216,8 @@ void 
PathSensitiveBugReport::Profile(llvm::FoldingSetNodeID &hash) const {
   for (SourceRange range : Ranges) {
 if (!range.isValid())
   continue;
-hash.AddInteger(range.getBegin().getRawEncoding());
-hash.AddInteger(range.getEnd().getRawEncoding());
+hash.Add(range.getBegin());
+hash.Add(range.getEnd());
   }
 }
 



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


[PATCH] D89851: [clangd] Separate final_result into a different message

2020-10-27 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 300936.
kbobyrev marked 3 inline comments as done.
kbobyrev added a comment.

Address post-LGTM comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89851

Files:
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/server/Server.cpp

Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -109,7 +109,7 @@
   ++Sent;
 });
 LookupReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -142,7 +142,7 @@
   ++Sent;
 });
 FuzzyFindReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -173,7 +173,7 @@
   ++Sent;
 });
 RefsReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -207,7 +207,7 @@
   ++Sent;
 });
 RelationsReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
Index: clang-tools-extra/clangd/index/remote/Index.proto
===
--- clang-tools-extra/clangd/index/remote/Index.proto
+++ clang-tools-extra/clangd/index/remote/Index.proto
@@ -10,6 +10,9 @@
 
 package clang.clangd.remote;
 
+// Common final result for streaming requests.
+message FinalResult { optional bool has_more = 1; }
+
 message LookupRequest { repeated string ids = 1; }
 
 // The response is a stream of symbol messages and the terminating message
@@ -17,7 +20,7 @@
 message LookupReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2;
+FinalResult final_result = 2;
   }
 }
 
@@ -36,7 +39,7 @@
 message FuzzyFindReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -51,7 +54,7 @@
 message RefsReply {
   oneof kind {
 Ref stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -116,7 +119,7 @@
 message RelationsReply {
   oneof kind {
 Relation stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -52,7 +52,7 @@
 unsigned FailedToParse = 0;
 while (Reader->Read(&Reply)) {
   if (!Reply.has_stream_result()) {
-FinalResult = Reply.final_result();
+FinalResult = Reply.final_result().has_more();
 continue;
   }
   auto Response = ProtobufMarshaller->fromProtobuf(Reply.stream_result());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] d26dd74 - [clangd] Separate final_result into a different message

2020-10-27 Thread Kirill Bobyrev via cfe-commits

Author: Kirill Bobyrev
Date: 2020-10-27T11:46:16+01:00
New Revision: d26dd743084a886382204ede5eeed146cd29fcd6

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

LOG: [clangd] Separate final_result into a different message

This is a breaking change in remote index protocol.

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/index/remote/Client.cpp
clang-tools-extra/clangd/index/remote/Index.proto
clang-tools-extra/clangd/index/remote/server/Server.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/remote/Client.cpp 
b/clang-tools-extra/clangd/index/remote/Client.cpp
index a134d9c72932..ff6f1b2898d7 100644
--- a/clang-tools-extra/clangd/index/remote/Client.cpp
+++ b/clang-tools-extra/clangd/index/remote/Client.cpp
@@ -52,7 +52,7 @@ class IndexClient : public clangd::SymbolIndex {
 unsigned FailedToParse = 0;
 while (Reader->Read(&Reply)) {
   if (!Reply.has_stream_result()) {
-FinalResult = Reply.final_result();
+FinalResult = Reply.final_result().has_more();
 continue;
   }
   auto Response = ProtobufMarshaller->fromProtobuf(Reply.stream_result());

diff  --git a/clang-tools-extra/clangd/index/remote/Index.proto 
b/clang-tools-extra/clangd/index/remote/Index.proto
index 7619d0cb2ef3..27d17c77192b 100644
--- a/clang-tools-extra/clangd/index/remote/Index.proto
+++ b/clang-tools-extra/clangd/index/remote/Index.proto
@@ -10,6 +10,9 @@ syntax = "proto2";
 
 package clang.clangd.remote;
 
+// Common final result for streaming requests.
+message FinalResult { optional bool has_more = 1; }
+
 message LookupRequest { repeated string ids = 1; }
 
 // The response is a stream of symbol messages and the terminating message
@@ -17,7 +20,7 @@ message LookupRequest { repeated string ids = 1; }
 message LookupReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2;
+FinalResult final_result = 2;
   }
 }
 
@@ -36,7 +39,7 @@ message FuzzyFindRequest {
 message FuzzyFindReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -51,7 +54,7 @@ message RefsRequest {
 message RefsReply {
   oneof kind {
 Ref stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -116,7 +119,7 @@ message RelationsRequest {
 message RelationsReply {
   oneof kind {
 Relation stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 

diff  --git a/clang-tools-extra/clangd/index/remote/server/Server.cpp 
b/clang-tools-extra/clangd/index/remote/server/Server.cpp
index 7b68549a4afd..38bb754e17cf 100644
--- a/clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ b/clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -109,7 +109,7 @@ class RemoteIndexServer final : public 
v1::SymbolIndex::Service {
   ++Sent;
 });
 LookupReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -142,7 +142,7 @@ class RemoteIndexServer final : public 
v1::SymbolIndex::Service {
   ++Sent;
 });
 FuzzyFindReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -173,7 +173,7 @@ class RemoteIndexServer final : public 
v1::SymbolIndex::Service {
   ++Sent;
 });
 RefsReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -207,7 +207,7 @@ class RemoteIndexServer final : public 
v1::SymbolIndex::Service {
   ++Sent;
 });
 RelationsReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);



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


[PATCH] D89851: [clangd] Separate final_result into a different message

2020-10-27 Thread Kirill Bobyrev 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 rGd26dd743084a: [clangd] Separate final_result into a 
different message (authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89851

Files:
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/server/Server.cpp

Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -109,7 +109,7 @@
   ++Sent;
 });
 LookupReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -142,7 +142,7 @@
   ++Sent;
 });
 FuzzyFindReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -173,7 +173,7 @@
   ++Sent;
 });
 RefsReply LastMessage;
-LastMessage.set_final_result(HasMore);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
@@ -207,7 +207,7 @@
   ++Sent;
 });
 RelationsReply LastMessage;
-LastMessage.set_final_result(true);
+LastMessage.mutable_final_result()->set_has_more(true);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
 SPAN_ATTACH(Tracer, "Failed to send", FailedToSend);
Index: clang-tools-extra/clangd/index/remote/Index.proto
===
--- clang-tools-extra/clangd/index/remote/Index.proto
+++ clang-tools-extra/clangd/index/remote/Index.proto
@@ -10,6 +10,9 @@
 
 package clang.clangd.remote;
 
+// Common final result for streaming requests.
+message FinalResult { optional bool has_more = 1; }
+
 message LookupRequest { repeated string ids = 1; }
 
 // The response is a stream of symbol messages and the terminating message
@@ -17,7 +20,7 @@
 message LookupReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2;
+FinalResult final_result = 2;
   }
 }
 
@@ -36,7 +39,7 @@
 message FuzzyFindReply {
   oneof kind {
 Symbol stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -51,7 +54,7 @@
 message RefsReply {
   oneof kind {
 Ref stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
@@ -116,7 +119,7 @@
 message RelationsReply {
   oneof kind {
 Relation stream_result = 1;
-bool final_result = 2; // HasMore
+FinalResult final_result = 2;
   }
 }
 
Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -52,7 +52,7 @@
 unsigned FailedToParse = 0;
 while (Reader->Read(&Reply)) {
   if (!Reply.has_stream_result()) {
-FinalResult = Reply.final_result();
+FinalResult = Reply.final_result().has_more();
 continue;
   }
   auto Response = ProtobufMarshaller->fromProtobuf(Reply.stream_result());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Dmitry Polukhin via Phabricator via cfe-commits
DmitryPolukhin added a comment.

@Hiralo, it looks like you uploaded wrong diff because your previous revision 
is shown as "base" version. Base revision should be clang-tidy sources without 
your changes.

Please add Lit test for the new option, see 
https://llvm.org/docs/TestingGuide.html for more details and existing 
clang-tidy tests.




Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:330
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {

I think you can make this option much simpler if you just read file content and 
use it or `Config` here. No changes in 
clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.


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

https://reviews.llvm.org/D89936

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


[PATCH] D89046: [AST] Build recovery expression by default for all language.

2020-10-27 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a subscriber: hubert.reinterpretcast.
hokein added a comment.

@hubert.reinterpretcast, similar to D78350 , 
could you help to test this patch with your downstream clang? this patch is 
based on 2c2dc7c392a3f28d4dbec3018e3137d5d4f8c6c8 
. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89046

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


[PATCH] D90221: Include attribute details when dumping AST in JSON

2020-10-27 Thread Lev Aronsky via Phabricator via cfe-commits
aronsky created this revision.
aronsky added reviewers: aaron.ballman, steveire.
aronsky created this object with visibility "All Users".
Herald added subscribers: cfe-commits, mgorny.
Herald added a project: clang.
aronsky requested review of this revision.

AST dumps in JSON format were missing attribute nodes, compared to the textual 
dumps. This commit fixes the issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90221

Files:
  clang/include/clang/AST/CMakeLists.txt
  clang/include/clang/AST/JSONNodeDumper.h
  clang/lib/AST/JSONNodeDumper.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -59,6 +59,8 @@
   llvm::raw_ostream &OS);
 void EmitClangAttrTextNodeDump(llvm::RecordKeeper &Records,
llvm::raw_ostream &OS);
+void EmitClangAttrJSONNodeDump(llvm::RecordKeeper &Records,
+   llvm::raw_ostream &OS);
 void EmitClangAttrNodeTraverse(llvm::RecordKeeper &Records,
llvm::raw_ostream &OS);
 
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -41,6 +41,7 @@
   GenClangAttrParsedAttrImpl,
   GenClangAttrParsedAttrKinds,
   GenClangAttrTextNodeDump,
+  GenClangAttrJSONNodeDump,
   GenClangAttrNodeTraverse,
   GenClangBasicReader,
   GenClangBasicWriter,
@@ -138,6 +139,8 @@
"Generate a clang parsed attribute kinds"),
 clEnumValN(GenClangAttrTextNodeDump, "gen-clang-attr-text-node-dump",
"Generate clang attribute text node dumper"),
+clEnumValN(GenClangAttrJSONNodeDump, "gen-clang-attr-json-node-dump",
+   "Generate clang attribute JSON node dumper"),
 clEnumValN(GenClangAttrNodeTraverse, "gen-clang-attr-node-traverse",
"Generate clang attribute traverser"),
 clEnumValN(GenClangDiagsDefs, "gen-clang-diags-defs",
@@ -295,6 +298,9 @@
   case GenClangAttrTextNodeDump:
 EmitClangAttrTextNodeDump(Records, OS);
 break;
+  case GenClangAttrJSONNodeDump:
+EmitClangAttrJSONNodeDump(Records, OS);
+break;
   case GenClangAttrNodeTraverse:
 EmitClangAttrNodeTraverse(Records, OS);
 break;
Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -24,6 +24,7 @@
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/JSON.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
@@ -3895,7 +3896,7 @@
  << "}\n";
 }
 
-// Emits the code to dump an attribute.
+// Emits the code to dump an attribute as text.
 void EmitClangAttrTextNodeDump(RecordKeeper &Records, raw_ostream &OS) {
   emitSourceFileHeader("Attribute text node dumper", OS);
 
@@ -3932,6 +3933,58 @@
   }
 }
 
+// Emits the code to dump an attribute as JSON.
+void EmitClangAttrJSONNodeDump(RecordKeeper &Records, raw_ostream &OS) {
+  emitSourceFileHeader("Attribute text node dumper", OS);
+
+  std::vector Attrs = Records.getAllDerivedDefinitions("Attr"), Args;
+  for (const auto *Attr : Attrs) {
+const Record &R = *Attr;
+if (!R.getValueAsBit("ASTNode"))
+  continue;
+
+OS << "  void Visit" << R.getName() << "Attr(const " << R.getName()
+   << "Attr *A) {\n";
+
+// If the attribute has a semantically-meaningful name (which is determined
+// by whether there is a Spelling enumeration for it), then write out the
+// spelling used for the attribute.
+
+std::string FunctionContent;
+llvm::raw_string_ostream SS(FunctionContent);
+
+Args = R.getValueAsListOfDefs("Args");
+
+if (!Args.empty())
+  OS << "const auto *SA = cast<" << R.getName()
+ << "Attr>(A); (void)SA;\n"
+ << "llvm::json::Array Args;\n";
+
+std::vector Spellings = GetFlattenedSpellings(R);
+if (Spellings.size() > 1 && !SpellingNamesAreCommon(Spellings))
+  OS << "JOS.attribute(\"spelling\", A->getSpelling());\n";
+
+for (const auto *Arg : Args) {
+  std::string ArgContent;
+  llvm::raw_string_ostream SS(ArgContent);
+
+  createArgument(*Arg, R.getName())->writeDump(SS);
+
+  if (SS.tell())
+OS << "{\n"
+   << "std::string Str;\n"
+   << "llvm::raw_string_ostream OS(Str);\n"
+   << SS.str() << "Args.push_back(OS.str());\n"
+   << "}\n";
+}
+
+if (!A

[PATCH] D90221: Include attribute details when dumping AST in JSON

2020-10-27 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Are there tests missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90221

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


[PATCH] D90221: Include attribute details when dumping AST in JSON

2020-10-27 Thread Lev Aronsky via Phabricator via cfe-commits
aronsky added a comment.

In D90221#2356062 , @lebedev.ri wrote:

> Are there tests missing?

Quite possible. I followed the trail of the existing functions to figure out 
the difference between JSON and textual dumping, and tried replicating 
everything in a manner similar to the existing code. I haven't run into any 
tests, but that's probably because I wasn't looking for those. I'll add the 
appropriate tests ASAP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90221

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


[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added inline comments.



Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:330
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {

DmitryPolukhin wrote:
> I think you can make this option much simpler if you just read file content 
> and use it or `Config` here. No changes in 
> clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.
Sorry, didn't get. Can you please elaborate/pseudocode?



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

https://reviews.llvm.org/D89936

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


[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added inline comments.



Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:330
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {

Hiralo wrote:
> DmitryPolukhin wrote:
> > I think you can make this option much simpler if you just read file content 
> > and use it or `Config` here. No changes in 
> > clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.
> Sorry, didn't get. Can you please elaborate/pseudocode?
> 
> I think you can make this option much simpler if you just read file content 
> and use it or `Config` here. No changes in 
> clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.

Are you suggesting to...
(a) as per this patch have option '--config-file' (ClangTidyMain.cpp changes)
(b) read this file in ClangTidyMain.cpp itself and 
(c) pass YAML o/p to code-flow-of-config option (again change only in 
ClangTidyMain.cpp).

if so...

Shouldn't at call to tryReadConfigFile() kind of call in ClangTidyMain.cpp?

Can you please point me to LLVM/Clang File IO calls/examples?


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

https://reviews.llvm.org/D89936

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


[clang] 8503253 - [clang-format] Fix misformatted macro definitions after D86959

2020-10-27 Thread Alex Richardson via cfe-commits

Author: Alex Richardson
Date: 2020-10-27T12:16:46Z
New Revision: 850325348ae82cd5e26ea9edfd04219d0fbe7828

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

LOG: [clang-format] Fix misformatted macro definitions after D86959

After D86959 the code `#define lambda [](const decltype(x) &ptr) {}`
was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to
now parsing the '&' token as a BinaryOperator. The problem was caused by
the condition `Line.InPPDirective && (!Left->Previous || 
!Left->Previous->is(tok::identifier))) {`
being matched and therefore not performing the checks for "previous token
is one of decltype/_Atomic/etc.". This patch moves those checks after the
existing if/else chain to ensure the left-parent token classification is
always run after checking whether the contents of the parens is an
expression or not.

This change also introduces a new TokenAnnotatorTest that checks the
token kind and Role of Tokens after analyzing them. This is used to check
for TT_PointerOrReference, in addition to indirectly testing this based
on the resulting formatting.

Reviewed By: MyDeveloperDay

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

Added: 
clang/unittests/Format/TokenAnnotatorTest.cpp

Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/CMakeLists.txt
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TestLexer.h

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 66a8cacbb4af..22dcd7521dbe 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -256,16 +256,6 @@ class AnnotatingParser {
 } else if (Contexts[Contexts.size() - 2].CaretFound) {
   // This is the parameter list of an ObjC block.
   Contexts.back().IsExpression = false;
-} else if (PrevNonComment && PrevNonComment->is(tok::kw___attribute)) {
-  Left->setType(TT_AttributeParen);
-} else if (PrevNonComment &&
-   PrevNonComment->isOneOf(TT_TypenameMacro, tok::kw_decltype,
-   tok::kw_typeof, tok::kw__Atomic,
-   tok::kw___underlying_type)) {
-  Left->setType(TT_TypeDeclarationParen);
-  // decltype() and typeof() usually contain expressions.
-  if (PrevNonComment->isOneOf(tok::kw_decltype, tok::kw_typeof))
-Contexts.back().IsExpression = true;
 } else if (Left->Previous && Left->Previous->is(TT_ForEachMacro)) {
   // The first argument to a foreach macro is a declaration.
   Contexts.back().IsForEachMacro = true;
@@ -279,6 +269,21 @@ class AnnotatingParser {
   Contexts.back().IsExpression = !IsForOrCatch;
 }
 
+// Infer the role of the l_paren based on the previous token if we haven't
+// detected one one yet.
+if (PrevNonComment && Left->is(TT_Unknown)) {
+  if (PrevNonComment->is(tok::kw___attribute)) {
+Left->setType(TT_AttributeParen);
+  } else if (PrevNonComment->isOneOf(TT_TypenameMacro, tok::kw_decltype,
+ tok::kw_typeof, tok::kw__Atomic,
+ tok::kw___underlying_type)) {
+Left->setType(TT_TypeDeclarationParen);
+// decltype() and typeof() usually contain expressions.
+if (PrevNonComment->isOneOf(tok::kw_decltype, tok::kw_typeof))
+  Contexts.back().IsExpression = true;
+  }
+}
+
 if (StartsObjCMethodExpr) {
   Contexts.back().ColonIsObjCMethodExpr = true;
   Left->setType(TT_ObjCMethodExpr);

diff  --git a/clang/unittests/Format/CMakeLists.txt 
b/clang/unittests/Format/CMakeLists.txt
index 472e6eec40af..281ebc2d411c 100644
--- a/clang/unittests/Format/CMakeLists.txt
+++ b/clang/unittests/Format/CMakeLists.txt
@@ -21,6 +21,7 @@ add_clang_unittest(FormatTests
   SortImportsTestJava.cpp
   SortIncludesTest.cpp
   UsingDeclarationsSorterTest.cpp
+  TokenAnnotatorTest.cpp
   )
 
 clang_target_link_libraries(FormatTests

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index be9c84332265..0c08eb55be5f 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -8197,6 +8197,12 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
   verifyFormat("void f() { MACRO(A * B); }");
   verifyFormat("void f() { MACRO(A & B); }");
 
+  // This lambda was mis-formatted after D88956 (treating it as a binop):
+  verifyFormat("auto x = [](const decltype(x) &ptr) {};");
+  verifyFormat("auto x = [](const decltype(x) *ptr) {};");
+  verifyFormat("#define lambda [](const decltype(x) &ptr) {}");
+  verifyFormat("#define lambda [](const decltype(x) *ptr) {}");
+
   verifyFormat("DatumHandle 

[PATCH] D88956: [clang-format] Fix misformatted macro definitions after D86959

2020-10-27 Thread Alexander Richardson 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 rG850325348ae8: [clang-format] Fix misformatted macro 
definitions after D86959 (authored by arichardson).

Changed prior to commit:
  https://reviews.llvm.org/D88956?vs=299054&id=300961#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88956

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/CMakeLists.txt
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TestLexer.h
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- /dev/null
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -0,0 +1,70 @@
+//===- unittest/Format/TokenAnnotatorTest.cpp - Formatting unit tests -===//
+//
+// 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 "clang/Format/Format.h"
+
+#include "FormatTestUtils.h"
+#include "TestLexer.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace format {
+namespace {
+
+class TokenAnnotatorTest : public ::testing::Test {
+protected:
+  TokenList annotate(llvm::StringRef Code,
+ const FormatStyle &Style = getLLVMStyle()) {
+return TestLexer(Style).annotate(Code);
+  }
+};
+
+#define EXPECT_TOKEN_KIND(FormatTok, Kind) \
+  EXPECT_EQ((FormatTok)->Tok.getKind(), Kind) << *(FormatTok)
+#define EXPECT_TOKEN_TYPE(FormatTok, Type) \
+  EXPECT_EQ((FormatTok)->getType(), Type) << *(FormatTok)
+#define EXPECT_TOKEN(FormatTok, Kind, Type)\
+  do { \
+EXPECT_TOKEN_KIND(FormatTok, Kind);\
+EXPECT_TOKEN_TYPE(FormatTok, Type);\
+  } while (false);
+
+TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmpInMacroDefinition) {
+  // This is a regression test for mis-parsing the & after decltype as a binary
+  // operator instead of a reference (when inside a macro definition).
+  auto Tokens = annotate("auto x = [](const decltype(x) &ptr) {};");
+  EXPECT_EQ(Tokens.size(), 18u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_decltype, TT_Unknown);
+  EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[9], tok::identifier, TT_Unknown);
+  EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
+  // Same again with * instead of &:
+  Tokens = annotate("auto x = [](const decltype(x) *ptr) {};");
+  EXPECT_EQ(Tokens.size(), 18u) << Tokens;
+  EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
+
+  // Also check that we parse correctly within a macro definition:
+  Tokens = annotate("#define lambda [](const decltype(x) &ptr) {}");
+  EXPECT_EQ(Tokens.size(), 17u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_decltype, TT_Unknown);
+  EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[9], tok::identifier, TT_Unknown);
+  EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
+  // Same again with * instead of &:
+  Tokens = annotate("#define lambda [](const decltype(x) *ptr) {}");
+  EXPECT_EQ(Tokens.size(), 17u) << Tokens;
+  EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
+  EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
+}
+
+} // namespace
+} // namespace format
+} // namespace clang
Index: clang/unittests/Format/TestLexer.h
===
--- clang/unittests/Format/TestLexer.h
+++ clang/unittests/Format/TestLexer.h
@@ -16,6 +16,9 @@
 #define CLANG_UNITTESTS_FORMAT_TESTLEXER_H
 
 #include "../../lib/Format/FormatTokenLexer.h"
+#include "../../lib/Format/TokenAnalyzer.h"
+#include "../../lib/Format/TokenAnnotator.h"
+#include "../../lib/Format/UnwrappedLineParser.h"
 
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/SourceManager.h"
@@ -29,7 +32,8 @@
 typedef llvm::SmallVector TokenList;
 
 inline std::ostream &operator<<(std::ostream &Stream, const FormatToken &Tok) {
-  Stream << "(" << Tok.Tok.getName() << ", \"" << Tok.TokenText.str() << "\")";
+  Stream << "(" << Tok.Tok.getName() << ", \"" << Tok.TokenText.str() << "\" , "
+ << getTokenTypeName(Tok.getType()) << ")";
   return Stream;
 }
 inline std::os

[PATCH] D88913: [FPEnv] Use strictfp metadata in casting nodes

2020-10-27 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment.

In D88913#2353379 , @sepavloff wrote:

> Generally the patch looks good. But the need to expect incorrect values in 
> tests is a concern. Maybe this is a consequence of storing exception behavior 
> in a separate field of CGFPOptionsRAII. This misbehavior should be fixed.

In this patch? Because that's going to be a huge patch. Fixing all the issues 
with strictfp AST->IRBuilder is going to be large. Fixing them incrementally 
seems better to me. Eliminating the incorrect values in the tests marked FIXME 
would sweep the problem under the rug.

It's true that incorrect values in tests is _not_ the desired end state. But it 
seems to me that as a _temporary_ incremental step it beats the alternatives.




Comment at: clang/test/CodeGen/aarch64-v8.2a-neon-intrinsics-constrained.c:26
+// metadata from the AST instead of the global default from the command line.
+// FIXME: All cases of "fpexcept.maytrap" in this test are wrong.
+

sepavloff wrote:
> kpn wrote:
> > kpn wrote:
> > > sepavloff wrote:
> > > > kpn wrote:
> > > > > sepavloff wrote:
> > > > > > Why they are wrong?
> > > > > Because the #pragma covers the entire file and sets exception 
> > > > > handling to "strict". Thus all constrained intrinsic calls should be 
> > > > > "strict", and if they are "maytrap" or "ignore" then we have a bug.
> > > > What is the reason for that? Does `#pragma float_control` work 
> > > > incorrectly? Why  in `clang/test/CodeGen/complex-math-strictfp.c` 
> > > > exception handling is correct?
> > > The #pragma works just fine. The problem is that we need to get the 
> > > strictfp bits from the AST to the IRBuilder, and we haven't finished 
> > > implementing that. So sometimes it works, like in 
> > > complex-math-strictfp.c, and sometimes it doesn't. As you can see in the 
> > > tests in this patch.
> > I forgot to mention that complex-math-strictfp.c gets a correct BinOpInfo 
> > passed down to get the IRBuilder set correctly. But there are other places 
> > that don't correctly set BinOpInfo and so we get inconsistent behavior 
> > despite the call to the IRBuilder being wrapped in FPOptsRAII. And _that's_ 
> > why I structured this patch the way I did.
> > The problem is that we need to get the strictfp bits from the AST to the 
> > IRBuilder
> 
> What is the status of this problem? Is it on track?
This is a larger problem that we need to tackle incrementally. I'd like to get 
a signoff on the approach taken in this patch before going too far down the 
road of writing fixes for all the issues we have here. But it is at the top of 
my list.


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

https://reviews.llvm.org/D88913

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


[PATCH] D90215: [CMake] Support inter-proto dependencies in generate_protos.

2020-10-27 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added inline comments.



Comment at: llvm/cmake/modules/FindGRPC.cmake:118
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h

On line 89 the argument is called `DEPENDS` (also in the comments) but here it 
is called `PROTO_DEPENDS`, I think this is a typo?



Comment at: llvm/cmake/modules/FindGRPC.cmake:124
+  ABSOLUTE
+  BASE_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+# Compilation of each generated source depends on ${BINARY}/Foo.pb.h.

This relies on the protos being generated from the same directory which is 
probably a very restrictive requirement. I don't see a better solution other 
than specifying dirs/full paths to the files in arguments but that does not 
seem nice, too. Maybe add a FIXME?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90215

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


[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo added inline comments.



Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:330
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {

Hiralo wrote:
> Hiralo wrote:
> > DmitryPolukhin wrote:
> > > I think you can make this option much simpler if you just read file 
> > > content and use it or `Config` here. No changes in 
> > > clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.
> > Sorry, didn't get. Can you please elaborate/pseudocode?
> > 
> > I think you can make this option much simpler if you just read file content 
> > and use it or `Config` here. No changes in 
> > clang-tools-extra/clang-tidy/ClangTidyOptions.h/.cpp will be required.
> 
> Are you suggesting to...
> (a) as per this patch have option '--config-file' (ClangTidyMain.cpp changes)
> (b) read this file in ClangTidyMain.cpp itself and 
> (c) pass YAML o/p to code-flow-of-config option (again change only in 
> ClangTidyMain.cpp).
> 
> if so...
> 
> Shouldn't at call to tryReadConfigFile() kind of call in ClangTidyMain.cpp?
> 
> Can you please point me to LLVM/Clang File IO calls/examples?
From code point of view... within ClangTidyMain.cpp itself... code-flow may 
look...

```
llvm::ErrorOr> Text = 
llvm::MemoryBuffer::getFile(ConfigFile.c_str());
if (std::error_code EC = Text.getError()) {
  llvm::errs() << "Can't read " << ConfigFile << ": " << EC.message() << "\n";
}

and then

Configassign(ConfigFile);
from then onwards it will be considered as Config values
```

Let me try implementing and test...


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

https://reviews.llvm.org/D89936

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


[PATCH] D89743: Support Attr in DynTypedNode and ASTMatchers.

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a subscriber: klimek.
aaron.ballman added a comment.

In D89743#2348487 , @sammccall wrote:

> In D89743#2342229 , @aaron.ballman 
> wrote:
>
>> My preference is to add support for `hasName()` as that's going to be the 
>> most common need for matching attributes.
>
> Sounds good (though I ran into issues calling this `hasName` specifically, 
> see below). There's overlap with hasAttr(Kind) but I think that only handles 
> decls, you can't bind the attribute itself, and it's harder to extend to the 
> other stuff you mentioned.
> So maybe hasAttr gets deprecated, or maybe `has(attr(hasName("foo")))` is a 
> mouthful for a common case so the shorthand is nice.

I was sort of expecting `hasAttr()` to be deprecated because it is a leaky 
abstraction (consumers of the API have to know about our internal naming 
convention for attribute kind enumerations, it makes it harder for use to 
change the definition of the enumeration, etc.

>> If you also added support for matching which syntax is used, support 
>> attributes for `hasArgument()` (which I suppose could be interesting given 
>> that there are the parsed attribute arguments and the semantic attribute 
>> arguments, and they may differ), etc, I certainly wouldn't complain, but I 
>> think at least name matching support is required to make the matcher 
>> marginally useful.
>
> Yeah, in the interests of time I think i'll need to stop there (my 
> understanding of the attribute model is pretty superficial).

That's fine by me, thank you for the bits you've done!

>> I'm totally fine if this happens in a follow-up patch (or patches). WDYT?
>
> For `hasAttrName` and `isImplicit` (which simplifies the tests), I've tried 
> to fold it into this patch, it's simple enough.
> I went with `hasAttrName` (matching `Attr::getAttrName()`) because I wasn't 
> easily able to get `attrName` to work.
>
> The issue is that `hasName` is already the name of a Decl matcher with the 
> same signature, so we'd have to make it polymorphic.
> (This means they'd appear to be one matcher, with one set of docs etc, 
> despite having very different semantics - doesn't really seem right...)

I definitely don't agree that `hasName()` has different semantics for 
attributes from declarations -- both of them are named identifiers, potentially 
with scope information as part of the name. Making the matcher polymorphic 
matches my expectations (pun intended).

> The implementation of the Decl version is the fairly complex HasNameMatcher 
> (shared with `hasAnyName`) that copies strings into a vector on construction. 
> This doesn't fit into the polymorphic matcher model as far as I can find, so 
> we're adding heap allocations to the fastpath of matching hasName("foo") 
> which seems... not obviously a good tradeoff.

This, on the other hand, is a very good reason to not push forward with those 
changes yet.

> If you think the `hasName` name is important I'm happy to drop `hasAttrName` 
> from this patch, and someone can work out how to add it with the better name, 
> but I'm not sure I want to pick this battle with the template gods...

I'm curious if @klimek agrees, but I think `hasName()` is the correct way we 
want to eventually go. That said, I think having an attribute matcher with no 
way to match by name encourages an anti-pattern where people write a very 
generic matcher that matches a lot and then do further refinement work for 
every match (rather than taking advantage of memoization and other 
optimizations), so I think `hasAttrName()` is still better than nothing. Would 
it make sense to add the API but mark it as deprecated to alert users that this 
API may go away some day if we can swing it? It's a bit unfriendly since we 
don't have a replacement API lined up for users to use, so I wouldn't want to 
issue any diagnostics for using the matcher.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:6764
+AST_MATCHER_P(Attr, hasAttrName, llvm::StringRef, Name) {
+  return Node.getAttrName() && Node.getAttrName()->isStr(Name);
+}

If you want to avoid duplicating the call to `getAttrName()` (I don't insist).
```
if (const IdentifierInfo *II = Node.getAttrName())
  return II->isStr(Name);
return false;
```



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:729
 
- private:
+  static bool matchesNode(const NamedDecl &Node, StringRef Name);
+

Are the changes to the `HasNameMatcher` needed?



Comment at: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp:1893
+  attr(hasAttrName("nonnull";
+  // On windows, some nodes an implicit visibility attribute.
+  EXPECT_TRUE(

nodes an -> nodes create an


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89743

_

[PATCH] D90157: [analyzer] Rework SValBuilder::evalCast function into maintainable and clear way

2020-10-27 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> Now I'm going to make unittests for SValBuilder::evalCast. Let me ask you to 
> offer me some examples of casts to check. As many cases we can collect as 
> robust the test would be. E.g.

This is not going to be easy. I guess we should cover both implicit and 
explicit type conversions. C++ is ridiculously complex in these domains. For 
maximal precision I'd suggest to systematically go through the below pages and 
try to cover each major case:
https://en.cppreference.com/w/cpp/language/explicit_cast
https://en.cppreference.com/w/cpp/language/implicit_conversion




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h:105
 
-  SVal evalCast(SVal val, QualType castTy, QualType originalType);
+  SVal evalCast(SVal V, QualType CastTy, QualType OriginalTy);
+  SVal evalCastKind(UndefinedVal V, QualType CastTy, QualType OriginalTy);

+1 for this kind of splitting, makes the code cleaner for me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90157

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


[PATCH] D90042: [clang-tidy] performance-unnecessary-copy-initialization: Check for const reference arguments that are replaced template parameter type.

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D90042#2350035 , @flx wrote:

> I should note that I was only able to reproduce the false positive with the 
> actual implementation std::function and not our fake version here.

Any reason not to lift enough of the actual definition to be able to reproduce 
the issue in your test cases? Does the change in definitions break other tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90042

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


[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

2020-10-27 Thread Tom Rix via Phabricator via cfe-commits
trixirt updated this revision to Diff 300965.
trixirt added a comment.

precheckin lint fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90180

Files:
  clang-tools-extra/clang-tidy/linuxkernel/CMakeLists.txt
  clang-tools-extra/clang-tidy/linuxkernel/LinuxKernelTidyModule.cpp
  clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.cpp
  clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.h
  clang-tools-extra/test/clang-tidy/checkers/linuxkernel-switch-semi.c

Index: clang-tools-extra/test/clang-tidy/checkers/linuxkernel-switch-semi.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/linuxkernel-switch-semi.c
@@ -0,0 +1,37 @@
+// RUN: %check_clang_tidy %s linuxkernel-switch-semi %t
+
+int f(int a) {
+  switch (a) {
+  case 1:
+return 0;
+  default:
+break;
+  };
+  // CHECK-MESSAGES: warning: unneeded semicolon
+  // CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+  return 0;
+}
+
+// A normal switch, should not produce a warning
+int p1(int a) {
+  switch (a) {
+  case 1:
+return 0;
+  default:
+break;
+  }
+  return 0;
+}
+
+#define EMPTY_MACRO()
+// A corner case, do not fix an empty macro
+int p2(int a) {
+  switch (a) {
+  case 1:
+return 0;
+  default:
+break;
+  }
+  EMPTY_MACRO();
+  return 0;
+}
Index: clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.h
@@ -0,0 +1,30 @@
+//===--- SwitchSemiCheck.h - clang-tidy*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LINUXKERNEL_SWITCHSEMICHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LINUXKERNEL_SWITCHSEMICHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace linuxkernel {
+
+class SwitchSemiCheck : public ClangTidyCheck {
+public:
+  SwitchSemiCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace linuxkernel
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_LINUXKERNEL_SWITCHSEMICHECK_H
Index: clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.cpp
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/linuxkernel/SwitchSemiCheck.cpp
@@ -0,0 +1,76 @@
+//===--- SwitchSemiCheck.cpp - clang-tidy--===//
+//
+// 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 "SwitchSemiCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace linuxkernel {
+
+void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) {
+  // From the reproducer
+  // void foo (int a) {
+  //   switch (a) {};
+  // }
+  // The AST
+  // `-FunctionDecl
+  //   |-ParmVarDecl
+  //   `-CompoundStmt <--- "comp", 'C'
+  //|-SwitchStmt <-- "switch", 'S'
+  //| |-ImplicitCastExpr
+  //| | `-DeclRefExpr
+  //| `-CompoundStmt
+  //`-NullStmt <-- 'N'
+  Finder->addMatcher(
+  compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this);
+}
+
+void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) {
+  auto *C = Result.Nodes.getNodeAs("comp");
+  auto *S = Result.Nodes.getNodeAs("switch");
+
+  auto Current = C->body_begin();
+  auto Next = Current;
+  Next++;
+  while (Next != C->body_end()) {
+if (*Current == S) {
+  if (const auto *N = dyn_cast(*Next)) {
+// This code has the same AST as the reproducer
+//
+// #define EMPTY()
+// void foo (int a) {
+// switch (a) {} EMPTY();
+// }
+//
+// But we do not want to remove the ; because the
+// macro may only be conditionally empty.
+// ex/ the release version of a debug macro
+//
+// So check that the NullStmt does not have a
+// leading empty macro.
+if (!N->hasLeadingEmptyMacro() && S->getBody()->getEndLoc().isValid() &&
+N->getSemiLoc().isValid()) {

[PATCH] D83088: Introduce CfgTraits abstraction

2020-10-27 Thread Renato Golin via Phabricator via cfe-commits
rengolin added a comment.

I have read all of the comments in this review and have looked at all the other 
pending reviews because of this and I still see strong disagreement on the 
design and implementation.

Unfortunately, I can't contribute with the technical discussion because there's 
a lot more context and content here than I can absorb in the time I have 
available, but overall I think David's critics are very pertinent. They don't 
mean the code is wrong or bad, just that they are important questions that need 
answers. Some of the questions were answered, others weren't. This patch should 
not have been committed before those things were sorted out, as is clearly 
stated in the (existing) review policy 
(https://llvm.org/docs/CodeReview.html#acknowledge-all-reviewer-feedback).

I do appreciate that the other patches are "waiting" for this one and that it 
has been months, but this patch fundamentally changes the algorithm with a 
motivation that still isn't clear for two reasons:

1. It was initially stated that the motivation is to reduce the number of 
templates because the author doesn't like them, which is not a good reason.
2. Despite recurrent requests to show concrete code examples comparing current 
and new design, showing why it would be "easier to use", none have materialised 
(other than David's own attempts).

All of the other patches were approved by the same set of people. This is 
definitely not uncommon, but is highly susceptible to unconscious bias. Once 
David questioned the approach with concrete questions, concrete answers should 
address all of the points.

This patch should have never been committed in the first place, even with one 
approval.

In D83088#2342760 , @dblaikie wrote:

> Sorry about the delays in review - but please revert this patch until we can 
> hash out a few more details. I really don't think this is the best direction 
> forward for a core abstraction & I'll do my best to explain why & try to 
> understand where you're coming from.

The (current) review policy 
(https://llvm.org/docs/CodeReview.html#can-code-be-reviewed-after-it-is-committed)
 is already clear enough:

"There is a strong expectation that authors respond promptly to post-commit 
feedback and address it. Failure to do so is cause for the patch to be 
reverted."

It's pretty clear that the paragraph applies to David's post-commit review.

> I'd really like to see examples like this ^ using the different abstractions 
> under consideration here (classic GraphTraits, CfgTraits dynamic and static 
> typed, perhaps what a static API would look like if it wasn't trying to be 
> dynamic API compatible).

This is the main request that was left unaddressed and the one that has the 
highest impact on the design of the API as well as all the following patches. 
The fact that they have all been approved doesn't mean this one must, too.

Their own approval just means those changes look good with the current 
interpretation, not that they must land. It's entirely possible that they 
continue to be good after the API has changed (if it has), in which case the 
approvals can just be restated. But they may well disappear or change 
completely due to the change in API, and will need new reviews to avoid having 
an already approved review change substantially in content.

> Indeed template code can get a bit weird - but I'm not sure it's quite enough 
> to justify the change in/complications of mulitple (static and dynamic) 
> abstractions here just yet. It might be that taking a more structured C++ 
> idiomatic approach to template design (like C++ standard container concept 
> abstractions) might lead to more usable code without /some/ complexities 
> (though may trade others).

And this is the main critic to the overall design choice, which I also agree 
completely. I'm not a big fan of complex template code myself, but the idioms 
are well known and they do simplify usage in many cases.

LLVM has had its fair share of discussions on the topics and we have developed 
multiple APIs and containers tho overcome deficiencies in the standard library, 
some of those concepts made into the standard. Some of those I have learned to 
like when I tried to implement otherwise and failed.

Only with concrete comparison of usage and patterns that we can make an 
informed decision and this is required to change a core concept of the compiler 
more than any other place. A single example where your pattern fits isn't 
enough to demonstrate that it will be generic and usable for all the other 
patterns that it may be used.

I'm sorry this delays more your work, but this is what working on an open 
source very large project entails. In comparison, LLVM is very fast compared to 
other OSS projects out there.

Also, echoing other people in this thread, this is more a case for an RFC 
thread on the list than code review. If the original thread didn't catch the 
attention of a public wi

[clang] e562a40 - Fix for PR47544. Clang is crashing after generating the right

2020-10-27 Thread Zahira Ammarguellat via cfe-commits

Author: Zahira Ammarguellat
Date: 2020-10-27T05:57:39-07:00
New Revision: e562a40871da14cef6685efef09760bca2718269

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

LOG: Fix for PR47544. Clang is crashing after generating the right
diagnostic for a re-declaration of a friend method.d
https://reviews.llvm.org/D88112

Added: 
clang/test/SemaCXX/invalid-decl.cpp

Modified: 
clang/lib/Parse/ParseCXXInlineMethods.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseCXXInlineMethods.cpp 
b/clang/lib/Parse/ParseCXXInlineMethods.cpp
index d05332b5ac5a..12941f214cbc 100644
--- a/clang/lib/Parse/ParseCXXInlineMethods.cpp
+++ b/clang/lib/Parse/ParseCXXInlineMethods.cpp
@@ -405,14 +405,21 @@ void 
Parser::ParseLexedMethodDeclaration(LateParsedMethodDeclaration &LM) {
 ConsumeAnyToken();
 } else if (HasUnparsed) {
   assert(Param->hasInheritedDefaultArg());
-  FunctionDecl *Old = cast(LM.Method)->getPreviousDecl();
-  ParmVarDecl *OldParam = Old->getParamDecl(I);
-  assert (!OldParam->hasUnparsedDefaultArg());
-  if (OldParam->hasUninstantiatedDefaultArg())
-Param->setUninstantiatedDefaultArg(
-OldParam->getUninstantiatedDefaultArg());
+  const FunctionDecl *Old;
+  if (const auto *FunTmpl = dyn_cast(LM.Method))
+Old =
+cast(FunTmpl->getTemplatedDecl())->getPreviousDecl();
   else
-Param->setDefaultArg(OldParam->getInit());
+Old = cast(LM.Method)->getPreviousDecl();
+  if (Old) {
+ParmVarDecl *OldParam = const_cast(Old->getParamDecl(I));
+assert(!OldParam->hasUnparsedDefaultArg());
+if (OldParam->hasUninstantiatedDefaultArg())
+  Param->setUninstantiatedDefaultArg(
+  OldParam->getUninstantiatedDefaultArg());
+else
+  Param->setDefaultArg(OldParam->getInit());
+  }
 }
   }
 

diff  --git a/clang/test/SemaCXX/invalid-decl.cpp 
b/clang/test/SemaCXX/invalid-decl.cpp
new file mode 100644
index ..0cb8b00a8d12
--- /dev/null
+++ b/clang/test/SemaCXX/invalid-decl.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+class test1 {
+  template  friend int bar(bool = true) {} // expected-note 
{{previous declaration is here}}
+  template  friend int bar(bool);  // expected-error 
{{friend declaration specifying a default argument must be the only 
declaration}}
+};
+
+class test2 {
+  friend int bar(bool = true) {} // expected-note {{previous declaration is 
here}}
+  friend int bar(bool);  // expected-error{{friend declaration 
specifying a default argument must be the only declaration}}
+};



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


[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

2020-10-27 Thread Tom Rix via Phabricator via cfe-commits
trixirt added a comment.

The 10,000 problems are for all the extra semicolon problems.
Those after switch are a small subset, chosen because is ok to automagically 
fix them.

The checker is in the linuxkernel/  because it is being used to fix the linux 
kernel now.
And to enforce it stays fixed.

Enforcement here is necessary because the linux kernel's enforcer checkpatch is
a line checker, not an ast checker.

If folks think this is a general fixer, I do not mind moving it to some other 
checker dir.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90180

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


[PATCH] D89986: [AIX] do not emit visibility attribute into IR when there is -mignore-xcoff-visibility

2020-10-27 Thread Digger via Phabricator via cfe-commits
DiggerLin marked 9 inline comments as done.
DiggerLin added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:520
   Options.DataSections = CodeGenOpts.DataSections;
-  Options.IgnoreXCOFFVisibility = CodeGenOpts.IgnoreXCOFFVisibility;
   Options.UniqueSectionNames = CodeGenOpts.UniqueSectionNames;

sfertile wrote:
> DiggerLin wrote:
> > jasonliu wrote:
> > > DiggerLin wrote:
> > > > DiggerLin wrote:
> > > > > jasonliu wrote:
> > > > > > DiggerLin wrote:
> > > > > > > jasonliu wrote:
> > > > > > > > DiggerLin wrote:
> > > > > > > > > jasonliu wrote:
> > > > > > > > > > Instead of just removing this line, should this get 
> > > > > > > > > > replaced with the new LangOpts option?
> > > > > > > > > I do not think we need a CodeGenOp of ignore-xcoff-visibility 
> > > > > > > > > in clang, we only need the LangOpt of the 
> > > > > > > > > ignore-xcoff-visilbity to control whether we will  generate 
> > > > > > > > > the visibility in the IR,  when the LangOpt of 
> > > > > > > > > ignore-xcoff-visibility do not generate the visibility 
> > > > > > > > > attribute of GV in the IR. it do not need CodeGenOp of 
> > > > > > > > > ignore-xcoff-visibility any more for the clang .
> > > > > > > > > 
> > > > > > > > > we have still CodeGen ignore-xcoff-visibility op in  llc.
> > > > > > > > We removed the visibility from IR level with this patch. But 
> > > > > > > > there is also visibility settings coming from CodeGen part of 
> > > > > > > > clang, which needs to get ignore when we are doing the code gen 
> > > > > > > > in llc. So I think you still need to set the options correct 
> > > > > > > > for llc.
> > > > > > > yes we have the set the options correct for llc in the code.
> > > > > > > 
> > > > > > > in the source file llvm/lib/CodeGen/CommandFlags.cpp, we have (in 
> > > > > > > the patch https://reviews.llvm.org/D87451 add new option 
> > > > > > > -mignore-xcoff-visibility) , the function
> > > > > > > TargetOptions codegen::InitTargetOptionsFromCodeGenFlags() {
> > > > > > > 
> > > > > > > Options.IgnoreXCOFFVisibility = getIgnoreXCOFFVisibility(); 
> > > > > > > ...}
> > > > > > > 
> > > > > > What I'm saying is... 
> > > > > > I think we need a line like this:
> > > > > > `Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;`
> > > > > > so that when you invoke clang, backend would get the correct 
> > > > > > setting as well. 
> > > > > I do not think so, from the clang FE, we do not generated the 
> > > > > visibility in the IR. so there is no need these line.
> > > > or we can say that because we do not set the hidden visibility into the 
> > > > GlobalValue , so we do not need the 
> > > > Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;
> > > I think I mentioned this before, we could have extra visibility settings 
> > > in clang/lib/CodeGen that's not depending on the existing visibility 
> > > setting in the IR. (You could search for `setVisibility` there.) That was 
> > > the reason we did it in llc first. 
> > I will add Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;  
> > here.
> > I think I mentioned this before, we could have extra visibility settings in 
> > clang/lib/CodeGen that's not depending on the existing visibility setting 
> > in the IR. (You could search for setVisibility there.) That was the reason 
> > we did it in llc first.
> 
>  A lot of these are in places we wouldn't encounter with AIX, like for 
> Objective-C code gen. But are others like [[ 
> https://github.com/llvm/llvm-project/blob/b03ea054db1bcf9452b3a70e21d3372b6e58759a/clang/lib/CodeGen/ItaniumCXXABI.cpp#L2507
>  | this]]  an issue? Should they be addressed in this patch?
after I added the Options.IgnoreXCOFFVisibility = 
LangOpts.IgnoreXCOFFVisibility , even there is  
GV->setVisibility(llvm::GlobalValue::HiddenVisibility);  it do not effect our 
output.

there is following code in the function void 
PPCAIXAsmPrinter::emitLinkage(const GlobalValue *GV,
   MCSymbol *GVSym) const
{
 . 
  if (!TM.getIgnoreXCOFFVisibility()) {
switch (GV->getVisibility()) {

// TODO: "exported" and "internal" Visibility needs to go here.
case GlobalValue::DefaultVisibility:
  break;
case GlobalValue::HiddenVisibility:
  VisibilityAttr = MAI->getHiddenVisibilityAttr();
  break;
case GlobalValue::ProtectedVisibility:
  VisibilityAttr = MAI->getProtectedVisibilityAttr();
  break;
}
  }

...
}



Comment at: clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp:1
 // REQUIRES: powerpc-registered-target
 

sfertile wrote:
> You shouldn't need this requires anymore.
please  see the 
https://reviews.llvm.org/rGa15bd0bfc20c2b2955c59450a67b6e8efe89c708



Comment at: clang/test/CodeGen/aix-visibility-inlines-hidden.cpp:1
+// REQUIRES: powerpc-registered-target
+

jasonliu wrote:
> sfertile wrote:
> > Shouldn't

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

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:482
   Styles.emplace_back(IdentifierNamingCheck::NamingStyle{
-  std::move(CaseOptional), std::move(Prefix), std::move(Postfix)});
-else
+  std::move(CaseOptional), std::move(Prefix), std::move(Postfix),
+  std::move(HPOpt), HNOption});

Drive-by note that's not something you need to address: these calls to 
`std::move()` for prefix and postfix are rather suspect given that the 
parameters in the constructor are both `const std::string&`.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:483
+  std::move(CaseOptional), std::move(Prefix), std::move(Postfix),
+  std::move(HPOpt), HNOption});
+} else {

Would it make sense to declare `HNOption` as a typical local variable (no need 
for the `clearAll()` API since you can default construct properly), and pass an 
rvalue reference rather than an lvalue reference (so call std::move()) here, as 
with the other arguments)?



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:549
+  for (const auto &CStr : HNOption.CString) {
+auto Key = CStr.getKey().str();
+if (ModifiedTypeName.find(Key) == 0) {

You shouldn't use `auto` when the type isn't spelled out in the initialization. 
(Same below)



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:631
+
+  if (CRD->isUnion()) {
 return "";

Elide braces around single-line if statements, per our usual coding guidelines.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:635-636
 
-  if (clang::Decl::Kind::EnumConstant == Decl->getKind() ||
-  clang::Decl::Kind::CXXMethod == Decl->getKind()||
-  clang::Decl::Kind::Function == Decl->getKind()) {
+  if (CRD->isStruct()) {
+if (!isHungarianNotationOptionEnabled("TreatStructAsClass",
+  HNOption.General)) {

Combine into a single `if`?



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:644
+  bool IsAbstractClass = false;
+  for (const auto *Method : CRD->methods()) {
+if (Method->isPure()) {

No need to do this manually, you can use `CXXRecordData::isAbstract()` since 
it's already computed.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:651-658
+  std::string Prefix;
+  if (IsAbstractClass) {
+  Prefix = "I";
+  } else {
+  Prefix = "C";
+  }
+

`return CRD->isAbstract() ? "I" : "C";`



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:662-666
+  std::string Name = ECD->getType().getAsString();
+  if (std::string::npos != Name.find("enum")) {
+Name = Name.substr(strlen("enum"), Name.length() - strlen("enum"));
+Name = Name.erase(0, Name.find_first_not_of(" "));
+  }

This is a bit worrying -- can you not look at the `DeclContext` for the 
`EnumConstantDecl` to find the parent `EnumDecl` and ask for its name directly?



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:703
+
+static std::string getDeclTypeName(const clang::NamedDecl *ND) {
+  const auto VD = dyn_cast(ND);

You can drop the `clang::` bit.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:704
+static std::string getDeclTypeName(const clang::NamedDecl *ND) {
+  const auto VD = dyn_cast(ND);
+  if (!VD) {

When using type deduction, the coding style is to put all pointers and 
qualifiers on the declaration as well (so we don't have to infer them from 
context), so this should be `const auto *`.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:806
+static std::string getHungarianNotationPrefix(
+const clang::Decl *D,
+IdentifierNamingCheck::HungarianNotationOption &HNOption) {

Can drop the `clang::` bit.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:808-809
+IdentifierNamingCheck::HungarianNotationOption &HNOption) {
+  const auto ND = dyn_cast(D);
+  if (!ND) {
+return "";

`const auto *` and elide braces (I'll stop pointing these out, can you do a 
pass over the whole check?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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


[PATCH] D90157: [analyzer] Rework SValBuilder::evalCast function into maintainable and clear way

2020-10-27 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

In D90157#2356170 , @martong wrote:

>> Now I'm going to make unittests for SValBuilder::evalCast. Let me ask you to 
>> offer me some examples of casts to check. As many cases we can collect as 
>> robust the test would be. E.g.
>
> This is not going to be easy. I guess we should cover both implicit and 
> explicit type conversions. C++ is ridiculously complex in these domains. For 
> maximal precision I'd suggest to systematically go through the below pages 
> and try to cover each major case:
> https://en.cppreference.com/w/cpp/language/explicit_cast
> https://en.cppreference.com/w/cpp/language/implicit_conversion

@martong  Keep in mind that we try hard not to emit casts - even if that would 
require. Check D85528 , exactly touching this 
topic.

---

By the same token, I think you should run the test-suite using the Z3 
refutation and/or Z3 constraint solver to check if this introduces any 
regression.
You can do that by installing Z3, adding the cmake options: 
`-DLLVM_ENABLE_Z3_SOLVER=ON`, `-DLLVM_Z3_INSTALL_DIR=/path/to/z3`
After this, you should be able to run the lit-test:
`./bin/llvm-lit -sv --show-unsupported --show-xfail 
/home/elnbbea/git/llvm-project/clang/test/Analysis --param USE_Z3_SOLVER=1`
Run it before and after your fix and you should expect no //new// 
failures/crashes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90157

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


[PATCH] D89986: [AIX] do not emit visibility attribute into IR when there is -mignore-xcoff-visibility

2020-10-27 Thread Digger via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 300972.
DiggerLin marked 3 inline comments as done.
DiggerLin added a comment.

address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89986

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/lib/AST/Decl.cpp
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
  clang/test/CodeGen/aix-visibility-inlines-hidden.cpp

Index: clang/test/CodeGen/aix-visibility-inlines-hidden.cpp
===
--- /dev/null
+++ clang/test/CodeGen/aix-visibility-inlines-hidden.cpp
@@ -0,0 +1,39 @@
+// REQUIRES: powerpc-registered-target
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -fvisibility-inlines-hidden \
+   -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -fvisibility-inlines-hidden \
+// RUN:-fvisibility default -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -mignore-xcoff-visibility -emit-llvm \
+// RUN:-fvisibility-inlines-hidden -fvisibility default -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+int x = 66;
+__attribute__((__noinline__)) inline void f() {
+  x = 55;
+}
+
+#pragma GCC visibility push(hidden)
+__attribute__((__noinline__)) inline void foo() {
+  x = 55;
+}
+#pragma GCC visibility pop
+
+int bar() {
+  f();
+  foo();
+  return x;
+}
+
+// VISIBILITY-IR: define linkonce_odr hidden void @_Z1fv()
+// NOVISIBILITY-IR:   define linkonce_odr void @_Z1fv()
+
+// VISIBILITY-IR: define linkonce_odr hidden void @_Z3foov()
+// NOVISIBILITY-IR:   define linkonce_odr void @_Z3foov()
Index: clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
===
--- clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
+++ clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
@@ -1,24 +1,10 @@
 // REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -o - -x c++ -S  %s  |\
-// RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
 
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-ASM %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
 
 // RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -emit-llvm -o - -x c++ %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-IR %s
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
 
 // RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -emit-llvm -o - -x c++ %s  | \
 // RUN: FileCheck -check-prefix=VISIBILITY-IR %s
@@ -70,28 +56,11 @@
 // VISIBILITY-IR:define weak_odr protected i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
 // VISIBILITY-IR:define hidden void @_Z7prambarv()
 
-// VISIBILITY-ASM: .globl  _Z5foo_hPi[DS],hidden
-// VISIBILITY-ASM: .globl  ._Z5foo_hPi,hidden
-// VISIBILITY-ASM: .globl  _Z3barv[DS],protected
-// VISIBILITY-ASM: .globl  ._Z3barv,protected
-// VISIBILITY-ASM: .weak   _ZNK9TestClass5valueEv[DS],hidden
-// VISIBILITY-ASM: .weak   ._ZNK9TestClass5valueEv,hidden
-// VISIBILITY-ASM: .weak   _ZN5basicIiE7getdataEv[DS],protected
-// VISIBILITY-ASM: .weak   ._ZN5basicIiE7getdataEv,protected
-// VISIBILITY-ASM: .globl  _Z7prambarv[DS],hidden
-// VISIBILITY-ASM: .globl  ._Z7prambarv,hidden
-// VISIBILITY-ASM: .globl  b,protected
-// VISIBILITY-ASM: .globl  pramb,hidden
-
-// IGNOREVISIBILITY-ASM: .globl  _Z5foo_hPi[DS]
-// IGNOREVISIBILITY-ASM: .globl  ._Z5foo_hPi
-// IGNOREVISIBILITY-ASM: .globl  _Z3barv[DS]
-// IGNOREVISIBILITY-ASM: .globl  ._Z3barv
-// IGNOREVISIBILITY-ASM: .weak   _ZNK9TestClass5valueEv[DS]
-// IGNOREVISIBILITY-ASM: .weak   ._ZNK9TestClass5valueE

[clang] b19473c - [clang] RewriteObjCClassMetaData - remove superfluous null pointer check. NFCI.

2020-10-27 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2020-10-27T13:14:55Z
New Revision: b19473cf590eca13d23a20191c820d0f9d835beb

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

LOG: [clang] RewriteObjCClassMetaData - remove superfluous null pointer check. 
NFCI.

We've already dereferenced the pointer and no other getClassInterface() calls 
appear to bother with such a check.

Reported as "Snippet 6" in https://www.viva64.com/en/b/0771/

Added: 


Modified: 
clang/lib/Frontend/Rewrite/RewriteObjC.cpp

Removed: 




diff  --git a/clang/lib/Frontend/Rewrite/RewriteObjC.cpp 
b/clang/lib/Frontend/Rewrite/RewriteObjC.cpp
index 3caf9a672062..543b3b09a9cc 100644
--- a/clang/lib/Frontend/Rewrite/RewriteObjC.cpp
+++ b/clang/lib/Frontend/Rewrite/RewriteObjC.cpp
@@ -5285,9 +5285,8 @@ void 
RewriteObjCFragileABI::RewriteObjCClassMetaData(ObjCImplementationDecl *IDe
   }
 
   // Build _objc_ivar_list metadata for classes ivars if needed
-  unsigned NumIvars = !IDecl->ivar_empty()
-  ? IDecl->ivar_size()
-  : (CDecl ? CDecl->ivar_size() : 0);
+  unsigned NumIvars =
+  !IDecl->ivar_empty() ? IDecl->ivar_size() : CDecl->ivar_size();
   if (NumIvars > 0) {
 static bool objc_ivar = false;
 if (!objc_ivar) {



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


[clang] 2bc2e2e - [MallocChecker] Remove duplicate QCoreApplication::postEvent check. NFCI.

2020-10-27 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2020-10-27T13:14:54Z
New Revision: 2bc2e2e9fe25c5568cfb8681e441fcc6a194daa4

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

LOG: [MallocChecker] Remove duplicate QCoreApplication::postEvent check. NFCI.

This appears to have been in the original patch in D14170.

Reported as "Snippet 11" in https://www.viva64.com/en/b/0771/

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
index fc6d15371a2f..f117d5505ecb 100644
--- a/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -3110,11 +3110,6 @@ bool 
MallocChecker::mayFreeAnyEscapedMemoryOrIsModeledExplicitly(
 return true;
   }
 
-  if (FName == "postEvent" &&
-  FD->getQualifiedNameAsString() == "QCoreApplication::postEvent") {
-return true;
-  }
-
   if (FName == "connectImpl" &&
   FD->getQualifiedNameAsString() == "QObject::connectImpl") {
 return true;



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


[PATCH] D90042: [clang-tidy] performance-unnecessary-copy-initialization: Check for const reference arguments that are replaced template parameter type.

2020-10-27 Thread Felix Berger via Phabricator via cfe-commits
flx added a comment.

In D90042#2356180 , @aaron.ballman 
wrote:

> In D90042#2350035 , @flx wrote:
>
>> I should note that I was only able to reproduce the false positive with the 
>> actual implementation std::function and not our fake version here.
>
> Any reason not to lift enough of the actual definition to be able to 
> reproduce the issue in your test cases? Does the change in definitions break 
> other tests?

I poured over the actual definition and couldn't find any difference wrt the 
call operator that would explain it. I would also think that:

  template 
  void foo(T&& t) {
std::forward(t).modify();
  }

would be a simpler case that should trigger replacement, but it doesn't. Do you 
have any idea what I could be missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90042

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


[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

2020-10-27 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 300975.
jansvoboda11 added a comment.

Formalize the "implied by" relationship with `DefaultAnyOf<[...]>`.


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

https://reviews.llvm.org/D82756

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -435,7 +435,12 @@
   OS << "nullptr";
   };
 
-  std::vector> OptsWithMarshalling;
+  auto IsMarshallingOption = [](const Record &R) {
+return !isa(R.getValueInit("MarshallingKind")) &&
+   !R.getValueAsString("KeyPath").empty();
+  };
+
+  std::vector OptsWithMarshalling;
   for (unsigned I = 0, E = Opts.size(); I != E; ++I) {
 const Record &R = *Opts[I];
 
@@ -443,12 +448,31 @@
 OS << "OPTION(";
 WriteOptRecordFields(OS, R);
 OS << ")\n";
-if (!isa(R.getValueInit("MarshallingKind")))
-  OptsWithMarshalling.push_back(MarshallingKindInfo::create(R));
+if (IsMarshallingOption(R))
+  OptsWithMarshalling.push_back(&R);
   }
   OS << "#endif // OPTION\n";
 
-  for (const auto &KindInfo : OptsWithMarshalling) {
+  auto CmpMarshallingOpts = [](const Record *const *A, const Record *const *B) {
+unsigned AID = (*A)->getID();
+unsigned BID = (*B)->getID();
+
+if (AID < BID)
+  return -1;
+if (AID > BID)
+  return 1;
+return 0;
+  };
+
+  // Restore the definition order of marshalling options.
+  array_pod_sort(OptsWithMarshalling.begin(), OptsWithMarshalling.end(),
+ CmpMarshallingOpts);
+
+  std::vector> MarshallingKindInfos;
+  for (const auto *R : OptsWithMarshalling)
+MarshallingKindInfos.push_back(MarshallingKindInfo::create(*R));
+
+  for (const auto &KindInfo : MarshallingKindInfos) {
 OS << "#ifdef " << KindInfo->MacroName << "\n";
 OS << KindInfo->MacroName << "(";
 WriteOptRecordFields(OS, KindInfo->R);
@@ -463,7 +487,7 @@
   OS << "\n";
   OS << MarshallingStringInfo::ValueTablePreamble;
   std::vector ValueTableNames;
-  for (const auto &KindInfo : OptsWithMarshalling)
+  for (const auto &KindInfo : MarshallingKindInfos)
 if (auto MaybeValueTableName = KindInfo->emitValueTable(OS))
   ValueTableNames.push_back(*MaybeValueTableName);
 
Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -144,18 +144,24 @@
 
 // Helpers for defining marshalling information.
 
+class DefaultAnyOf defaults> {
+  code DefaultValue = !foldl("false", defaults, accumulator, option,
+ !strconcat(accumulator, " || ", !cast(option.KeyPath)));
+}
+
 class MarshallingInfo {
   code KeyPath = keypath;
   code DefaultValue = defaultvalue;
 }
+
 class MarshallingInfoString
   : MarshallingInfo {
   string MarshallingKind = "string";
   code NormalizerRetTy = normalizerretty;
 }
 
-class MarshallingInfoFlag
-  : MarshallingInfo {
+class MarshallingInfoFlag>
+  : MarshallingInfo {
   string MarshallingKind = "flag";
 }
 
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -115,4 +115,19 @@
   ASSERT_THAT(GeneratedArgs, Each(StrNe(RelocationModelCStr)));
 }
 
+TEST_F(CC1CommandLineGenerationTest, CanGenerateCC1CommandLineImpliedFlags) {
+  const char *Args[] = {"clang", "-xc++", "-cl-unsafe-math-optimizations",
+"-cl-mad-enable", "-menable-unsafe-fp-math"};
+
+  CompilerInvocation CInvok;
+  CompilerInvocation::CreateFromArgs(CInvok, Args, *Diags);
+
+  CInvok.generateCC1CommandLine(GeneratedArgs, *this);
+
+  // Explicitly provided flags that can also be implied are not be emitted.
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+}
+
 } // anonymous namespace
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -941,15 +941,8 @@
   Opts.NoEscapingBlockTailCalls =
   Args.hasArg(OPT_fno_escaping_block_tail_calls);
   Opts.FloatABI = std::string(Args.getLastArgValue(OPT_mfloat_abi));
-  Opts.LessPreciseFPMAD = Args.hasArg(OPT_cl_mad_enable) ||
-  Args.hasArg(OP

[PATCH] D88566: be more specific when testing for no fuse-ld warnings

2020-10-27 Thread Ties Stuij via Phabricator via cfe-commits
stuij abandoned this revision.
stuij added a comment.

Abandoned because lack of reaction for such an unimportant issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88566

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


[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

2020-10-27 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a subscriber: Anastasia.
jansvoboda11 added a comment.

Using the records with `DefaultAnyOf<[...]>` to catch errors seems to work 
well, thanks for the suggestion.

(I was initially thinking about using the keypaths to avoid errors and reorder 
the options in the TableGen backend to make everything work.)

@dexonsmith WDYT about the implementation?

@Anastasia There is no need to manually expand `-cc1` options anymore. Do you 
have any other concerns?


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

https://reviews.llvm.org/D82756

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


[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

2020-10-27 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 300979.
jansvoboda11 added a comment.

Fix typo & whitespace.


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

https://reviews.llvm.org/D82756

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -435,7 +435,12 @@
   OS << "nullptr";
   };
 
-  std::vector> OptsWithMarshalling;
+  auto IsMarshallingOption = [](const Record &R) {
+return !isa(R.getValueInit("MarshallingKind")) &&
+   !R.getValueAsString("KeyPath").empty();
+  };
+
+  std::vector OptsWithMarshalling;
   for (unsigned I = 0, E = Opts.size(); I != E; ++I) {
 const Record &R = *Opts[I];
 
@@ -443,12 +448,31 @@
 OS << "OPTION(";
 WriteOptRecordFields(OS, R);
 OS << ")\n";
-if (!isa(R.getValueInit("MarshallingKind")))
-  OptsWithMarshalling.push_back(MarshallingKindInfo::create(R));
+if (IsMarshallingOption(R))
+  OptsWithMarshalling.push_back(&R);
   }
   OS << "#endif // OPTION\n";
 
-  for (const auto &KindInfo : OptsWithMarshalling) {
+  auto CmpMarshallingOpts = [](const Record *const *A, const Record *const *B) {
+unsigned AID = (*A)->getID();
+unsigned BID = (*B)->getID();
+
+if (AID < BID)
+  return -1;
+if (AID > BID)
+  return 1;
+return 0;
+  };
+
+  // Restore the definition order of marshalling options.
+  array_pod_sort(OptsWithMarshalling.begin(), OptsWithMarshalling.end(),
+ CmpMarshallingOpts);
+
+  std::vector> MarshallingKindInfos;
+  for (const auto *R : OptsWithMarshalling)
+MarshallingKindInfos.push_back(MarshallingKindInfo::create(*R));
+
+  for (const auto &KindInfo : MarshallingKindInfos) {
 OS << "#ifdef " << KindInfo->MacroName << "\n";
 OS << KindInfo->MacroName << "(";
 WriteOptRecordFields(OS, KindInfo->R);
@@ -463,7 +487,7 @@
   OS << "\n";
   OS << MarshallingStringInfo::ValueTablePreamble;
   std::vector ValueTableNames;
-  for (const auto &KindInfo : OptsWithMarshalling)
+  for (const auto &KindInfo : MarshallingKindInfos)
 if (auto MaybeValueTableName = KindInfo->emitValueTable(OS))
   ValueTableNames.push_back(*MaybeValueTableName);
 
Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -144,18 +144,24 @@
 
 // Helpers for defining marshalling information.
 
+class DefaultAnyOf defaults> {
+  code DefaultValue = !foldl("false", defaults, accumulator, option,
+ !strconcat(accumulator, " || ", !cast(option.KeyPath)));
+}
+
 class MarshallingInfo {
   code KeyPath = keypath;
   code DefaultValue = defaultvalue;
 }
+
 class MarshallingInfoString
   : MarshallingInfo {
   string MarshallingKind = "string";
   code NormalizerRetTy = normalizerretty;
 }
 
-class MarshallingInfoFlag
-  : MarshallingInfo {
+class MarshallingInfoFlag>
+  : MarshallingInfo {
   string MarshallingKind = "flag";
 }
 
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -115,4 +115,20 @@
   ASSERT_THAT(GeneratedArgs, Each(StrNe(RelocationModelCStr)));
 }
 
+TEST_F(CC1CommandLineGenerationTest, CanGenerateCC1CommandLineImpliedFlags) {
+  const char *Args[] = {"clang", "-xc++", "-cl-unsafe-math-optimizations",
+"-cl-mad-enable", "-menable-unsafe-fp-math"};
+
+  CompilerInvocation CInvok;
+  CompilerInvocation::CreateFromArgs(CInvok, Args, *Diags);
+
+  CInvok.generateCC1CommandLine(GeneratedArgs, *this);
+
+  // Explicitly provided flags that were also implied by another flag, are not
+  // emitted.
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+}
+
 } // anonymous namespace
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -941,15 +941,8 @@
   Opts.NoEscapingBlockTailCalls =
   Args.hasArg(OPT_fno_escaping_block_tail_calls);
   Opts.FloatABI = std::string(Args.getLastArgValue(OPT_mfloat_abi));
-  Opts.LessPreciseFPMAD = Args.hasArg(OPT_cl_mad_enable) ||
-  Args.hasArg(OPT_cl_unsafe_math_optimizati

[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

2020-10-27 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

I think CLang should do this job, since it has two related warnings already.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90180

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


[PATCH] D90109: [clang-tidy] Use ANSI escape codes for --use-color on Windows

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D90109#2352180 , @dsanders11 wrote:

> Added a few inline comments for clarification.
>
> **Note**: I was not able to get a debug build and unit tests working on my 
> Windows set up, so this has only been tested manually. I'm not sure if the 
> unit test added in D79477  runs on Windows, 
> but  in theory it should be broken on Windows since it expects ANSI escape 
> codes in the output.

The functionality test specifies `REQUIRES: ansi-escape-sequences` so I'm 
guessing that test is not run on Windows. The unit test is parsing 
configuration options, not exercising the options themselves.

What issues did you run into regarding testing, because I feel like the patch 
should have test coverage (esp given that color vs ANSI escape codes are a bit 
of an oddity to reason about)?




Comment at: clang-tools-extra/clang-tidy/ClangTidy.cpp:113
 DiagPrinter->BeginSourceFile(LangOpts);
+#if defined(_WIN32)
+if (DiagOpts->ShowColors && !llvm::sys::Process::StandardOutIsDisplayed()) 
{

dsanders11 wrote:
> To prevent any unintended changes this has been confined to only Windows, but 
> the code should be safe to run on any platform. I believe it would be a no-op 
> on Unix, which always uses ANSI escape codes and UseANSIEscapeCodes is a 
> no-op.
I agree that the code should work on all supported platforms, I'd say you can 
remove the `#if`.



Comment at: llvm/lib/Support/Windows/Process.inc:330
 DWORD Mode;
-GetConsoleMode(Console, &Mode);
-Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
-SetConsoleMode(Console, Mode);
+if (GetConsoleMode(Console, &Mode) != 0) {
+  Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;

dsanders11 wrote:
> Fixes a crash when calling UseANSIEscapeCodes if standard out isn't a console.
If this fails, do we still want to set `UseANSI` to `enable` below? Similar if 
setting the mode fails?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90109

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


[PATCH] D90215: [CMake] Support inter-proto dependencies in generate_protos.

2020-10-27 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: llvm/cmake/modules/FindGRPC.cmake:118
+  # DEPENDS arg is a list of "Foo.proto".
+  foreach(ImportedProto IN LISTS PROTO_DEPENDS)
+# Foo.proto -> Foo.pb.h

kbobyrev wrote:
> On line 89 the argument is called `DEPENDS` (also in the comments) but here 
> it is called `PROTO_DEPENDS`, I think this is a typo?
the variables extracted from arguments have names derived from the argument 
labels (DEPENDS) by prepending a prefix (in this case PROTO, the third argument 
to cmake_parse_arguments). So DEPENDS is the arg, PROTO_DEPENDS is the 
extracted variable.

(I forgot to mention I did test this, checking that the ninja graph still shows 
a dependency from Service.pb.cc.o onto Index.pb.h)



Comment at: llvm/cmake/modules/FindGRPC.cmake:124
+  ABSOLUTE
+  BASE_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+# Compilation of each generated source depends on ${BINARY}/Foo.pb.h.

kbobyrev wrote:
> This relies on the protos being generated from the same directory which is 
> probably a very restrictive requirement. I don't see a better solution other 
> than specifying dirs/full paths to the files in arguments but that does not 
> seem nice, too. Maybe add a FIXME?
> This relies on the protos being generated from the same directory

Why? The intention was that the DEPENDS args can be relative paths (Foo.proto, 
dir/Bar.proto, ../Baz.proto) or absolute ones 
(${CMAKE_CURRENT_BINARY_DIR}/../SomeGenerated.proto).

Thus resolving the extension-substituted path against 
${CMAKE_CURRENT_BINARY_DIR}, rather than simply appending it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90215

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


[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D90180#2354931 , @njames93 wrote:

> Is this not already handled by `-Wextra-semi`. If it isn't I feel like it 
> should be handled there rather than in clang-tidy

Strong +1 -- this is already handled by `-Wextra-semi-stmt` and should not be 
duplicated in a clang-tidy check. In fact, there's already a fix-it produced by 
Clang for this: https://godbolt.org/z/xhbfc9


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90180

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


[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Hiral via Phabricator via cfe-commits
Hiralo updated this revision to Diff 300980.
Hiralo added a comment.

With updated patch now changes are only in ClangTidyMain.cpp.
Thanks to @DmitryPolukhin for valuable suggestion :)

Added '--config-file' option to specify custom config file.
ClangTidyMain.cpp reads ConfigFile into string and then assigned read data to 
'Config' i.e. makes like '--config' code flow internally.

Ref comments https://reviews.llvm.org/D89936#inline-839224

Thank you.
-Hiral


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

https://reviews.llvm.org/D89936

Files:
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -73,6 +73,14 @@
 )"),
cl::init(""), cl::cat(ClangTidyCategory));
 
+static cl::opt ConfigFile("config-file", cl::desc(R"(
+Specify full path of .clang-tidy or custom config file.
+For example, --config-file=/some/path/myTidyConfig
+Note: this option is mutually exclusive to --config and --checks options.
+)"),
+   cl::init(""),
+   cl::cat(ClangTidyCategory));
+
 static cl::opt WarningsAsErrors("warnings-as-errors", cl::desc(R"(
 Upgrades warnings to errors. Same format as
 '-checks'.
@@ -279,6 +287,7 @@
 
   ClangTidyOptions DefaultOptions;
   DefaultOptions.Checks = DefaultChecks;
+  DefaultOptions.ConfigFile = "";
   DefaultOptions.WarningsAsErrors = "";
   DefaultOptions.HeaderFilterRegex = HeaderFilter;
   DefaultOptions.SystemHeaders = SystemHeaders;
@@ -291,6 +300,8 @@
   ClangTidyOptions OverrideOptions;
   if (Checks.getNumOccurrences() > 0)
 OverrideOptions.Checks = Checks;
+  if (ConfigFile.getNumOccurrences() > 0)
+OverrideOptions.ConfigFile = ConfigFile;
   if (WarningsAsErrors.getNumOccurrences() > 0)
 OverrideOptions.WarningsAsErrors = WarningsAsErrors;
   if (HeaderFilter.getNumOccurrences() > 0)
@@ -302,6 +313,30 @@
   if (UseColor.getNumOccurrences() > 0)
 OverrideOptions.UseColor = UseColor;
 
+  if (!ConfigFile.empty()) {
+if (!Config.empty()) {
+  llvm::errs() << "Error: --config-file and --config are mutually "
+  "exclusive. Specify only one.\n";
+  return nullptr;
+}
+
+if (!Checks.empty()) {
+  llvm::errs() << "Error: --config-file and --checks are mutually "
+  "exclusive. Specify only one.\n";
+  return nullptr;
+}
+
+llvm::ErrorOr> Text =
+llvm::MemoryBuffer::getFile(ConfigFile.c_str());
+if (std::error_code EC = Text.getError()) {
+  llvm::errs() << "Can't read config-file '" << ConfigFile
+   << "': " << EC.message() << "\n";
+  return nullptr;
+}
+
+Config.assign((*Text)->getBuffer());
+  }
+
   if (!Config.empty()) {
 if (llvm::ErrorOr ParsedConfig =
 parseConfiguration(Config)) {


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -73,6 +73,14 @@
 )"),
cl::init(""), cl::cat(ClangTidyCategory));
 
+static cl::opt ConfigFile("config-file", cl::desc(R"(
+Specify full path of .clang-tidy or custom config file.
+For example, --config-file=/some/path/myTidyConfig
+Note: this option is mutually exclusive to --config and --checks options.
+)"),
+   cl::init(""),
+   cl::cat(ClangTidyCategory));
+
 static cl::opt WarningsAsErrors("warnings-as-errors", cl::desc(R"(
 Upgrades warnings to errors. Same format as
 '-checks'.
@@ -279,6 +287,7 @@
 
   ClangTidyOptions DefaultOptions;
   DefaultOptions.Checks = DefaultChecks;
+  DefaultOptions.ConfigFile = "";
   DefaultOptions.WarningsAsErrors = "";
   DefaultOptions.HeaderFilterRegex = HeaderFilter;
   DefaultOptions.SystemHeaders = SystemHeaders;
@@ -291,6 +300,8 @@
   ClangTidyOptions OverrideOptions;
   if (Checks.getNumOccurrences() > 0)
 OverrideOptions.Checks = Checks;
+  if (ConfigFile.getNumOccurrences() > 0)
+OverrideOptions.ConfigFile = ConfigFile;
   if (WarningsAsErrors.getNumOccurrences() > 0)
 OverrideOptions.WarningsAsErrors = WarningsAsErrors;
   if (HeaderFilter.getNumOccurrences() > 0)
@@ -302,6 +313,30 @@
   if (UseColor.getNumOccurrences() > 0)
 OverrideOptions.UseColor = UseColor;
 
+  if (!ConfigFile.empty()) {
+if (!Config.empty()) {
+  llvm::errs() << "Error: --config-file and --config are mutually "
+  "exclusive. Specify only one.\n";
+  return nullptr;
+}
+
+if (!Checks.empty()) {
+  llvm::errs() << "Error: --config-file and --checks are mutually "
+   

[PATCH] D88609: Use uint64_t for branch weights instead of uint32_t

2020-10-27 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a subscriber: thakis.
kiranchandramohan added a comment.

@thakis Can you revert the testcase fix in MLIR also which was necessary after 
this patch? https://reviews.llvm.org/rG0fc1aa22ee6ac337a5d51fa5666c9cd61da61b07


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88609

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


[clang] 75a1790 - Fix use-after-scope introduced in 850325348ae82cd5e26ea9edfd04219d0fbe7828

2020-10-27 Thread Alex Richardson via cfe-commits

Author: Alex Richardson
Date: 2020-10-27T14:26:23Z
New Revision: 75a1790f4bf052b0a615ed0270a7b4b1c4c88818

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

LOG: Fix use-after-scope introduced in 850325348ae82cd5e26ea9edfd04219d0fbe7828

Added: 


Modified: 
clang/unittests/Format/MacroExpanderTest.cpp
clang/unittests/Format/TestLexer.h
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/unittests/Format/MacroExpanderTest.cpp 
b/clang/unittests/Format/MacroExpanderTest.cpp
index 20e1dba0d49a0..b2cd5112b820f 100644
--- a/clang/unittests/Format/MacroExpanderTest.cpp
+++ b/clang/unittests/Format/MacroExpanderTest.cpp
@@ -11,6 +11,7 @@ namespace {
 
 class MacroExpanderTest : public ::testing::Test {
 public:
+  MacroExpanderTest() : Lex(Allocator, Buffers) {}
   std::unique_ptr
   create(const std::vector &MacroDefinitions) {
 return std::make_unique(MacroDefinitions,
@@ -64,7 +65,9 @@ class MacroExpanderTest : public ::testing::Test {
   << Context << " in " << text(Tokens) << " at " << File << ":" << 
Line;
 }
   }
-
+protected:
+  llvm::SpecificBumpPtrAllocator Allocator;
+  std::vector> Buffers;
   TestLexer Lex;
 };
 

diff  --git a/clang/unittests/Format/TestLexer.h 
b/clang/unittests/Format/TestLexer.h
index 2f2b754fcbbb7..0945e9e66c6fd 100644
--- a/clang/unittests/Format/TestLexer.h
+++ b/clang/unittests/Format/TestLexer.h
@@ -59,12 +59,15 @@ inline std::string text(llvm::ArrayRef 
Tokens) {
 
 class TestLexer : public UnwrappedLineConsumer {
 public:
-  TestLexer(FormatStyle Style = getLLVMStyle())
-  : Style(Style), SourceMgr("test.cpp", ""),
-IdentTable(getFormattingLangOpts(Style)) {}
+  TestLexer(llvm::SpecificBumpPtrAllocator &Allocator,
+std::vector> &Buffers,
+FormatStyle Style = getLLVMStyle())
+  : Allocator(Allocator), Buffers(Buffers), Style(Style),
+SourceMgr("test.cpp", ""), IdentTable(getFormattingLangOpts(Style)) {}
 
   TokenList lex(llvm::StringRef Code) {
-auto Result = getNewLexer(Code).lex();
+FormatTokenLexer Lex = getNewLexer(Code);
+ArrayRef Result = Lex.lex();
 return TokenList(Result.begin(), Result.end());
   }
 
@@ -77,6 +80,7 @@ class TestLexer : public UnwrappedLineConsumer {
 for (auto &Line : UnwrappedLines) {
   AnnotatedLine Annotated(Line);
   Annotator.annotate(Annotated);
+  Annotator.calculateFormattingInformation(Annotated);
 }
 UnwrappedLines.clear();
 return TokenList(Tokens.begin(), Tokens.end());
@@ -99,18 +103,16 @@ class TestLexer : public UnwrappedLineConsumer {
 llvm::MemoryBuffer::getMemBufferCopy(Code, ""));
 clang::FileID FID =
 SourceMgr.get().createFileID(Buffers.back()->getMemBufferRef());
-FormatTokenLexer Lex(SourceMgr.get(), FID, 0, Style, Encoding, Allocator,
- IdentTable);
 return FormatTokenLexer(SourceMgr.get(), FID, 0, Style, Encoding, 
Allocator,
 IdentTable);
   }
 
 public:
+  llvm::SpecificBumpPtrAllocator& Allocator;
+  std::vector>& Buffers;
   FormatStyle Style;
   encoding::Encoding Encoding = encoding::Encoding_UTF8;
-  std::vector> Buffers;
   clang::SourceManagerForFile SourceMgr;
-  llvm::SpecificBumpPtrAllocator Allocator;
   IdentifierTable IdentTable;
   SmallVector UnwrappedLines;
 };

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 12a985217d973..e87270d638652 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -20,8 +20,10 @@ class TokenAnnotatorTest : public ::testing::Test {
 protected:
   TokenList annotate(llvm::StringRef Code,
  const FormatStyle &Style = getLLVMStyle()) {
-return TestLexer(Style).annotate(Code);
+return TestLexer(Allocator, Buffers, Style).annotate(Code);
   }
+  llvm::SpecificBumpPtrAllocator Allocator;
+  std::vector> Buffers;
 };
 
 #define EXPECT_TOKEN_KIND(FormatTok, Kind) 
\



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


[PATCH] D54943: WIP [clang-tidy] implement const-transformation for cppcoreguidelines-const-correctness

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D54943#2352196 , @0x8000- wrote:

> Would it be possible to split this review further, into "checking" and 
> "fixing" portions? I understand that fix-it portion is more difficult, and 
> sometimes results in multiple 'const' keywords being added, but for the past 
> year we have used the check as part of regular CI runs to flag where it needs 
> to be added by the engineers and for our use case it works fine that way - so 
> I would prefer to have at least the "report" part as part of upstream 
> Clang12, even if the 'fixup' comes later, due to the complexity of covering 
> all corner cases.

I wouldn't have an issue with that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54943

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


[PATCH] D90232: Respond to review items and renew D14484 for merge possiblity

2020-10-27 Thread Andrew Somerville via Phabricator via cfe-commits
catskul created this revision.
catskul added a reviewer: clang-format.
catskul added a project: clang-format.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
catskul requested review of this revision.

I'm trying to get D14484  past the finish line 
so I've adopted it.

This revision:

- fixes the unit tests
- resolves cases where the colon is attached (where the original did not)
- removes non-sensical 'backward compatibility'


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90232

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -4667,8 +4667,51 @@
"  aaa(aaa),\n"
"  at() {}");
 
+  FormatStyle BestFit = getLLVMStyle();
+  BestFit.ConstructorInitializer = FormatStyle::CI_BestFit;
+  verifyFormat("SomeClass::Constructor()\n"
+   ": a(aa),\n"
+   "  a(aa),\n"
+   "  a(aa) {}",
+   BestFit);
+  verifyFormat("SomeClass::Constructor()\n"
+   ": a(aa), // Some comment\n"
+   "  a(aa),\n"
+   "  a(aa) {}",
+   BestFit);
+  verifyFormat("MyClass::MyClass(int var)\n"
+   ": some_var_(var),// 4 space indent\n"
+   "  some_other_var_(var + 1) { // lined up\n"
+   "}",
+   BestFit);
+  verifyFormat("Constructor() : a(a), a(a) {}\n",
+   BestFit);
+  verifyFormat("Constructor()\n"
+   ": a(aa),\n"
+   "  a(aa),\n"
+   "  a(aa),\n"
+   "  a(aa),\n"
+   "  a(aa) {}",
+   BestFit);
+  verifyFormat("Constructor()\n"
+   ": a(aa, aa,\n"
+   "aa) {}",
+   BestFit);
+  BestFit.ColumnLimit = 60;
+  verifyFormat("Constructor()\n"
+   ": (a),\n"
+   "  (b) {}",
+   BestFit);
+
+  EXPECT_EQ("Constructor()\n"
+": // Comment forcing unwanted break.\n"
+"  () {}",
+format("Constructor() :\n"
+   "// Comment forcing unwanted break.\n"
+   "() {}"));
+
   FormatStyle OnePerLine = getLLVMStyle();
-  OnePerLine.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  OnePerLine.ConstructorInitializer = FormatStyle::CI_OnePerLine;
   OnePerLine.AllowAllParametersOfDeclarationOnNextLine = false;
   verifyFormat("SomeClass::Constructor()\n"
": a(aa),\n"
@@ -4685,6 +4728,14 @@
"  some_other_var_(var + 1) { // lined up\n"
"}",
OnePerLine);
+  verifyFormat("Constructor()\n"
+   ": a(a),\n"
+   "  a(a) {}",
+   OnePerLine);
+  verifyFormat("Constructor()\n"
+   ": a(a),\n"
+   "  a(a) {}",
+   OnePerLine);
   verifyFormat("Constructor()\n"
": a(aa),\n"
"  a(aa),\n"
@@ -4721,7 +4772,7 @@
   FormatStyle Style = getLLVMStyle();
   Style.BreakConstructorInitializers = FormatStyle::BCIS_BeforeComma;
   Style.ColumnLimit = 60;
-  Style.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  Style.ConstructorInitializer = FormatStyle::CI_BestFit;
   Style.AllowAllConstructorInitializersOnNextLine = true;
   Style.BinPackParameters = false;
 
@@ -4919,13 +4970,13 @@
   verifyFormat("template \n"
"Constructor() : Initializer(FitsOnTheLine) {}",
getStyleWithColumns(Style, 50));
-  Style.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  Style.ConstructorInitializer = FormatStyle::CI_BestFit;
   verifyFormat(
   "SomeClass::Constructor() :\n"
   "a(aa), aaa() {}",
   Style);
 
-  Style.ConstructorInitializerAllOnOneLineOrOnePerLine = false;
+  Style.ConstructorInitializer = FormatStyle::CI_Compact;
   verifyFormat(
   "SomeClass::Constructor() :\n"
   "a(aa), aaa() {}",
@@ -4980,7 +5031,7 @@
Style);
 
   FormatStyle 

[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Michael Liao via Phabricator via cfe-commits
hliao updated this revision to Diff 300985.
hliao added a comment.

Test case is enhanced to check that no kernel argument type is coerced.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
  clang/test/CodeGenCUDA/kernel-args.cu

Index: clang/test/CodeGenCUDA/kernel-args.cu
===
--- clang/test/CodeGenCUDA/kernel-args.cu
+++ clang/test/CodeGenCUDA/kernel-args.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=AMDGCN %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda- -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=NVPTX %s
@@ -6,17 +6,18 @@
 
 struct A {
   int a[32];
+  float *p;
 };
 
-// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 4 %x)
+// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 8 %x)
 __global__ void kernel(A x) {
 }
 
 class Kernel {
 public:
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 8 %x)
   static __global__ void memberKernel(A x){}
   template static __global__ void templateMemberKernel(T x) {}
 };
@@ -29,11 +30,11 @@
 
 void test() {
   Kernel K;
-  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)templateKernel);
 
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)Kernel::templateMemberKernel);
 }
Index: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ /dev/null
@@ -1,113 +0,0 @@
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -emit-llvm -x hip %s -o - | FileCheck --check-prefixes=COMMON,CHECK %s
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -emit-llvm -x hip %s -disable-O0-optnone -o - | opt -S -O2 | FileCheck %s --check-prefixes=COMMON,OPT
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -x hip %s -o - | FileCheck -check-prefix=HOST %s
-
-#include "Inputs/cuda.h"
-
-// Coerced struct from `struct S` without all generic pointers lowered into
-// global ones.
-// COMMON: %struct.S.coerce = type { i32 addrspace(1)*, float addrspace(1)* }
-// COMMON: %struct.T.coerce = type { [2 x float addrspace(1)*] }
-
-// On the host-side compilation, generic pointer won't be coerced.
-// HOST-NOT: %struct.S.coerce
-// HOST-NOT: %struct.T.coerce
-
-// HOST: define void @_Z22__device_stub__kernel1Pi(i32* %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel1Pi(i32 addrspace(1)*{{.*}} %x.coerce)
-// CHECK: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// CHECK-NOT: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// OPT: [[VAL:%.*]] = load i32, i32 addrspace(1)* %x.coerce, align 4
-// OPT: [[INC:%.*]] = add nsw i32 [[VAL]], 1
-// OPT: store i32 [[INC]], i32 addrspace(1)* %x.coerce, align 4
-// OPT: ret void
-__global__ void kernel1(int *x) {
-  x[0]++;
-}
-
-// HOST: define void @_Z22__device_stub__kernel2Ri(i32* nonnull align 4 dereferenceable(4) %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel2Ri(i32 addrspace(1)*{{.*}} nonnull align 4 dereferenceable(4) %x.coerce)
-// CHECK:

[PATCH] D90110: [clang-tidy] Use --use-color in run-clang-tidy.py

2020-10-27 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.

This change LGTM, but please wait a few days in case @alexfh (or others) have 
concerns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90110

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


[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

In D89980#2348339 , @tra wrote:

> Are there any tests to illustrate what this change does to IR or generated 
> code?

the existing test `kernel-args.cu` is enhanced by adding a pointer in that 
aggregate kernel argument. Previously, as the pointer is used in that aggregate 
kernel argument,  it will be coerced into a global pointer. Now, it won't be 
changed anymore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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


[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Michael Liao via Phabricator via cfe-commits
hliao updated this revision to Diff 300989.
hliao added a comment.

Revise the comment and point the safety issue by coercing the kernel argument
from a generic pointer to a global one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
  clang/test/CodeGenCUDA/kernel-args.cu

Index: clang/test/CodeGenCUDA/kernel-args.cu
===
--- clang/test/CodeGenCUDA/kernel-args.cu
+++ clang/test/CodeGenCUDA/kernel-args.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=AMDGCN %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda- -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=NVPTX %s
@@ -6,17 +6,18 @@
 
 struct A {
   int a[32];
+  float *p;
 };
 
-// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 4 %x)
+// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 8 %x)
 __global__ void kernel(A x) {
 }
 
 class Kernel {
 public:
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 8 %x)
   static __global__ void memberKernel(A x){}
   template static __global__ void templateMemberKernel(T x) {}
 };
@@ -29,11 +30,11 @@
 
 void test() {
   Kernel K;
-  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)templateKernel);
 
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)Kernel::templateMemberKernel);
 }
Index: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ /dev/null
@@ -1,113 +0,0 @@
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -emit-llvm -x hip %s -o - | FileCheck --check-prefixes=COMMON,CHECK %s
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -emit-llvm -x hip %s -disable-O0-optnone -o - | opt -S -O2 | FileCheck %s --check-prefixes=COMMON,OPT
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -x hip %s -o - | FileCheck -check-prefix=HOST %s
-
-#include "Inputs/cuda.h"
-
-// Coerced struct from `struct S` without all generic pointers lowered into
-// global ones.
-// COMMON: %struct.S.coerce = type { i32 addrspace(1)*, float addrspace(1)* }
-// COMMON: %struct.T.coerce = type { [2 x float addrspace(1)*] }
-
-// On the host-side compilation, generic pointer won't be coerced.
-// HOST-NOT: %struct.S.coerce
-// HOST-NOT: %struct.T.coerce
-
-// HOST: define void @_Z22__device_stub__kernel1Pi(i32* %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel1Pi(i32 addrspace(1)*{{.*}} %x.coerce)
-// CHECK: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// CHECK-NOT: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// OPT: [[VAL:%.*]] = load i32, i32 addrspace(1)* %x.coerce, align 4
-// OPT: [[INC:%.*]] = add nsw i32 [[VAL]], 1
-// OPT: store i32 [[INC]], i32 addrspace(1)* %x.coerce, align 4
-// OPT: ret void
-__global__ void kernel1(int *x) {
-  x[0]++;
-}
-
-// HOST: define void @_Z22__device_stub__kernel2Ri(i32* nonnull align 4 dereferenceable(4) %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel2Ri(i32 addrspace(1)*{{.*}} nonnull al

[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm requested changes to this revision.
arsenm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu:30
-}
-
-// HOST: define void @_Z22__device_stub__kernel2Ri(i32* nonnull align 4 
dereferenceable(4) %x)

This test should not be deleted. I want to see the diff in the IR produced 
here. I think this still be worse, since AA does not answer all of the problems 
of using generic pointers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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


[PATCH] D87030: Adapt CastExpr::getSubExprAsWritten to ConstantExpr

2020-10-27 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg added a comment.

ping


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

https://reviews.llvm.org/D87030

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


[PATCH] D89481: [scan-build] Fix clang++ pathname again

2020-10-27 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89481

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


[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Michael Liao via Phabricator via cfe-commits
hliao added inline comments.



Comment at: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu:30
-}
-
-// HOST: define void @_Z22__device_stub__kernel2Ri(i32* nonnull align 4 
dereferenceable(4) %x)

arsenm wrote:
> This test should not be deleted. I want to see the diff in the IR produced 
> here. I think this still be worse, since AA does not answer all of the 
> problems of using generic pointers
Could you elaborate on problems using generic pointers?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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


[PATCH] D88553: [clangd] Start using SyntaxTrees for folding ranges feature

2020-10-27 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-tools-extra/clangd/SemanticSelection.cpp:42
+
+llvm::Optional toFoldingRange(LocInfo Begin, LocInfo End,
+const SourceManager &SM) {

just use SourceLocations or SourceRange here? We have the SourceManager to 
decompose them anyway.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88553

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


[PATCH] D90238: Update to D31635

2020-10-27 Thread Andrew Somerville via Phabricator via cfe-commits
catskul created this revision.
catskul added a reviewer: clang-format.
catskul added a project: clang-format.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
catskul requested review of this revision.

I'm trying to get D31635  past the finish line 
so I've adopted it.

This revision:

- fixes the documentation by running `dump_format_style.py`
- adds test for PAS_Right + RAS_Left and commented out '* &' example


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90238

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/TokenAnnotator.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -884,6 +884,43 @@
getLLVMStyleWithColumns(62));
 }
 
+TEST_F(FormatTest, SeparatePointerReferenceAlignment) {
+  FormatStyle Style = getLLVMStyle();
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  Style.ReferenceAlignment = FormatStyle::RAS_Pointer;
+  verifyFormat("int* f1(int* a, int& b, int&& c);", Style);
+  verifyFormat("int& f2(int&& c, int* a, int& b);", Style);
+  verifyFormat("int&& f3(int& b, int&& c, int* a);", Style);
+  verifyFormat("int* a = f1();\nint& b = f2();\nint&& c = f3();", Style);
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  Style.ReferenceAlignment = FormatStyle::RAS_Pointer;
+  verifyFormat("int *f1(int *a, int &b, int &&c);", Style);
+  verifyFormat("int &f2(int &&c, int *a, int &b);", Style);
+  verifyFormat("int &&f3(int &b, int &&c, int *a);", Style);
+  verifyFormat("int *a = f1();\nint &b = f2();\nint &&c = f3();", Style);
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  Style.ReferenceAlignment = FormatStyle::RAS_Left;
+  verifyFormat("int *f1(int *a, int& b, int&& c);", Style);
+  verifyFormat("int& f2(int&& c, int *a, int& b);", Style);
+  verifyFormat("int&& f3(int& b, int&& c, int *a);", Style);
+  verifyFormat("int *a = f1();\nint& b = f2();\nint&& c = f3();", Style);
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  Style.ReferenceAlignment = FormatStyle::RAS_Middle;
+  verifyFormat("int* f1(int* a, int & b, int && c);", Style);
+  verifyFormat("int & f2(int && c, int* a, int & b);", Style);
+  verifyFormat("int && f3(int & b, int && c, int* a);", Style);
+  verifyFormat("int* a = f1();\nint & b = f2();\nint && c = f3();", Style);
+  Style.PointerAlignment = FormatStyle::PAS_Middle;
+  Style.ReferenceAlignment = FormatStyle::RAS_Right;
+  verifyFormat("int * f1(int * a, int &b, int &&c);", Style);
+  verifyFormat("int &f2(int &&c, int * a, int &b);", Style);
+  verifyFormat("int &&f3(int &b, int &&c, int * a);", Style);
+  verifyFormat("int * a = f1();\nint &b = f2();\nint &&c = f3();", Style);
+
+  // we don't handle this yet, so output may be arbitrary until it's specifically handled
+  //verifyFormat("int Add2(BTree * &Root, char * szToAdd)", Style);
+}
+
 TEST_F(FormatTest, FormatsForLoop) {
   verifyFormat(
   "for (int VeryVeryLongLoopVariable = 0; VeryVeryLongLoopVariable < 10;\n"
@@ -13744,6 +13781,15 @@
   FormatStyle::PAS_Right);
   CHECK_PARSE("PointerAlignment: Middle", PointerAlignment,
   FormatStyle::PAS_Middle);
+  Style.ReferenceAlignment = FormatStyle::RAS_Middle;
+  CHECK_PARSE("ReferenceAlignment: Pointer", ReferenceAlignment,
+  FormatStyle::RAS_Pointer);
+  CHECK_PARSE("ReferenceAlignment: Left", ReferenceAlignment,
+  FormatStyle::RAS_Left);
+  CHECK_PARSE("ReferenceAlignment: Right", ReferenceAlignment,
+  FormatStyle::RAS_Right);
+  CHECK_PARSE("ReferenceAlignment: Middle", ReferenceAlignment,
+  FormatStyle::RAS_Middle);
   // For backward compatibility:
   CHECK_PARSE("PointerBindsToType: Left", PointerAlignment,
   FormatStyle::PAS_Left);
Index: clang/lib/Format/TokenAnnotator.h
===
--- clang/lib/Format/TokenAnnotator.h
+++ clang/lib/Format/TokenAnnotator.h
@@ -189,6 +189,9 @@
 
   void calculateUnbreakableTailLengths(AnnotatedLine &Line);
 
+  FormatStyle::PointerAlignmentStyle
+  getTokenPointerAlignment(const FormatToken &PointerOrReference);
+
   const FormatStyle &Style;
 
   const AdditionalKeywords &Keywords;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2822,14 +2822,14 @@
 }
 return (Left.Tok.isLiteral() ||
 (!Left.isOneOf(TT_PointerOrReference, tok::l_paren) &&
- (Style.PointerAlignment != FormatStyle::PAS_Left ||
+ (getTokenPointerAlignment(Right) != FormatStyle::PAS_Left ||
   (Li

[PATCH] D89899: [CodeGen] Implement [[likely]] and [[unlikely]] for the iteration statements

2020-10-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:1861
+
+  do [[unlikely]] {   // The loop will always iterate once
+...   // The likelihood attribute affects the likelihood of the

Mordante wrote:
> aaron.ballman wrote:
> > Oye, I don't know how I feel about this. According to the standard 
> > (http://eel.is/c++draft/stmt.pre#1), the unlikely attribute appertains to 
> > the compound statement, not the expression within the while loop and that 
> > compound statement is required to be entered at least once so this just 
> > feels really unintuitive to me. WDYT?
> I like the current approach. I agree it feels a bit odd, the initial path of 
> execution will always be the substatement. Whether the substatement will be 
> executed after the condition in the `while` isn't known upfront so there the 
> likelihood attribute can help. If we don't allow it here I see no other way 
> to express the fact the user expects it unlikely the loop more than one 
> iteration.
> 
> I just did a short test with GCC and MSVC and it seems to have no effect on 
> the generated assembly code. So maybe it would be better to remove it for now 
> and discuss it later with the other vendors. Do you agree?
> 
> I just did a short test with GCC and MSVC and it seems to have no effect on 
> the generated assembly code. So maybe it would be better to remove it for now 
> and discuss it later with the other vendors. Do you agree?

I think that's a great approach, thank you!

The reason I am uncomfortable with the current approach is that we went to a 
lot of effort to make appertainment clear for attributes and *not* let them 
slide around like GNU-style attributes, and that's effectively what this one is 
doing. So while the behavior we get is not the worst, it opens the door to more 
"oh, but I know better than the user where this belongs" sort of shenanigans 
that we should be resistant to.



Comment at: clang/include/clang/Basic/AttrDocs.td:1866
+  while(true) [[unlikely]] {
+...   // The attribute has no effect
+  }   // Clang elides comparison and generates an infinite loop

Mordante wrote:
> aaron.ballman wrote:
> > This is a bit of an edge case where I can't tell whether we should or 
> > should not diagnose. On the one hand, the user wrote something and we think 
> > it's meaningless, which we would usually diagnose as being an ignored 
> > attribute so the user can maybe react to it. On the other hand, "has no 
> > effect" is perhaps not the same as "ignored", as with `i + 0` (it's not 
> > really ignored but you would expect it to have no effect either).
> In this case it's ignored since the CodeGen doesn't create a branch 
> instruction. GCC does the same at -O0, MSVC creates the branch at -O0, but 
> removes it at higher optimization levels. So since the other two main 
> compilers also remove the branch I think we could issue a diagnostic in this 
> case we can do that when the CodeGen determines the branch isn't needed. In 
> that case I don't expect false positives. Agreed?
> 
> 
I think that's reasonable if it's easy enough for you to do, but I don't insist 
on a diagnostic if it turns out to be tricky to support for some reason.



Comment at: clang/include/clang/Basic/AttrDocs.td:1871
+...   // The attribute has no effect
+  } while(0); // Clang elides comparison and generates no loop
+

Mordante wrote:
> aaron.ballman wrote:
> > elides comparison -> elides the comparison
> If we keep the do/while likelihood and issue a diagnostic for `while(1)` we 
> should do the same here.
Agreed, good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89899

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


[PATCH] D90240: [SyntaxTree] Add reverse links to syntax Nodes.

2020-10-27 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

Rationale:
Children of a syntax tree had forward links only, because there was no
need for reverse links.

This need appeared when we started mutating the syntax tree.
On a forward list, to remove a target node in O(1) we need a pointer to the 
node before the target. If we don't have this "before" pointer, we have to find 
it, and that requires O(n).
So in order to remove a syntax node from a tree, we would similarly need to 
find the node before to then remove. This is both not ergonomic nor does it 
have a good complexity.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90240

Files:
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/Mutations.cpp
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -57,8 +57,9 @@
 }
 
 syntax::Node::Node(NodeKind Kind)
-: Parent(nullptr), NextSibling(nullptr), Kind(static_cast(Kind)),
-  Role(0), Original(false), CanModify(false) {
+: Parent(nullptr), NextSibling(nullptr), PreviousSibling(nullptr),
+  Kind(static_cast(Kind)), Role(0), Original(false),
+  CanModify(false) {
   this->setRole(NodeRole::Detached);
 }
 
@@ -85,10 +86,16 @@
 void syntax::Tree::prependChildLowLevel(Node *Child) {
   assert(Child->Parent == nullptr);
   assert(Child->NextSibling == nullptr);
+  assert(Child->PreviousSibling == nullptr);
   assert(Child->getRole() != NodeRole::Detached);
 
   Child->Parent = this;
-  Child->NextSibling = this->FirstChild;
+  if (this->FirstChild) {
+Child->NextSibling = this->FirstChild;
+this->FirstChild->PreviousSibling = Child;
+  } else
+this->LastChild = Child;
+
   this->FirstChild = Child;
 }
 
@@ -100,6 +107,7 @@
   assert(canModify() && "Cannot modify `this`.");
 
   Node *&Begin = BeforeBegin ? BeforeBegin->NextSibling : FirstChild;
+  Node *&Last = End ? End->PreviousSibling : LastChild;
 
 #ifndef NDEBUG
   for (auto *N = New; N; N = N->NextSibling) {
@@ -135,6 +143,7 @@
 N->setRole(NodeRole::Detached);
 N->Parent = nullptr;
 N->NextSibling = nullptr;
+N->PreviousSibling = nullptr;
 if (N->Original)
   traverse(N, [](Node *C) { C->Original = false; });
 
@@ -143,16 +152,19 @@
 
   if (!New) {
 Begin = End;
+Last = BeforeBegin;
 return;
   }
   // Attach new nodes.
   Begin = New;
-  auto *Last = New;
+  New->PreviousSibling = BeforeBegin;
+  auto *LastInNew = New;
   for (auto *N = New; N != nullptr; N = N->NextSibling) {
-Last = N;
+LastInNew = N;
 N->Parent = this;
   }
-  Last->NextSibling = End;
+  LastInNew->NextSibling = End;
+  Last = LastInNew;
 }
 
 namespace {
@@ -243,11 +255,20 @@
   const auto *T = dyn_cast(this);
   if (!T)
 return;
+
+  const auto *Last = T->getFirstChild();
+  for (; Last && Last->getNextSibling(); Last = Last->getNextSibling())
+;
+  assert(Last == T->getLastChild() &&
+ "Last child is reachable by advancing from the first child.");
+
   for (const auto *C = T->getFirstChild(); C; C = C->getNextSibling()) {
 if (T->isOriginal())
   assert(C->isOriginal());
 assert(!C->isDetached());
 assert(C->getParent() == T);
+const auto *Next = C->getNextSibling();
+assert(!Next || C == Next->getPreviousSibling());
   }
 
   const auto *L = dyn_cast(T);
@@ -282,14 +303,13 @@
 }
 
 syntax::Leaf *syntax::Tree::findLastLeaf() {
-  syntax::Leaf *Last = nullptr;
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+  for (auto *C = getLastChild(); C; C = C->getPreviousSibling()) {
 if (auto *L = dyn_cast(C))
-  Last = L;
-else if (auto *L = cast(C)->findLastLeaf())
-  Last = L;
+  return L;
+if (auto *L = cast(C)->findLastLeaf())
+  return L;
   }
-  return Last;
+  return nullptr;
 }
 
 syntax::Node *syntax::Tree::findChild(NodeRole R) {
Index: clang/lib/Tooling/Syntax/Mutations.cpp
===
--- clang/lib/Tooling/Syntax/Mutations.cpp
+++ clang/lib/Tooling/Syntax/Mutations.cpp
@@ -23,19 +23,6 @@
 
 using namespace clang;
 
-static syntax::Node *findPrevious(syntax::Node *N) {
-  assert(N);
-  assert(N->getParent());
-  if (N->getParent()->getFirstChild() == N)
-return nullptr;
-  for (syntax::Node *C = N->getParent()->getFirstChild(); C != nullptr;
-   C = C->getNextSibling()) {
-if (C->getNextSibling() == N)
-  return C;
-  }
-  llvm_unreachable("could not find a child node");
-}
-
 // This class has access to the internals of tree nodes. Its sole purpose is to
 // define helpers that allow implementing the high-level mutation operations.
 class syntax::MutationsImpl {
@@ -46,6 +33,7 @@
 assert(Anchor->Parent != nullptr);
 assert(New->Pare

[PATCH] D90240: [SyntaxTree] Add reverse links to syntax Nodes.

2020-10-27 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas added a reviewer: gribozavr2.
eduucaldas added a subscriber: sammccall.
eduucaldas added inline comments.



Comment at: clang/include/clang/Tooling/Syntax/Tree.h:189
   /// EXPECTS: Child->Role != Detached
   void prependChildLowLevel(Node *Child);
   friend class TreeBuilder;

Should we provide an `appendChildLowLevel` as well?

That has one use inside `foldChildren` in `BuildTree.cpp`. 
Currently this function does a reverse iteration prepending children. We could 
change that into a forward iteration appending. There is no impact in 
time-complexity. This change would just improve readability inside this 
function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90240

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


[clang] 5984097 - [AMDGPU] Add missing support for targets

2020-10-27 Thread via cfe-commits

Author: Tony
Date: 2020-10-27T15:36:31Z
New Revision: 5984097823891fc90438a3b859c513a0b63331cd

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

LOG: [AMDGPU] Add missing support for targets

- Add missing tests.

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

Added: 


Modified: 
clang/test/CodeGenOpenCL/amdgpu-features.cl
llvm/lib/Object/ELFObjectFile.cpp
llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test

Removed: 




diff  --git a/clang/test/CodeGenOpenCL/amdgpu-features.cl 
b/clang/test/CodeGenOpenCL/amdgpu-features.cl
index a463c061114e..6a27c047d58c 100644
--- a/clang/test/CodeGenOpenCL/amdgpu-features.cl
+++ b/clang/test/CodeGenOpenCL/amdgpu-features.cl
@@ -11,6 +11,7 @@
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx904 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX904 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx906 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX906 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx908 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX908 %s
+// RUN: %clang_cc1 -triple amdgcn -target-cpu gfx909 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX909 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1010 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1010 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1011 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1011 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1012 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1012 %s
@@ -22,10 +23,22 @@
 // GFX601-NOT: "target-features"
 // GFX602-NOT: "target-features"
 // GFX700: "target-features"="+ci-insts,+flat-address-space"
+// GFX701: "target-features"="+ci-insts,+flat-address-space"
+// GFX702: "target-features"="+ci-insts,+flat-address-space"
+// GFX703: "target-features"="+ci-insts,+flat-address-space"
+// GFX704: "target-features"="+ci-insts,+flat-address-space"
+// GFX705: "target-features"="+ci-insts,+flat-address-space"
 // GFX801: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+s-memrealtime"
+// GFX802: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+s-memrealtime"
+// GFX803: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+s-memrealtime"
+// GFX805: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+s-memrealtime"
+// GFX810: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+s-memrealtime"
+// GFX900: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+s-memrealtime"
+// GFX902: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX904: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX906: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX908: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+mai-insts,+s-memrealtime"
+// GFX909: 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+flat-address-space,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX1010: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dpp,+flat-address-space,+gfx10-insts,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX1011: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dot5-insts,+dot6-insts,+dpp,+flat-address-space,+gfx10-insts,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX1012: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dot5-insts,+dot6-insts,+dpp,+flat-address-space,+gfx10-insts,+gfx8-insts,+gfx9-insts,+s-memrealtime"

diff  --git a/llvm/lib/Object/ELFObjectFile.cpp 
b/llvm/lib/Object/ELFObjectFile.cpp
index 1807a57e7dc1..fda89d85ba25 100644
--- a/llvm/lib/Object/ELFObjectFile.cpp
+++ b/llvm/lib/Object/ELFObjectFile.cpp
@@ -466,7 +466,10 @@ StringRef ELFObjectFileBase::getAMDGPUCPUName() const {
 return "gfx1012";
   case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1030:
 return "gfx1030";
-
+  case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1031:
+return "gfx1031";
+  case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1032:
+return "gfx1032";
   default:
 llvm_unreachable("Unknown EF_AMDGPU_MACH value");
   }

diff  --git a/llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml 
b/llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
index 78a845c5a941..16779920674f 100644
--- a/llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ b/ll

[PATCH] D90212: [AMDGPU] Add missing support for targets

2020-10-27 Thread Tony Tye 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 rG598409782389: [AMDGPU] Add missing support for targets 
(authored by t-tye).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90212

Files:
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test

Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -73,6 +73,9 @@
 # RUN: yaml2obj %s -o %t -DCPU=GFX1031
 # RUN: llvm-readobj -h %t | FileCheck %s --match-full-lines -DFILE=%t -DCPU=GFX1031 -DFLAGS=0x37
 
+# RUN: yaml2obj %s -o %t -DCPU=GFX1032
+# RUN: llvm-readobj -h %t | FileCheck %s --match-full-lines -DFILE=%t -DCPU=GFX1032 -DFLAGS=0x38
+
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
Index: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
===
--- llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
@@ -1,115 +1,171 @@
 # RUN: yaml2obj --docnum=1 %s -o %t.o.1
 # RUN: llvm-readobj -S --file-headers %t.o.1 | FileCheck --check-prefixes=ELF-ALL,ELF-R600 %s
 # RUN: obj2yaml %t.o.1 | FileCheck --check-prefixes=YAML-R600 %s
+
 # RUN: yaml2obj --docnum=2 %s -o %t.o.2
 # RUN: llvm-readobj -S --file-headers %t.o.2 | FileCheck --check-prefixes=ELF-ALL,ELF-R630 %s
 # RUN: obj2yaml %t.o.2 | FileCheck --check-prefixes=YAML-R630 %s
+
 # RUN: yaml2obj --docnum=3 %s -o %t.o.3
 # RUN: llvm-readobj -S --file-headers %t.o.3 | FileCheck --check-prefixes=ELF-ALL,ELF-RS880 %s
 # RUN: obj2yaml %t.o.3 | FileCheck --check-prefixes=YAML-RS880 %s
+
 # RUN: yaml2obj --docnum=4 %s -o %t.o.4
 # RUN: llvm-readobj -S --file-headers %t.o.4 | FileCheck --check-prefixes=ELF-ALL,ELF-RV670 %s
 # RUN: obj2yaml %t.o.4 | FileCheck --check-prefixes=YAML-RV670 %s
+
 # RUN: yaml2obj --docnum=5 %s -o %t.o.5
 # RUN: llvm-readobj -S --file-headers %t.o.5 | FileCheck --check-prefixes=ELF-ALL,ELF-RV710 %s
 # RUN: obj2yaml %t.o.5 | FileCheck --check-prefixes=YAML-RV710 %s
+
 # RUN: yaml2obj --docnum=6 %s -o %t.o.6
 # RUN: llvm-readobj -S --file-headers %t.o.6 | FileCheck --check-prefixes=ELF-ALL,ELF-RV730 %s
 # RUN: obj2yaml %t.o.6 | FileCheck --check-prefixes=YAML-RV730 %s
+
 # RUN: yaml2obj --docnum=7 %s -o %t.o.7
 # RUN: llvm-readobj -S --file-headers %t.o.7 | FileCheck --check-prefixes=ELF-ALL,ELF-RV770 %s
 # RUN: obj2yaml %t.o.7 | FileCheck --check-prefixes=YAML-RV770 %s
+
 # RUN: yaml2obj --docnum=8 %s -o %t.o.8
 # RUN: llvm-readobj -S --file-headers %t.o.8 | FileCheck --check-prefixes=ELF-ALL,ELF-CEDAR %s
 # RUN: obj2yaml %t.o.8 | FileCheck --check-prefixes=YAML-CEDAR %s
+
 # RUN: yaml2obj --docnum=9 %s -o %t.o.9
 # RUN: llvm-readobj -S --file-headers %t.o.9 | FileCheck --check-prefixes=ELF-ALL,ELF-CYPRESS %s
 # RUN: obj2yaml %t.o.9 | FileCheck --check-prefixes=YAML-CYPRESS %s
+
 # RUN: yaml2obj --docnum=10 %s -o %t.o.10
 # RUN: llvm-readobj -S --file-headers %t.o.10 | FileCheck --check-prefixes=ELF-ALL,ELF-JUNIPER %s
 # RUN: obj2yaml %t.o.10 | FileCheck --check-prefixes=YAML-JUNIPER %s
+
 # RUN: yaml2obj --docnum=11 %s -o %t.o.11
 # RUN: llvm-readobj -S --file-headers %t.o.11 | FileCheck --check-prefixes=ELF-ALL,ELF-REDWOOD %s
 # RUN: obj2yaml %t.o.11 | FileCheck --check-prefixes=YAML-REDWOOD %s
+
 # RUN: yaml2obj --docnum=12 %s -o %t.o.12
 # RUN: llvm-readobj -S --file-headers %t.o.12 | FileCheck --check-prefixes=ELF-ALL,ELF-SUMO %s
 # RUN: obj2yaml %t.o.12 | FileCheck --check-prefixes=YAML-SUMO %s
+
 # RUN: yaml2obj --docnum=13 %s -o %t.o.13
 # RUN: llvm-readobj -S --file-headers %t.o.13 | FileCheck --check-prefixes=ELF-ALL,ELF-BARTS %s
 # RUN: obj2yaml %t.o.13 | FileCheck --check-prefixes=YAML-BARTS %s
+
 # RUN: yaml2obj --docnum=14 %s -o %t.o.14
 # RUN: llvm-readobj -S --file-headers %t.o.14 | FileCheck --check-prefixes=ELF-ALL,ELF-CAICOS %s
 # RUN: obj2yaml %t.o.14 | FileCheck --check-prefixes=YAML-CAICOS %s
+
 # RUN: yaml2obj --docnum=15 %s -o %t.o.15
 # RUN: llvm-readobj -S --file-headers %t.o.15 | FileCheck --check-prefixes=ELF-ALL,ELF-CAYMAN %s
 # RUN: obj2yaml %t.o.15 | FileCheck --check-prefixes=YAML-CAYMAN %s
+
 # RUN: yaml2obj --docnum=16 %s -o %t.o.16
 # RUN: llvm-readobj -S --file-headers %t.o.16 | FileCheck --check-prefixes=ELF-ALL,ELF-TURKS %s
 # RUN: obj2yaml %t.o.16 | FileCheck --check-prefixes=YAML-TURKS %s
+
 # RUN: yaml2obj --docnum=17 %s -o %t.o.17
 # RUN: llvm-readobj -S --file-headers %t.o.17 | FileCheck --check-prefixes=ELF-ALL,ELF-GFX600 %s
 # RUN: obj2yaml %t.o.17 | FileCheck --check-prefixes=YAML-GFX600 %s
+
 # RUN: yaml2obj --docnu

[PATCH] D89936: [clang-tidy] adding "--clang-tidy-config=" to specify custom config file

2020-10-27 Thread Dmitry Polukhin via Phabricator via cfe-commits
DmitryPolukhin added a comment.

Yes, it is what I meant as a simpler solution. But please add Lit test even for 
such trivial option.




Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:337
+
+Config.assign((*Text)->getBuffer());
+  }

I suggest creating new local variable with text of the config from `Config` or 
`ConfigFile` file content i.e. avoid modifying `Config` itself.


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

https://reviews.llvm.org/D89936

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


[PATCH] D88553: [clangd] Start using SyntaxTrees for folding ranges feature

2020-10-27 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 301008.
kbobyrev added a comment.

Address post-LGTM comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88553

Files:
  clang-tools-extra/clangd/SemanticSelection.cpp
  clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -271,29 +271,29 @@
 #endif
 }
 
-syntax::Leaf *syntax::Tree::findFirstLeaf() {
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findFirstLeaf() const {
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   return L;
-if (auto *L = cast(C)->findFirstLeaf())
+if (const auto *L = cast(C)->findFirstLeaf())
   return L;
   }
   return nullptr;
 }
 
-syntax::Leaf *syntax::Tree::findLastLeaf() {
-  syntax::Leaf *Last = nullptr;
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findLastLeaf() const {
+  const syntax::Leaf *Last = nullptr;
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   Last = L;
-else if (auto *L = cast(C)->findLastLeaf())
+else if (const auto *L = cast(C)->findLastLeaf())
   Last = L;
   }
   return Last;
 }
 
-syntax::Node *syntax::Tree::findChild(NodeRole R) {
-  for (auto *C = FirstChild; C; C = C->getNextSibling()) {
+const syntax::Node *syntax::Tree::findChild(NodeRole R) const {
+  for (const auto *C = FirstChild; C; C = C->getNextSibling()) {
 if (C->getRole() == R)
   return C;
   }
Index: clang/include/clang/Tooling/Syntax/Tree.h
===
--- clang/include/clang/Tooling/Syntax/Tree.h
+++ clang/include/clang/Tooling/Syntax/Tree.h
@@ -168,20 +168,21 @@
   Node *getFirstChild() { return FirstChild; }
   const Node *getFirstChild() const { return FirstChild; }
 
-  Leaf *findFirstLeaf();
-  const Leaf *findFirstLeaf() const {
-return const_cast(this)->findFirstLeaf();
+  const Leaf *findFirstLeaf() const;
+  Leaf *findFirstLeaf() {
+return const_cast(const_cast(this)->findFirstLeaf());
   }
 
-  Leaf *findLastLeaf();
-  const Leaf *findLastLeaf() const {
-return const_cast(this)->findLastLeaf();
+  const Leaf *findLastLeaf() const;
+  Leaf *findLastLeaf() {
+return const_cast(const_cast(this)->findLastLeaf());
   }
 
-protected:
-  using Node::Node;
   /// Find the first node with a corresponding role.
-  Node *findChild(NodeRole R);
+  const Node *findChild(NodeRole R) const;
+  Node *findChild(NodeRole R) {
+return const_cast(const_cast(this)->findChild(R));
+  }
 
 private:
   /// Prepend \p Child to the list of children and and sets the parent pointer.
Index: clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
@@ -203,26 +203,61 @@
 TEST(FoldingRanges, All) {
   const char *Tests[] = {
   R"cpp(
-[[int global_variable]];
+#define FOO int foo() {\
+  int Variable = 42; \
+}
 
-[[void func() {
-  int v = 100;
-}]]
+// Do not generate folding range for braces within macro expansion.
+FOO
+
+// Do not generate folding range within macro arguments.
+#define FUNCTOR(functor) functor
+void func() {[[
+  FUNCTOR([](){});
+]]}
+
+// Do not generate folding range with a brace coming from macro.
+#define LBRACE {
+void bar() LBRACE
+  int X = 42;
+}
+  )cpp",
+  R"cpp(
+void func() {[[
+  int Variable = 100;
+
+  if (Variable > 5) {[[
+Variable += 42;
+  ]]} else if (Variable++)
+++Variable;
+  else {[[
+Variable--;
+  ]]}
+
+  // Do not generate FoldingRange for empty CompoundStmts.
+  for (;;) {}
+
+  // If there are newlines between {}, we should generate one.
+  for (;;) {[[
+
+  ]]}
+]]}
   )cpp",
   R"cpp(
-[[class Foo {
+class Foo {
 public:
-  [[Foo() {
+  Foo() {[[
 int X = 1;
-  }]]
+  ]]}
 
 private:
-  [[int getBar() {
+  int getBar() {[[
 return 42;
-  }]]
+  ]]}
 
-  [[void getFooBar() { }]]
-}]];
+  // Braces are located 

[PATCH] D88553: [clangd] Start using SyntaxTrees for folding ranges feature

2020-10-27 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 301009.
kbobyrev added a comment.

Resolve merge conflict.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88553

Files:
  clang-tools-extra/clangd/SemanticSelection.cpp
  clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -271,29 +271,29 @@
 #endif
 }
 
-syntax::Leaf *syntax::Tree::findFirstLeaf() {
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findFirstLeaf() const {
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   return L;
-if (auto *L = cast(C)->findFirstLeaf())
+if (const auto *L = cast(C)->findFirstLeaf())
   return L;
   }
   return nullptr;
 }
 
-syntax::Leaf *syntax::Tree::findLastLeaf() {
-  syntax::Leaf *Last = nullptr;
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findLastLeaf() const {
+  const syntax::Leaf *Last = nullptr;
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   Last = L;
-else if (auto *L = cast(C)->findLastLeaf())
+else if (const auto *L = cast(C)->findLastLeaf())
   Last = L;
   }
   return Last;
 }
 
-syntax::Node *syntax::Tree::findChild(NodeRole R) {
-  for (auto *C = FirstChild; C; C = C->getNextSibling()) {
+const syntax::Node *syntax::Tree::findChild(NodeRole R) const {
+  for (const auto *C = FirstChild; C; C = C->getNextSibling()) {
 if (C->getRole() == R)
   return C;
   }
Index: clang/include/clang/Tooling/Syntax/Tree.h
===
--- clang/include/clang/Tooling/Syntax/Tree.h
+++ clang/include/clang/Tooling/Syntax/Tree.h
@@ -168,20 +168,24 @@
   Node *getFirstChild() { return FirstChild; }
   const Node *getFirstChild() const { return FirstChild; }
 
-  Leaf *findFirstLeaf();
-  const Leaf *findFirstLeaf() const {
-return const_cast(this)->findFirstLeaf();
+  const Leaf *findFirstLeaf() const;
+  Leaf *findFirstLeaf() {
+return const_cast(const_cast(this)->findFirstLeaf());
   }
 
-  Leaf *findLastLeaf();
-  const Leaf *findLastLeaf() const {
-return const_cast(this)->findLastLeaf();
+  const Leaf *findLastLeaf() const;
+  Leaf *findLastLeaf() {
+return const_cast(const_cast(this)->findLastLeaf());
+  }
+
+  /// Find the first node with a corresponding role.
+  const Node *findChild(NodeRole R) const;
+  Node *findChild(NodeRole R) {
+return const_cast(const_cast(this)->findChild(R));
   }
 
 protected:
   using Node::Node;
-  /// Find the first node with a corresponding role.
-  Node *findChild(NodeRole R);
 
 private:
   /// Prepend \p Child to the list of children and and sets the parent pointer.
Index: clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
@@ -203,26 +203,61 @@
 TEST(FoldingRanges, All) {
   const char *Tests[] = {
   R"cpp(
-[[int global_variable]];
+#define FOO int foo() {\
+  int Variable = 42; \
+}
 
-[[void func() {
-  int v = 100;
-}]]
+// Do not generate folding range for braces within macro expansion.
+FOO
+
+// Do not generate folding range within macro arguments.
+#define FUNCTOR(functor) functor
+void func() {[[
+  FUNCTOR([](){});
+]]}
+
+// Do not generate folding range with a brace coming from macro.
+#define LBRACE {
+void bar() LBRACE
+  int X = 42;
+}
+  )cpp",
+  R"cpp(
+void func() {[[
+  int Variable = 100;
+
+  if (Variable > 5) {[[
+Variable += 42;
+  ]]} else if (Variable++)
+++Variable;
+  else {[[
+Variable--;
+  ]]}
+
+  // Do not generate FoldingRange for empty CompoundStmts.
+  for (;;) {}
+
+  // If there are newlines between {}, we should generate one.
+  for (;;) {[[
+
+  ]]}
+]]}
   )cpp",
   R"cpp(
-[[class Foo {
+class Foo {
 public:
-  [[Foo() {
+  Foo() {[[
 int X = 1;
-  }]]
+  ]]}
 
 private:
-  [[int getBar() {
+  int getBar() {[[
 return 42;
-  }]]
+  ]]}
 
-  [[void getFooBar() {

[PATCH] D82035: [PowerPC] Add Sema checks for MMA types

2020-10-27 Thread Baptiste Saleil via Phabricator via cfe-commits
bsaleil updated this revision to Diff 301010.
bsaleil added reviewers: nemanjai, saghir, lei, rsmith.
bsaleil added a comment.
Herald added a subscriber: dexonsmith.

Rebasing patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82035

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/Sema/ppc-mma-types.c
  clang/test/SemaCXX/ppc-mma-types.cpp

Index: clang/test/SemaCXX/ppc-mma-types.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/ppc-mma-types.cpp
@@ -0,0 +1,384 @@
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
+// RUN:   -fcxx-exceptions -target-cpu future %s -verify
+
+// vector quad
+
+// alias
+using vq_t = __vector_quad;
+void testVQAlias(int *inp, int *outp) {
+  vq_t *vqin = (vq_t *)inp;
+  vq_t *vqout = (vq_t *)outp;
+  *vqout = *vqin;
+}
+
+class TestClassVQ {
+  // method argument
+public:
+  void testVQArg1(__vector_quad vq, int *ptr) { // expected-error {{invalid use of PPC MMA type}}
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = vq;
+*vqp1 = vq;
+  }
+  void testVQArg2(const __vector_quad vq, int *ptr) { // expected-error {{invalid use of PPC MMA type}}
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = vq;
+*vqp2 = vq;
+  }
+  void testVQArg3(__vector_quad *vq, int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = *vq;
+vqp1 = vqp;
+  }
+  void testVQArg4(const __vector_quad *const vq, int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = *vq;
+vqp2 = vqp;
+  }
+  void testVQArg5(__vector_quad vqa[], int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = vqa[0];
+*vqp1 = vqa[1];
+  }
+  void testVQArg6(const vq_t vq, int *ptr) { // expected-error {{invalid use of PPC MMA type}}
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = vq;
+*vqp2 = vq;
+  }
+  void testVQArg7(const vq_t *vq, int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+*vqp = *vq;
+vqp1 = vqp;
+  }
+
+  // method return
+  __vector_quad testVQRet1(int *ptr) { // expected-error {{invalid use of PPC MMA type}}
+__vector_quad *vqp = (__vector_quad *)ptr;
+vq1 = *vqp;
+return *vqp; // expected-error {{invalid use of PPC MMA type}}
+  }
+
+  __vector_quad *testVQRet2(int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+vq2 = *vqp;
+return vqp + 2;
+  }
+
+  const __vector_quad *testVQRet3(int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+vqp1 = vqp;
+return vqp + 2;
+  }
+
+  const vq_t testVQRet4(int *ptr) { // expected-error {{invalid use of PPC MMA type}}
+__vector_quad *vqp = (__vector_quad *)ptr;
+vqp2 = vqp;
+return *vqp; // expected-error {{invalid use of PPC MMA type}}
+  }
+
+  const vq_t *testVQRet5(int *ptr) {
+__vector_quad *vqp = (__vector_quad *)ptr;
+vq1 = *vqp;
+return vqp + 2;
+  }
+
+  // template argument
+  template 
+  void testVQTemplate(T v, T *p) { // expected-note {{candidate template ignored: substitution failure [with T = __vector_quad]: invalid use of PPC MMA type}} \
+ expected-note {{candidate template ignored: substitution failure [with T = __vector_quad]: invalid use of PPC MMA type}}
+*(p + 1) = v;
+  }
+
+  // class field
+public:
+  __vector_quad vq1; // expected-error {{invalid use of PPC MMA type}}
+  __vector_quad *vqp1;
+
+private:
+  vq_t vq2; // expected-error {{invalid use of PPC MMA type}}
+  vq_t *vqp2;
+};
+
+// template
+template 
+class ClassTemplateVQ1 {
+  T t; // expected-error {{invalid use of PPC MMA type}}
+};
+template 
+class ClassTemplateVQ2 {
+  T *t;
+};
+template 
+class ClassTemplateVQ3 {
+  int foo(T t) { return 10; }
+};
+template 
+class ClassTemplateVQ4 {
+public:
+  T operator()(Ts...) const {} // expected-error {{invalid use of PPC MMA type}}
+};
+void testVQTemplate() {
+  ClassTemplateVQ1<__vector_quad> t1; // expected-note {{in instantiation of template class 'ClassTemplateVQ1<__vector_quad>' requested here}}
+  ClassTemplateVQ1<__vector_quad *> t2;
+  ClassTemplateVQ2<__vector_quad> t3;
+  ClassTemplateVQ2<__vector_quad *> t4;
+
+  ClassTemplateVQ3 t5;
+  // The following case is not prevented but it ok, this function type cannot be
+  // instantiated because we prevent any function from returning an MMA type.
+  ClassTemplateVQ3<__vector_quad(int, int, int)> t6;
+  ClassTemplateVQ3 t7; // expected-error {{invalid use of PPC MMA type}}
+
+  ClassTemplateVQ4 t8; // expected-note {{in instantiation of template class 'ClassTemplateVQ4' requested here}}
+  ClassTemplateVQ4 t9;
+
+  TestClassVQ tc;
+  __vector_quad vq;
+  __vector_quad *vqp = &vq;
+  tc.testVQTemplate(&vq, &vqp);
+  tc.testVQTemplate(&vq, &vqp);

[PATCH] D89986: [AIX] do not emit visibility attribute into IR when there is -mignore-xcoff-visibility

2020-10-27 Thread Sean Fertile via Phabricator via cfe-commits
sfertile added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:520
   Options.DataSections = CodeGenOpts.DataSections;
-  Options.IgnoreXCOFFVisibility = CodeGenOpts.IgnoreXCOFFVisibility;
   Options.UniqueSectionNames = CodeGenOpts.UniqueSectionNames;

DiggerLin wrote:
> sfertile wrote:
> > DiggerLin wrote:
> > > jasonliu wrote:
> > > > DiggerLin wrote:
> > > > > DiggerLin wrote:
> > > > > > jasonliu wrote:
> > > > > > > DiggerLin wrote:
> > > > > > > > jasonliu wrote:
> > > > > > > > > DiggerLin wrote:
> > > > > > > > > > jasonliu wrote:
> > > > > > > > > > > Instead of just removing this line, should this get 
> > > > > > > > > > > replaced with the new LangOpts option?
> > > > > > > > > > I do not think we need a CodeGenOp of 
> > > > > > > > > > ignore-xcoff-visibility in clang, we only need the LangOpt 
> > > > > > > > > > of the ignore-xcoff-visilbity to control whether we will  
> > > > > > > > > > generate the visibility in the IR,  when the LangOpt of 
> > > > > > > > > > ignore-xcoff-visibility do not generate the visibility 
> > > > > > > > > > attribute of GV in the IR. it do not need CodeGenOp of 
> > > > > > > > > > ignore-xcoff-visibility any more for the clang .
> > > > > > > > > > 
> > > > > > > > > > we have still CodeGen ignore-xcoff-visibility op in  llc.
> > > > > > > > > We removed the visibility from IR level with this patch. But 
> > > > > > > > > there is also visibility settings coming from CodeGen part of 
> > > > > > > > > clang, which needs to get ignore when we are doing the code 
> > > > > > > > > gen in llc. So I think you still need to set the options 
> > > > > > > > > correct for llc.
> > > > > > > > yes we have the set the options correct for llc in the code.
> > > > > > > > 
> > > > > > > > in the source file llvm/lib/CodeGen/CommandFlags.cpp, we have 
> > > > > > > > (in the patch https://reviews.llvm.org/D87451 add new option 
> > > > > > > > -mignore-xcoff-visibility) , the function
> > > > > > > > TargetOptions codegen::InitTargetOptionsFromCodeGenFlags() {
> > > > > > > > 
> > > > > > > > Options.IgnoreXCOFFVisibility = getIgnoreXCOFFVisibility(); 
> > > > > > > > ...}
> > > > > > > > 
> > > > > > > What I'm saying is... 
> > > > > > > I think we need a line like this:
> > > > > > > `Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;`
> > > > > > > so that when you invoke clang, backend would get the correct 
> > > > > > > setting as well. 
> > > > > > I do not think so, from the clang FE, we do not generated the 
> > > > > > visibility in the IR. so there is no need these line.
> > > > > or we can say that because we do not set the hidden visibility into 
> > > > > the GlobalValue , so we do not need the 
> > > > > Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;
> > > > I think I mentioned this before, we could have extra visibility 
> > > > settings in clang/lib/CodeGen that's not depending on the existing 
> > > > visibility setting in the IR. (You could search for `setVisibility` 
> > > > there.) That was the reason we did it in llc first. 
> > > I will add Options.IgnoreXCOFFVisibility = 
> > > LangOpts.IgnoreXCOFFVisibility;  here.
> > > I think I mentioned this before, we could have extra visibility settings 
> > > in clang/lib/CodeGen that's not depending on the existing visibility 
> > > setting in the IR. (You could search for setVisibility there.) That was 
> > > the reason we did it in llc first.
> > 
> >  A lot of these are in places we wouldn't encounter with AIX, like for 
> > Objective-C code gen. But are others like [[ 
> > https://github.com/llvm/llvm-project/blob/b03ea054db1bcf9452b3a70e21d3372b6e58759a/clang/lib/CodeGen/ItaniumCXXABI.cpp#L2507
> >  | this]]  an issue? Should they be addressed in this patch?
> after I added the Options.IgnoreXCOFFVisibility = 
> LangOpts.IgnoreXCOFFVisibility , even there is  
> GV->setVisibility(llvm::GlobalValue::HiddenVisibility);  it do not effect our 
> output.
> 
> there is following code in the function void 
> PPCAIXAsmPrinter::emitLinkage(const GlobalValue *GV,
>MCSymbol *GVSym) const
> {
>  . 
>   if (!TM.getIgnoreXCOFFVisibility()) {
> switch (GV->getVisibility()) {
> 
> // TODO: "exported" and "internal" Visibility needs to go here.
> case GlobalValue::DefaultVisibility:
>   break;
> case GlobalValue::HiddenVisibility:
>   VisibilityAttr = MAI->getHiddenVisibilityAttr();
>   break;
> case GlobalValue::ProtectedVisibility:
>   VisibilityAttr = MAI->getProtectedVisibilityAttr();
>   break;
> }
>   }
> 
> ...
> }
> it do not effect our output.
It can if we set the GlobalValue to be dso_local though ... that is the whole 
point of this patch.



Comment at: clang/test/CodeGen/aix-visibility-inlines-hidden.cpp:1
+// REQUIRES: powerpc-registered-target
+

DiggerLin wrote:
> jasonliu wrote:
> > sfertile wrote:
>

[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Michael Liao via Phabricator via cfe-commits
hliao updated this revision to Diff 301012.
hliao added a comment.

Add `amdgpu-kernel-arg-pointer-type.cu` back and revise its checks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
  clang/test/CodeGenCUDA/kernel-args.cu

Index: clang/test/CodeGenCUDA/kernel-args.cu
===
--- clang/test/CodeGenCUDA/kernel-args.cu
+++ clang/test/CodeGenCUDA/kernel-args.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=AMDGCN %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda- -fcuda-is-device \
 // RUN: -emit-llvm %s -o - | FileCheck -check-prefix=NVPTX %s
@@ -6,17 +6,18 @@
 
 struct A {
   int a[32];
+  float *p;
 };
 
-// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 4 %x)
+// AMDGCN: define amdgpu_kernel void @_Z6kernel1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+// NVPTX: define void @_Z6kernel1A(%struct.A* byval(%struct.A) align 8 %x)
 __global__ void kernel(A x) {
 }
 
 class Kernel {
 public:
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}})
-  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel12memberKernelE1A(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}})
+  // NVPTX: define void @_ZN6Kernel12memberKernelE1A(%struct.A* byval(%struct.A) align 8 %x)
   static __global__ void memberKernel(A x){}
   template static __global__ void templateMemberKernel(T x) {}
 };
@@ -29,11 +30,11 @@
 
 void test() {
   Kernel K;
-  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_Z14templateKernelI1AEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_Z14templateKernelI1AEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)templateKernel);
 
-  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 4 %{{.+}}
-  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 4 %x)
+  // AMDGCN: define amdgpu_kernel void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A addrspace(4)* byref(%struct.A) align 8 %{{.+}}
+  // NVPTX: define void @_ZN6Kernel20templateMemberKernelI1AEEvT_(%struct.A* byval(%struct.A) align 8 %x)
   launch((void*)Kernel::templateMemberKernel);
 }
Index: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
@@ -9,32 +9,26 @@
 
 // Coerced struct from `struct S` without all generic pointers lowered into
 // global ones.
-// COMMON: %struct.S.coerce = type { i32 addrspace(1)*, float addrspace(1)* }
-// COMMON: %struct.T.coerce = type { [2 x float addrspace(1)*] }
 
 // On the host-side compilation, generic pointer won't be coerced.
 // HOST-NOT: %struct.S.coerce
 // HOST-NOT: %struct.T.coerce
 
 // HOST: define void @_Z22__device_stub__kernel1Pi(i32* %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel1Pi(i32 addrspace(1)*{{.*}} %x.coerce)
-// CHECK: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// CHECK-NOT: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// OPT: [[VAL:%.*]] = load i32, i32 addrspace(1)* %x.coerce, align 4
+// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel1Pi(i32*{{.*}} %x)
+// OPT: [[VAL:%.*]] = load i32, i32* %x, align 4
 // OPT: [[INC:%.*]] = add nsw i32 [[VAL]], 1
-// OPT: store i32 [[INC]], i32 addrspace(1)* %x.coerce, align 4
+// OPT: store i32 [[INC]], i32* %x, align 4
 // OPT: ret void
 __global__ void kernel1(int *x) {
   x[0]++;
 }
 
 // HOST: define void @_Z22__device_stub__kernel2Ri(i32* nonnull align 4 dereferenceable(4) %x)
-// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel2Ri(i32 addrspace(1)*{{.*}} nonnull align 4 dereferenceable(4) %x.coerce)
-// CHECK: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// CHECK-NOT: = addrspacecast [[TYPE:.*]] addrspace(1)* %{{.*}} to [[TYPE]]*
-// OPT: [[VAL:%.*]] = load i32, i32 addrspace(1)* %x.coerce, align 4
+// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel2Ri(i32*{{.*}} nonnull align 4 deref

[PATCH] D88553: [clangd] Start using SyntaxTrees for folding ranges feature

2020-10-27 Thread Kirill Bobyrev 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 rG5ad6bbacf091: [clangd] Start using SyntaxTrees for folding 
ranges feature (authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88553

Files:
  clang-tools-extra/clangd/SemanticSelection.cpp
  clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -271,29 +271,29 @@
 #endif
 }
 
-syntax::Leaf *syntax::Tree::findFirstLeaf() {
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findFirstLeaf() const {
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   return L;
-if (auto *L = cast(C)->findFirstLeaf())
+if (const auto *L = cast(C)->findFirstLeaf())
   return L;
   }
   return nullptr;
 }
 
-syntax::Leaf *syntax::Tree::findLastLeaf() {
-  syntax::Leaf *Last = nullptr;
-  for (auto *C = getFirstChild(); C; C = C->getNextSibling()) {
-if (auto *L = dyn_cast(C))
+const syntax::Leaf *syntax::Tree::findLastLeaf() const {
+  const syntax::Leaf *Last = nullptr;
+  for (const auto *C = getFirstChild(); C; C = C->getNextSibling()) {
+if (const auto *L = dyn_cast(C))
   Last = L;
-else if (auto *L = cast(C)->findLastLeaf())
+else if (const auto *L = cast(C)->findLastLeaf())
   Last = L;
   }
   return Last;
 }
 
-syntax::Node *syntax::Tree::findChild(NodeRole R) {
-  for (auto *C = FirstChild; C; C = C->getNextSibling()) {
+const syntax::Node *syntax::Tree::findChild(NodeRole R) const {
+  for (const auto *C = FirstChild; C; C = C->getNextSibling()) {
 if (C->getRole() == R)
   return C;
   }
Index: clang/include/clang/Tooling/Syntax/Tree.h
===
--- clang/include/clang/Tooling/Syntax/Tree.h
+++ clang/include/clang/Tooling/Syntax/Tree.h
@@ -168,20 +168,24 @@
   Node *getFirstChild() { return FirstChild; }
   const Node *getFirstChild() const { return FirstChild; }
 
-  Leaf *findFirstLeaf();
-  const Leaf *findFirstLeaf() const {
-return const_cast(this)->findFirstLeaf();
+  const Leaf *findFirstLeaf() const;
+  Leaf *findFirstLeaf() {
+return const_cast(const_cast(this)->findFirstLeaf());
   }
 
-  Leaf *findLastLeaf();
-  const Leaf *findLastLeaf() const {
-return const_cast(this)->findLastLeaf();
+  const Leaf *findLastLeaf() const;
+  Leaf *findLastLeaf() {
+return const_cast(const_cast(this)->findLastLeaf());
+  }
+
+  /// Find the first node with a corresponding role.
+  const Node *findChild(NodeRole R) const;
+  Node *findChild(NodeRole R) {
+return const_cast(const_cast(this)->findChild(R));
   }
 
 protected:
   using Node::Node;
-  /// Find the first node with a corresponding role.
-  Node *findChild(NodeRole R);
 
 private:
   /// Prepend \p Child to the list of children and and sets the parent pointer.
Index: clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
@@ -203,26 +203,61 @@
 TEST(FoldingRanges, All) {
   const char *Tests[] = {
   R"cpp(
-[[int global_variable]];
+#define FOO int foo() {\
+  int Variable = 42; \
+}
 
-[[void func() {
-  int v = 100;
-}]]
+// Do not generate folding range for braces within macro expansion.
+FOO
+
+// Do not generate folding range within macro arguments.
+#define FUNCTOR(functor) functor
+void func() {[[
+  FUNCTOR([](){});
+]]}
+
+// Do not generate folding range with a brace coming from macro.
+#define LBRACE {
+void bar() LBRACE
+  int X = 42;
+}
+  )cpp",
+  R"cpp(
+void func() {[[
+  int Variable = 100;
+
+  if (Variable > 5) {[[
+Variable += 42;
+  ]]} else if (Variable++)
+++Variable;
+  else {[[
+Variable--;
+  ]]}
+
+  // Do not generate FoldingRange for empty CompoundStmts.
+  for (;;) {}
+
+  // If there are newlines between {}, we should generate one.
+  for (;;) {[[
+
+  ]]}
+]]}
   )cpp",
   R"cpp(
-[[class Foo {
+class Foo {
 public:
-  [[Foo() {
+  Foo() {[[
 int X = 1;
-  }]]
+  ]]}
 
 pri

[clang-tools-extra] 5ad6bba - [clangd] Start using SyntaxTrees for folding ranges feature

2020-10-27 Thread Kirill Bobyrev via cfe-commits

Author: Kirill Bobyrev
Date: 2020-10-27T16:47:35+01:00
New Revision: 5ad6bbacf091c90d47730bf284f4893eb1afb1ee

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

LOG: [clangd] Start using SyntaxTrees for folding ranges feature

This is an initial attempt to start using Syntax Trees in clangd while 
improving state of folding ranges feature and experimenting with Syntax Tree 
capabilities.

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/SemanticSelection.cpp
clang-tools-extra/clangd/unittests/SemanticSelectionTests.cpp
clang/include/clang/Tooling/Syntax/Tree.h
clang/lib/Tooling/Syntax/Tree.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/SemanticSelection.cpp 
b/clang-tools-extra/clangd/SemanticSelection.cpp
index cfce1520cd08..b855d7b63435 100644
--- a/clang-tools-extra/clangd/SemanticSelection.cpp
+++ b/clang-tools-extra/clangd/SemanticSelection.cpp
@@ -5,6 +5,7 @@
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
+
 #include "SemanticSelection.h"
 #include "FindSymbols.h"
 #include "ParsedAST.h"
@@ -13,8 +14,16 @@
 #include "SourceCode.h"
 #include "clang/AST/DeclBase.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
+#include "clang/Tooling/Syntax/BuildTree.h"
+#include "clang/Tooling/Syntax/Nodes.h"
+#include "clang/Tooling/Syntax/Tree.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/Support/Error.h"
+#include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -28,17 +37,65 @@ void addIfDistinct(const Range &R, std::vector 
&Result) {
   }
 }
 
-// Recursively collects FoldingRange from a symbol and its children.
-void collectFoldingRanges(DocumentSymbol Symbol,
-  std::vector &Result) {
+llvm::Optional toFoldingRange(SourceRange SR,
+const SourceManager &SM) {
+  const auto Begin = SM.getDecomposedLoc(SR.getBegin()),
+ End = SM.getDecomposedLoc(SR.getEnd());
+  // Do not produce folding ranges if either range ends is not within the main
+  // file. Macros have their own FileID so this also checks if locations are 
not
+  // within the macros.
+  if ((Begin.first != SM.getMainFileID()) || (End.first != SM.getMainFileID()))
+return llvm::None;
   FoldingRange Range;
-  Range.startLine = Symbol.range.start.line;
-  Range.startCharacter = Symbol.range.start.character;
-  Range.endLine = Symbol.range.end.line;
-  Range.endCharacter = Symbol.range.end.character;
-  Result.push_back(Range);
-  for (const auto &Child : Symbol.children)
-collectFoldingRanges(Child, Result);
+  Range.startCharacter = SM.getColumnNumber(Begin.first, Begin.second) - 1;
+  Range.startLine = SM.getLineNumber(Begin.first, Begin.second) - 1;
+  Range.endCharacter = SM.getColumnNumber(End.first, End.second) - 1;
+  Range.endLine = SM.getLineNumber(End.first, End.second) - 1;
+  return Range;
+}
+
+llvm::Optional extractFoldingRange(const syntax::Node *Node,
+ const SourceManager &SM) {
+  if (const auto *Stmt = dyn_cast(Node)) {
+const auto *LBrace = cast_or_null(
+Stmt->findChild(syntax::NodeRole::OpenParen));
+// FIXME(kirillbobyrev): This should find the last child. Compound
+// statements have only one pair of braces so this is valid but for other
+// node kinds it might not be correct.
+const auto *RBrace = cast_or_null(
+Stmt->findChild(syntax::NodeRole::CloseParen));
+if (!LBrace || !RBrace)
+  return llvm::None;
+// Fold the entire range within braces, including whitespace.
+const SourceLocation LBraceLocInfo = LBrace->getToken()->endLocation(),
+ RBraceLocInfo = RBrace->getToken()->location();
+auto Range = toFoldingRange(SourceRange(LBraceLocInfo, RBraceLocInfo), SM);
+// Do not generate folding range for compound statements without any
+// nodes and newlines.
+if (Range && Range->startLine != Range->endLine)
+  return Range;
+  }
+  return llvm::None;
+}
+
+// Traverse the tree and collect folding ranges along the way.
+std::vector collectFoldingRanges(const syntax::Node *Root,
+   const SourceManager &SM) {
+  std::queue Nodes;
+  Nodes.push(Root);
+  std::vector Result;
+  while (!Nodes.empty()) {
+const syntax::Node *Node = Nodes.front();
+Nodes.pop();
+const auto Range = extractFoldingRange(Node, SM);
+if (Range)
+  Result.push_back(*Range);
+if (const auto *T = dyn_cast(Node))
+  for (const

[PATCH] D89986: [AIX] do not emit visibility attribute into IR when there is -mignore-xcoff-visibility

2020-10-27 Thread Digger via Phabricator via cfe-commits
DiggerLin marked an inline comment as done.
DiggerLin added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:520
   Options.DataSections = CodeGenOpts.DataSections;
-  Options.IgnoreXCOFFVisibility = CodeGenOpts.IgnoreXCOFFVisibility;
   Options.UniqueSectionNames = CodeGenOpts.UniqueSectionNames;

sfertile wrote:
> DiggerLin wrote:
> > sfertile wrote:
> > > DiggerLin wrote:
> > > > jasonliu wrote:
> > > > > DiggerLin wrote:
> > > > > > DiggerLin wrote:
> > > > > > > jasonliu wrote:
> > > > > > > > DiggerLin wrote:
> > > > > > > > > jasonliu wrote:
> > > > > > > > > > DiggerLin wrote:
> > > > > > > > > > > jasonliu wrote:
> > > > > > > > > > > > Instead of just removing this line, should this get 
> > > > > > > > > > > > replaced with the new LangOpts option?
> > > > > > > > > > > I do not think we need a CodeGenOp of 
> > > > > > > > > > > ignore-xcoff-visibility in clang, we only need the 
> > > > > > > > > > > LangOpt of the ignore-xcoff-visilbity to control whether 
> > > > > > > > > > > we will  generate the visibility in the IR,  when the 
> > > > > > > > > > > LangOpt of ignore-xcoff-visibility do not generate the 
> > > > > > > > > > > visibility attribute of GV in the IR. it do not need 
> > > > > > > > > > > CodeGenOp of ignore-xcoff-visibility any more for the 
> > > > > > > > > > > clang .
> > > > > > > > > > > 
> > > > > > > > > > > we have still CodeGen ignore-xcoff-visibility op in  llc.
> > > > > > > > > > We removed the visibility from IR level with this patch. 
> > > > > > > > > > But there is also visibility settings coming from CodeGen 
> > > > > > > > > > part of clang, which needs to get ignore when we are doing 
> > > > > > > > > > the code gen in llc. So I think you still need to set the 
> > > > > > > > > > options correct for llc.
> > > > > > > > > yes we have the set the options correct for llc in the code.
> > > > > > > > > 
> > > > > > > > > in the source file llvm/lib/CodeGen/CommandFlags.cpp, we have 
> > > > > > > > > (in the patch https://reviews.llvm.org/D87451 add new option 
> > > > > > > > > -mignore-xcoff-visibility) , the function
> > > > > > > > > TargetOptions codegen::InitTargetOptionsFromCodeGenFlags() {
> > > > > > > > > 
> > > > > > > > > Options.IgnoreXCOFFVisibility = getIgnoreXCOFFVisibility(); 
> > > > > > > > > ...}
> > > > > > > > > 
> > > > > > > > What I'm saying is... 
> > > > > > > > I think we need a line like this:
> > > > > > > > `Options.IgnoreXCOFFVisibility = 
> > > > > > > > LangOpts.IgnoreXCOFFVisibility;`
> > > > > > > > so that when you invoke clang, backend would get the correct 
> > > > > > > > setting as well. 
> > > > > > > I do not think so, from the clang FE, we do not generated the 
> > > > > > > visibility in the IR. so there is no need these line.
> > > > > > or we can say that because we do not set the hidden visibility into 
> > > > > > the GlobalValue , so we do not need the 
> > > > > > Options.IgnoreXCOFFVisibility = LangOpts.IgnoreXCOFFVisibility;
> > > > > I think I mentioned this before, we could have extra visibility 
> > > > > settings in clang/lib/CodeGen that's not depending on the existing 
> > > > > visibility setting in the IR. (You could search for `setVisibility` 
> > > > > there.) That was the reason we did it in llc first. 
> > > > I will add Options.IgnoreXCOFFVisibility = 
> > > > LangOpts.IgnoreXCOFFVisibility;  here.
> > > > I think I mentioned this before, we could have extra visibility 
> > > > settings in clang/lib/CodeGen that's not depending on the existing 
> > > > visibility setting in the IR. (You could search for setVisibility 
> > > > there.) That was the reason we did it in llc first.
> > > 
> > >  A lot of these are in places we wouldn't encounter with AIX, like for 
> > > Objective-C code gen. But are others like [[ 
> > > https://github.com/llvm/llvm-project/blob/b03ea054db1bcf9452b3a70e21d3372b6e58759a/clang/lib/CodeGen/ItaniumCXXABI.cpp#L2507
> > >  | this]]  an issue? Should they be addressed in this patch?
> > after I added the Options.IgnoreXCOFFVisibility = 
> > LangOpts.IgnoreXCOFFVisibility , even there is  
> > GV->setVisibility(llvm::GlobalValue::HiddenVisibility);  it do not effect 
> > our output.
> > 
> > there is following code in the function void 
> > PPCAIXAsmPrinter::emitLinkage(const GlobalValue *GV,
> >MCSymbol *GVSym) const
> > {
> >  . 
> >   if (!TM.getIgnoreXCOFFVisibility()) {
> > switch (GV->getVisibility()) {
> > 
> > // TODO: "exported" and "internal" Visibility needs to go here.
> > case GlobalValue::DefaultVisibility:
> >   break;
> > case GlobalValue::HiddenVisibility:
> >   VisibilityAttr = MAI->getHiddenVisibilityAttr();
> >   break;
> > case GlobalValue::ProtectedVisibility:
> >   VisibilityAttr = MAI->getProtectedVisibilityAttr();
> >   break;
> > }
> >   }
> > 
> > ...
> > }
> > it do not effect our output.
> It can if we set t

[PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend

2020-10-27 Thread dmajor via Phabricator via cfe-commits
dmajor added a comment.

After this commit our bots have a failure on the wasm target, could you please 
take a look?

test.c:

  double a, b;
  c() {
  #pragma STDC FENV_ACCESS ON
b == a;
  }

Run `clang -cc1 -triple wasm32-unknown-wasi -emit-obj test.c` (clang needs to 
be build with `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`)

Result:

  clang: 
/home/vm/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3764: 
bool (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode *): 
Assertion `!IsStrict && "Don't know how to expand for strict nodes."' failed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87528

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


[PATCH] D90161: [SyntaxTree] Provide iterators for Lists

2020-10-27 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas marked 8 inline comments as done.
eduucaldas added a comment.

I left some points unanswered, I'll answer them tomorrow :)




Comment at: clang/include/clang/Tooling/Syntax/Tree.h:231
+  /// `ElementAndDelimiter` acts as one.
+  template  class ElementAndDelimiterIterator {
+  public:

sammccall wrote:
> sammccall wrote:
> > sammccall wrote:
> > > this name is bulky and hard to read, leads to more unwieldy names later 
> > > (e.g. `getElementAndDelimiterBeforeBegin` which despite its length is 
> > > unclear that it's even an iterator).
> > > 
> > > Would there be actual confusion in calling this `ElementIterator`, and 
> > > providing the associated delimiters in addition to the elements?
> > overall, this design seems to be focused on the size being a single 
> > pointer, at the cost of complexity of most of the operations.
> > 
> > Why is this important to optimize for, compared to doing something like:
> > ```
> > private:
> >   Node *Elt, *Delim, *Next;
> >   void advance() {
> > // read one element
> > // set Elt and/or Delim
> > // always advances Next by at least one
> >   }
> > public:
> >   Iterator(Node *Start) : Elt(nullptr), Delim(nullptr), Next(Start) {}
> >   operator++() { advance(); }
> >   Leaf *getDelimiter() { return Delim; }
> >   Node *getElement() { return Elt; }
> > ```
> > 
> > (Performance isn't the biggest concern here, but I'd usually expect two 
> > extra pointers on the stack to be preferable to all the branches in the 
> > current impl)
> how sure are we that the template and strong typing is worthwhile on the 
> iterators? Can we try without it for a while and see how painful it is?
> how sure are we that the template and strong typing is worthwhile on the 
> iterators? Can we try without it for a while and see how painful it is?
It avoids duplication of code on derived classes - `CallArguments`, 
`ParameterDeclarationList` I suggest that we try to simplify other things 
and then rediscuss this point.  

1. BeforeBegin.
2. Trying to fit everything into a pointer. 
3. Templates and strong typing.



Comment at: clang/include/clang/Tooling/Syntax/Tree.h:231
+  /// `ElementAndDelimiter` acts as one.
+  template  class ElementAndDelimiterIterator {
+  public:

eduucaldas wrote:
> sammccall wrote:
> > sammccall wrote:
> > > sammccall wrote:
> > > > this name is bulky and hard to read, leads to more unwieldy names later 
> > > > (e.g. `getElementAndDelimiterBeforeBegin` which despite its length is 
> > > > unclear that it's even an iterator).
> > > > 
> > > > Would there be actual confusion in calling this `ElementIterator`, and 
> > > > providing the associated delimiters in addition to the elements?
> > > overall, this design seems to be focused on the size being a single 
> > > pointer, at the cost of complexity of most of the operations.
> > > 
> > > Why is this important to optimize for, compared to doing something like:
> > > ```
> > > private:
> > >   Node *Elt, *Delim, *Next;
> > >   void advance() {
> > > // read one element
> > > // set Elt and/or Delim
> > > // always advances Next by at least one
> > >   }
> > > public:
> > >   Iterator(Node *Start) : Elt(nullptr), Delim(nullptr), Next(Start) {}
> > >   operator++() { advance(); }
> > >   Leaf *getDelimiter() { return Delim; }
> > >   Node *getElement() { return Elt; }
> > > ```
> > > 
> > > (Performance isn't the biggest concern here, but I'd usually expect two 
> > > extra pointers on the stack to be preferable to all the branches in the 
> > > current impl)
> > how sure are we that the template and strong typing is worthwhile on the 
> > iterators? Can we try without it for a while and see how painful it is?
> > how sure are we that the template and strong typing is worthwhile on the 
> > iterators? Can we try without it for a while and see how painful it is?
> It avoids duplication of code on derived classes - `CallArguments`, 
> `ParameterDeclarationList` I suggest that we try to simplify other things 
> and then rediscuss this point.  
> 
> 1. BeforeBegin.
> 2. Trying to fit everything into a pointer. 
> 3. Templates and strong typing.
> Would there be actual confusion in calling this ElementIterator, and 
> providing the associated delimiters in addition to the elements?

This is a very interesting proposition! And it brought some interesting ideas. 
We'll further develop on them and answer to this inline tomorrow :) 



Comment at: clang/include/clang/Tooling/Syntax/Tree.h:235
+  switch (getKind()) {
+  case IteratorKind::BeforeBegin: {
+if (auto *Begin = getParent()->getFirstChild())

sammccall wrote:
> Are the before-begin iterators needed immediately?
> 
> My understanding is that before-begin iterators are used with nodes due to 
> the single-linked-list implementation, but that's going away. Can we avoid 
> adding more of these by sequencing those chang

[PATCH] D89986: [AIX] do not emit visibility attribute into IR when there is -mignore-xcoff-visibility

2020-10-27 Thread Digger via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 301020.
DiggerLin marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89986

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/lib/AST/Decl.cpp
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
  clang/test/CodeGen/aix-visibility-inlines-hidden.cpp

Index: clang/test/CodeGen/aix-visibility-inlines-hidden.cpp
===
--- /dev/null
+++ clang/test/CodeGen/aix-visibility-inlines-hidden.cpp
@@ -0,0 +1,39 @@
+// REQUIRES: powerpc-registered-target
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large \
+// RUN:-fvisibility-inlines-hidden -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -fvisibility-inlines-hidden \
+// RUN:-fvisibility default -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY-IR %s
+
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -mcmodel=large -mignore-xcoff-visibility -emit-llvm \
+// RUN:-fvisibility-inlines-hidden -fvisibility default -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
+
+int x = 66;
+__attribute__((__noinline__)) inline void f() {
+  x = 55;
+}
+
+#pragma GCC visibility push(hidden)
+__attribute__((__noinline__)) inline void foo() {
+  x = 55;
+}
+#pragma GCC visibility pop
+
+int bar() {
+  f();
+  foo();
+  return x;
+}
+
+// VISIBILITY-IR: define linkonce_odr hidden void @_Z1fv()
+// NOVISIBILITY-IR:   define linkonce_odr void @_Z1fv()
+
+// VISIBILITY-IR: define linkonce_odr hidden void @_Z3foov()
+// NOVISIBILITY-IR:   define linkonce_odr void @_Z3foov()
Index: clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
===
--- clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
+++ clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
@@ -1,24 +1,10 @@
 // REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -o - -x c++ -S  %s  |\
-// RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
 
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=IGNOREVISIBILITY-ASM %s
-
-// RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -o - -x c++ -S %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-ASM %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -emit-llvm -o - -x c++ %s  | \
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
 
 // RUN: %clang_cc1 -triple powerpc-unknown-aix -mignore-xcoff-visibility -fvisibility default -emit-llvm -o - -x c++ %s  | \
-// RUN: FileCheck -check-prefix=VISIBILITY-IR %s
+// RUN: FileCheck -check-prefix=NOVISIBILITY-IR %s
 
 // RUN: %clang_cc1 -triple powerpc-unknown-aix -fvisibility default -emit-llvm -o - -x c++ %s  | \
 // RUN: FileCheck -check-prefix=VISIBILITY-IR %s
@@ -70,28 +56,11 @@
 // VISIBILITY-IR:define weak_odr protected i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
 // VISIBILITY-IR:define hidden void @_Z7prambarv()
 
-// VISIBILITY-ASM: .globl  _Z5foo_hPi[DS],hidden
-// VISIBILITY-ASM: .globl  ._Z5foo_hPi,hidden
-// VISIBILITY-ASM: .globl  _Z3barv[DS],protected
-// VISIBILITY-ASM: .globl  ._Z3barv,protected
-// VISIBILITY-ASM: .weak   _ZNK9TestClass5valueEv[DS],hidden
-// VISIBILITY-ASM: .weak   ._ZNK9TestClass5valueEv,hidden
-// VISIBILITY-ASM: .weak   _ZN5basicIiE7getdataEv[DS],protected
-// VISIBILITY-ASM: .weak   ._ZN5basicIiE7getdataEv,protected
-// VISIBILITY-ASM: .globl  _Z7prambarv[DS],hidden
-// VISIBILITY-ASM: .globl  ._Z7prambarv,hidden
-// VISIBILITY-ASM: .globl  b,protected
-// VISIBILITY-ASM: .globl  pramb,hidden
-
-// IGNOREVISIBILITY-ASM: .globl  _Z5foo_hPi[DS]
-// IGNOREVISIBILITY-ASM: .globl  ._Z5foo_hPi
-// IGNOREVISIBILITY-ASM: .globl  _Z3barv[DS]
-// IGNOREVISIBILITY-ASM: .globl  ._Z3barv
-// IGNOREVISIBILITY-ASM: .weak   _ZNK9TestClass5valueEv[DS]
-// IGNOREVISIBILITY-ASM: .weak   ._ZNK9TestClass5valueEv
-// IGNOREVISIBILITY-ASM: .weak   _ZN5basic

[PATCH] D90240: [SyntaxTree] Add reverse links to syntax Nodes.

2020-10-27 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/include/clang/Tooling/Syntax/Tree.h:189
   /// EXPECTS: Child->Role != Detached
   void prependChildLowLevel(Node *Child);
   friend class TreeBuilder;

eduucaldas wrote:
> Should we provide an `appendChildLowLevel` as well?
> 
> That has one use inside `foldChildren` in `BuildTree.cpp`. 
> Currently this function does a reverse iteration prepending children. We 
> could change that into a forward iteration appending. There is no impact in 
> time-complexity. This change would just improve readability inside this 
> function.
There is some awkwardness in foldChildren because we can only go in reverse -- 
maybe append is indeed more natural.



Comment at: clang/lib/Tooling/Syntax/Tree.cpp:102
 
 void syntax::Tree::replaceChildRangeLowLevel(Node *BeforeBegin, Node *End,
  Node *New) {

Do you plan to remove BeforeBegin argument (in a follow-up if you prefer, but 
you could also change it here)



Comment at: clang/lib/Tooling/Syntax/Tree.cpp:262
+;
+  assert(Last == T->getLastChild() &&
+ "Last child is reachable by advancing from the first child.");

I think you could fold this check into the for loop below.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90240

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


[PATCH] D90161: [SyntaxTree] Provide iterators for Lists

2020-10-27 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 301024.
eduucaldas marked 6 inline comments as done.
eduucaldas added a comment.

- `const` on `getElement` and similar.
- `NotSentinel` -> `Element`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90161

Files:
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Tree.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -11,6 +11,7 @@
 #include "clang/Tooling/Syntax/BuildTree.h"
 #include "clang/Tooling/Syntax/Nodes.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/Support/raw_ostream.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
@@ -125,7 +126,7 @@
 }
 
 class ListTest : public SyntaxTreeTest {
-private:
+protected:
   std::string dumpQuotedTokensOrNull(const Node *N) {
 return N ? "'" +
StringRef(N->dumpTokens(Arena->getSourceManager()))
@@ -135,7 +136,15 @@
  : "null";
   }
 
-protected:
+  std::string
+  dumpElementAndDelimiter(const List::ElementAndDelimiter ED) {
+std::string Storage;
+llvm::raw_string_ostream OS(Storage);
+OS << "(" << dumpQuotedTokensOrNull(ED.element) << ", "
+   << dumpQuotedTokensOrNull(ED.delimiter) << ")";
+return OS.str();
+  }
+
   std::string
   dumpElementsAndDelimiters(ArrayRef> EDs) {
 std::string Storage;
@@ -145,8 +154,7 @@
 
 llvm::interleaveComma(
 EDs, OS, [&OS, this](const List::ElementAndDelimiter &ED) {
-  OS << "(" << dumpQuotedTokensOrNull(ED.element) << ", "
- << dumpQuotedTokensOrNull(ED.delimiter) << ")";
+  OS << dumpElementAndDelimiter(ED);
 });
 
 OS << "]";
@@ -351,4 +359,143 @@
   EXPECT_EQ(dumpNodes(List->getElementsAsNodes()), "['a', 'b', 'c']");
 }
 
+TEST_P(ListTest, List_Terminated_Iterator_Parent) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  buildTree("", GetParam());
+
+  // "a   b::  :: c"
+  auto *List = dyn_cast(syntax::createTree(
+  *Arena,
+  {
+  {createLeaf(*Arena, tok::identifier, "a"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::identifier, "b"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::coloncolon), NodeRole::ListDelimiter},
+  {createLeaf(*Arena, tok::coloncolon), NodeRole::ListDelimiter},
+  {createLeaf(*Arena, tok::identifier, "c"), NodeRole::ListElement},
+  },
+  NodeKind::NestedNameSpecifier));
+
+  EXPECT_EQ(List->getElementsAsNodesAndDelimitersBeforeBegin().getParent(),
+List);
+
+  for (auto It = List->getElementsAsNodesAndDelimitersBegin(),
+End = List->getElementsAsNodesAndDelimitersEnd();
+   It != End; ++It)
+EXPECT_EQ(It.getParent(), List);
+
+  EXPECT_EQ(List->getElementsAsNodesAndDelimitersEnd().getParent(), List);
+}
+
+TEST_P(ListTest, List_Terminated_Iterator_Equality) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  buildTree("", GetParam());
+
+  // "a   b::  :: c"
+  auto *List = dyn_cast(syntax::createTree(
+  *Arena,
+  {
+  {createLeaf(*Arena, tok::identifier, "a"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::identifier, "b"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::coloncolon), NodeRole::ListDelimiter},
+  {createLeaf(*Arena, tok::coloncolon), NodeRole::ListDelimiter},
+  {createLeaf(*Arena, tok::identifier, "c"), NodeRole::ListElement},
+  },
+  NodeKind::NestedNameSpecifier));
+
+  // different iterators are different.
+  for (auto BeforeIt = List->getElementsAsNodesAndDelimitersBeforeBegin(),
+End = List->getElementsAsNodesAndDelimitersEnd();
+   BeforeIt != End; ++BeforeIt) {
+auto It = BeforeIt;
+++It;
+for (; It != End; ++It) {
+  EXPECT_NE(BeforeIt, It);
+}
+  }
+
+  // Equal iterators are equal.
+  for (auto It = List->getElementsAsNodesAndDelimitersBegin(),
+It2 = List->getElementsAsNodesAndDelimitersBegin(),
+End = List->getElementsAsNodesAndDelimitersEnd();
+   It != End && It2 != End;) {
+EXPECT_EQ(++It, ++It2);
+  }
+
+  // Different sentinel iterators are different.
+  EXPECT_NE(List->getElementsAsNodesAndDelimitersBeforeBegin(),
+List->getElementsAsNodesAndDelimitersEnd());
+}
+
+TEST_P(ListTest, List_Separated_Iterator_Parent) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  buildTree("", GetParam());
+
+  // "a  b,  ,"
+  auto *List = dyn_cast(syntax::createTree(
+  *Arena,
+  {
+  {createLeaf(*Arena, tok::identifier, "a"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::identifier, "b"), NodeRole::ListElement},
+  {createLeaf(*Arena, tok::comma), NodeRole::ListDelimiter},
+

[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

2020-10-27 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith requested changes to this revision.
dexonsmith added a comment.
This revision now requires changes to proceed.

I like how this is coming together. I have a few comments inline.

Also, I wonder if there should be a test for the new OptParser behaviour in 
`llvm/unittests/Option/`.




Comment at: clang/include/clang/Driver/Options.td:1176
+defm reciprocal_math : OptInFFlag< "reciprocal-math", "Allow division 
operations to be reassociated", "", "", [], "LangOpts->AllowRecip">;
+def fapprox_func : Flag<["-"], "fapprox-func">, Group, 
Flags<[CC1Option, NoDriverOption]>,
+  MarshallingInfoFlag<"LangOpts->ApproxFunc", "false">;

dang wrote:
> Anastasia wrote:
> > could this also be OptInFFlag?
> The aim was to keep the driver semantics the same as before and this was not 
> something you could control with the driver, so I left it as just a CC1 flag. 
> However if it makes sense to be able to control this from the driver then we 
> can definitely make this `OptInFFLag`.
I think adding a driver flag (if that's the right thing to do) should be done 
separately in a follow-up commit.

Also for a separate commit: it would be a great improvement if you could have 
OptIn / OptOut flags that were `-cc1`-only (maybe `CC1OptInFFlag`).
- Both `-fX` and `-fno-X` would be parsed by `-cc1` (and cancel each other out).
- Only the non-default one would be generated when serializing to `-cc1` from 
`CompilerInvocation` (for `OptIn`, we'd never generate `-fno-X`).
- Neither would be recognized by the driver.

I suggest we might want that for most `-cc11` flags. This would make it easier 
to poke through the driver with `-Xclang` to override `-cc1` options the driver 
adds. Not something we want for end-users, but useful for debugging the 
compiler itself. Currently the workflow is to run the driver with `-###`, 
copy/paste, search for and remove the option you want to skip, and finally run 
the `-cc1` command...

The reason I bring it up is that it's possible people will start using 
`OptInFFLag` just in order to get this behaviour, not because they intend to 
add a driver flag.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3707
 #undef OPTION_WITH_MARSHALLING_FLAG
+
   return true;

I don't have an opinion about whether there should be a newline here, but 
please make unrelated whitespace changes like this in a separate commit 
(before/after).



Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:460-464
+if (AID < BID)
+  return -1;
+if (AID > BID)
+  return 1;
+return 0;

I think `array_pod_sort` will use this like a `bool`, similar to `std::sort`, 
in which case you I think you want:
```
  return (*A)->getID() < (*B)->getID();
```



Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:468-469
+  // Restore the definition order of marshalling options.
+  array_pod_sort(OptsWithMarshalling.begin(), OptsWithMarshalling.end(),
+ CmpMarshallingOpts);
+

I'm curious if this is necessary. If so, how do the options get out-of-order?

Also, a cleaner way to call `array_pod_sort` would be:
```
llvm::sort(OptsWithMarshalling, CmpMarshallingOpts);
```
and I would be tempted to define the lambda inline in the call to `llvm::sort`.

If it's not necessary, I suggest replacing with an assertion:
```
assert(llvm::is_sorted(OptsWithMarshalling, ...));
```


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

https://reviews.llvm.org/D82756

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


[PATCH] D89980: [hip] Remove kernel argument coercion.

2020-10-27 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu:19
+// COMMON-LABEL: define amdgpu_kernel void @_Z7kernel1Pi(i32*{{.*}} %x)
+// OPT: [[VAL:%.*]] = load i32, i32* %x, align 4
 // OPT: [[INC:%.*]] = add nsw i32 [[VAL]], 1

This is still a regression. Fixing up AA does not solve the problem this 
promotions this is intended to solve. Generic accesses are worse independently 
of the aliasing properties


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89980

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


RE: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend

2020-10-27 Thread Blower, Melanie I via cfe-commits
Thank you.  I don't know the solution but I can remove the assert and create a 
bug report to have it resolved.

> -Original Message-
> From: dmajor via Phabricator 
> Sent: Tuesday, October 27, 2020 11:58 AM
> To: Blower, Melanie I ; sepavl...@gmail.com;
> rjmcc...@gmail.com; rich...@metafoo.co.uk; aaron.ball...@gmail.com
> Cc: dma...@mozilla.com; dexonsm...@apple.com; sca...@apple.com;
> kevin.n...@sas.com; cfe-commits@lists.llvm.org; mlek...@skidmore.edu;
> blitzrak...@gmail.com; shen...@google.com; paul.robin...@sony.com
> Subject: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend
> 
> dmajor added a comment.
> 
> After this commit our bots have a failure on the wasm target, could you please
> take a look?
> 
> test.c:
> 
>   double a, b;
>   c() {
>   #pragma STDC FENV_ACCESS ON
> b == a;
>   }
> 
> Run `clang -cc1 -triple wasm32-unknown-wasi -emit-obj test.c` (clang needs to
> be build with `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`)
> 
> Result:
> 
>   clang: /home/vm/src/llvm-
> project/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3764: bool
> (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode *):
> Assertion `!IsStrict && "Don't know how to expand for strict nodes."' failed.
> 
> 
> Repository:
>   rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D87528/new/
> 
> https://reviews.llvm.org/D87528

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


  1   2   3   >