[PATCH] D63518: BitStream reader: propagate errors

[Alex Brachet via Phabricator via cfe-commits]

abrachet added inline comments.



Comment at: llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp:205
+  return MaybeBitCode.takeError();
+switch (unsigned BitCode = MaybeBitCode.get()) {
 default: // Default behavior: reject

This and an identical switch on line 5367 cause an unused variable warning from 
this commit. I don't know if the build bots report on this, or the proper way 
to tell you about this but hopefully you will see it :)


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63518



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

[PATCH] D63048: Update __VERSION__ to remove the hardcoded 4.2.1 version

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru added a comment.

@rnk how do you feel about removing both? I can take care of that if you want


Repository:
  rC Clang

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

https://reviews.llvm.org/D63048



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 206792.
jvikstrom added a comment.
Herald added a subscriber: jfb.

Moved semantic highlighting to be processed in onMainAST


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
  clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -36,6 +36,10 @@
 class IgnoreDiagnostics : public DiagnosticsConsumer {
   void onDiagnosticsReady(PathRef File,
   std::vector Diagnostics) override {}
+
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
 };
 
 MATCHER_P2(FileRange, File, Range, "") {
Index: clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
===
--- clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -677,6 +677,9 @@
   AllStatus.push_back(Status);
 }
 
+virtual void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {}
+
 std::vector allStatus() {
   std::lock_guard Lock(Mutex);
   return AllStatus;
Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -29,6 +29,9 @@
 class IgnoreDiagnostics : public DiagnosticsConsumer {
   void onDiagnosticsReady(PathRef File,
   std::vector Diagnostics) override {}
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
 };
 
 // GMock helpers for matching SymbolInfos items.
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -45,6 +45,9 @@
 class IgnoreDiagnostics : public DiagnosticsConsumer {
   void onDiagnosticsReady(PathRef File,
   std::vector Diagnostics) override {}
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
 };
 
 // GMock helpers for matching completion items.
Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -73,6 +73,10 @@
 return HadErrorInLastDiags;
   }
 
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
+
 private:
   std::mutex Mutex;
   bool HadErrorInLastDiags = false;
@@ -101,6 +105,10 @@
 return Result;
   }
 
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
+
   void clear() {
 std::lock_guard Lock(Mutex);
 LastDiagsHadError.clear();
@@ -279,6 +287,9 @@
 std::vector Diagnostics) override {
   Got = Context::current().getExisting(Secret);
 }
+  virtual void
+  onHighlightingsReady(PathRef File,
+std::vector Highlightings) override {}
 int Got;
   } DiagConsumer;
   MockCompilationDatabase CDB;
@@ -610,6 +621,10 @@
   Stats[FileIndex].HadErrorsInLastDiags = HadError;
 }
 
+virtual void
+onHighlightingsReady(PathRef File,
+  std::vector Highlightings) override {}
+
 std::vector takeFileStats() {
   std::lock_guard Lock(Mutex);
   return std::move(Stats);
@@ -845,6 +860,7 @@
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
 std::atomic Count = {0};
+std::atomic HighlightingCount = {0};
 
 NoConcurrentAccessDiagConsumer(std::promise StartSecondReparse)
 : StartSecondReparse(std::move(StartSecondReparse)) {}
@@ -865,6 +881,11 @@
   }
 }
 
+virtual void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++HighlightingCo

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/ClangdServer.h:60
+  // Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void onHighlightingsReady(PathRef File,
+ std::vector Highlightings) 
= 0;

hokein wrote:
> we may add this interface to the existing `DiagnosticsConsumer`.
Probably want to rename `DiagnosticsConsumer` as well, can't come up with a 
good name though. Any suggestions? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Nikolai Kosjar via Phabricator via cfe-commits]

nik added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.h:60
+  // Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void onHighlightingsReady(PathRef File,
+ std::vector Highlightings) 
= 0;

jvikstrom wrote:
> hokein wrote:
> > we may add this interface to the existing `DiagnosticsConsumer`.
> Probably want to rename `DiagnosticsConsumer` as well, can't come up with a 
> good name though. Any suggestions? 
One could summarize diagnostics and highlightings as annotations, so maybe 
FileAnnotationsConsumer or DocumentAnnotationsConsumer? Not sure how 
onFileUpdated() fits into this...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

thanks, it is much clearer now.

Could you please make the commit message be more specific what this patch does? 
C++ APIs is too generous, (we already have C++ APIs and data structures for 
semantic highlightings which are in `SemanticHighlighting.h`).




Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void onHighlightingsReady(PathRef File,
+ std::vector Highlightings) 
override;
 

clang-format: intention is not correct.



Comment at: clang-tools-extra/clangd/ClangdServer.h:60
+  // Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void onHighlightingsReady(PathRef File,
+ std::vector Highlightings) 
= 0;

nik wrote:
> jvikstrom wrote:
> > hokein wrote:
> > > we may add this interface to the existing `DiagnosticsConsumer`.
> > Probably want to rename `DiagnosticsConsumer` as well, can't come up with a 
> > good name though. Any suggestions? 
> One could summarize diagnostics and highlightings as annotations, so maybe 
> FileAnnotationsConsumer or DocumentAnnotationsConsumer? Not sure how 
> onFileUpdated() fits into this...
There is a FIXME on Line 43. I'd keep it unchanged now (I don't have a good 
name either).



Comment at: clang-tools-extra/clangd/ClangdServer.h:54
+
+  // Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void onHighlightingsReady(PathRef File,

nit: triple `/` here.



Comment at: clang-tools-extra/clangd/ClangdServer.h:56
+  virtual void onHighlightingsReady(PathRef File,
+ std::vector Highlightings) 
= 0;
 };

just provide an empty implementation (like `onFileUpdated`), and you don't need 
to update all the subclasses.



Comment at: clang-tools-extra/clangd/ClangdServer.h:140
+
+// If true Clangd will generate semantic highlightings for the current
+// document when it changes.

just: `Enable semantic highlighting features`, and name it `bool 
SemanticHighlighting`.



Comment at: clang-tools-extra/clangd/ClangdServer.h:160
   /// synchronize access to shared state.
+  /// If semantic highlighting is enabled ClangdServer also generates semantic
+  /// highlightings for the file after each parsing request. When highlightings

not sure whether we need this comment, because the intention is not obvious in 
code here (the flag is hidden in Opts), it might be more sensible to move it to 
`Options::SemanticHighlighting`.

And the comment is not precise in the new code now (we collect the highlighting 
tokens in the DiagConsumer now).



Comment at: clang-tools-extra/clangd/ClangdServer.h:320
+  
+  // If this is true semantic highlighting will be generated.
+  bool SemanticHighlightingEnabled = false;

We don't need to store it as a class member, we only pass this value to 
`ParsingCallBack` in the constructor.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.h:35
+// scopes.
+std::map>
+getSemanticHighlightingScopes();

I think it is unrelated to this patch, we should include this when we 
implements the LSP part.



Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:863
 std::atomic Count = {0};
+std::atomic HighlightingCount = {0};
 

We should keep the test isolated, this test is for diagnostics, please add a 
new `TEST_F` for merely testing the highlightings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D60499: [ASTImporter] Various source location and range import fixes.

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

balazske added a comment.

Ping


Repository:
  rC Clang

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

https://reviews.llvm.org/D60499



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

[clang-tools-extra] r364519 - [clangd] Address limitations in SelectionTree:

[Sam McCall via cfe-commits]

Author: sammccall
Date: Thu Jun 27 04:17:13 2019
New Revision: 364519

URL: http://llvm.org/viewvc/llvm-project?rev=364519&view=rev
Log:
[clangd] Address limitations in SelectionTree:

Summary:
 - nodes can have special-cased hit ranges including "holes" (FunctionTypeLoc 
in void foo())
 - token conflicts between siblings (int a,b;) are resolved in favor of left 
sibling
 - parent/child overlap is handled statefully rather than explicitly by 
comparing parent/child
   ranges (this lets us share a mechanism with sibling conflicts)

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/Selection.cpp
clang-tools-extra/trunk/clangd/unittests/SelectionTests.cpp

Modified: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=364519&r1=364518&r2=364519&view=diff
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (original)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Thu Jun 27 04:17:13 2019
@@ -8,7 +8,12 @@
 
 #include "Selection.h"
 #include "ClangdUnit.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/PrettyPrinter.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/TypeLoc.h"
+#include "llvm/ADT/STLExtras.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -16,6 +21,41 @@ namespace {
 using Node = SelectionTree::Node;
 using ast_type_traits::DynTypedNode;
 
+// Stores a collection of (possibly-overlapping) integer ranges.
+// When new ranges are added, hit-tests them against existing ones.
+class RangeSet {
+public:
+  // Returns true if any new offsets are covered.
+  // This is naive (linear in number of successful add() calls), but ok for 
now.
+  bool add(unsigned Begin, unsigned End) {
+assert(std::is_sorted(Ranges.begin(), Ranges.end()));
+assert(Begin < End);
+
+if (covered(Begin, End))
+  return false;
+auto Pair = std::make_pair(Begin, End);
+Ranges.insert(llvm::upper_bound(Ranges, Pair), Pair);
+return true;
+  }
+
+private:
+  bool covered(unsigned Begin, unsigned End) {
+assert(Begin < End);
+for (const auto &R : Ranges) {
+  if (Begin < R.first)
+return false; // The prefix [Begin, R.first) is not covered.
+  if (Begin < R.second) {
+Begin = R.second; // Prefix is covered, truncate the range.
+if (Begin >= End)
+  return true;
+  }
+}
+return false;
+  }
+
+  std::vector> Ranges; // Always sorted.
+};
+
 // We find the selection by visiting written nodes in the AST, looking for 
nodes
 // that intersect with the selected character range.
 //
@@ -86,6 +126,7 @@ public:
 
 private:
   using Base = RecursiveASTVisitor;
+
   SelectionVisitor(ASTContext &AST, unsigned SelBegin, unsigned SelEnd,
FileID SelFile)
   : SM(AST.getSourceManager()), LangOpts(AST.getLangOpts()),
@@ -112,6 +153,31 @@ private:
 return Ret;
   }
 
+  // HIT TESTING
+  //
+  // We do rough hit testing on the way down the tree to avoid traversing
+  // subtrees that don't touch the selection (canSafelySkipNode), but
+  // fine-grained hit-testing is mostly done on the way back up (in pop()).
+  // This means children get to claim parts of the selection first, and parents
+  // are only selected if they own tokens that no child owned.
+  //
+  // Nodes *usually* nest nicely: a child's getSourceRange() lies within the
+  // parent's, and a node (transitively) owns all tokens in its range.
+  //
+  // Exception 1: child range claims tokens that should be owned by the parent.
+  //  e.g. in `void foo(int);`, the FunctionTypeLoc should own
+  //  `void (int)` but the parent FunctionDecl should own `foo`.
+  // To handle this case, certain nodes claim small token ranges *before*
+  // their children are traversed. (see earlySourceRange).
+  //
+  // Exception 2: siblings both claim the same node.
+  //  e.g. `int x, y;` produces two sibling VarDecls.
+  //~ x
+  // y
+  // Here the first ("leftmost") sibling claims the tokens it wants, and the
+  // other sibling gets what's left. So selecting "int" only includes the left
+  // VarDecl in the selection tree.
+
   // An optimization for a common case: nodes outside macro expansions that
   // don't intersect the selection may be recursively skipped.
   bool canSafelySkipNode(SourceRange S) {
@@ -123,18 +189,24 @@ private:
   }
 
   // Pushes a node onto the ancestor stack. Pairs with pop().
+  // Performs early hit detection for some nodes (on the earlySourceRange).
   void push(DynTypedNode Node) {
+bool SelectedEarly = claimRange(earlySourceRange(Node));
 Nodes.emplace_back();
 Nodes.back().ASTNode = std::move(Node);
  

[PATCH] D63760: [clangd] Address limitations in SelectionTree:

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
sammccall marked 4 inline comments as done.
Closed by commit rL364519: [clangd] Address limitations in SelectionTree: 
(authored by sammccall, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63760?vs=206531&id=206823#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63760

Files:
  clang-tools-extra/trunk/clangd/Selection.cpp
  clang-tools-extra/trunk/clangd/unittests/SelectionTests.cpp

Index: clang-tools-extra/trunk/clangd/Selection.cpp
===
--- clang-tools-extra/trunk/clangd/Selection.cpp
+++ clang-tools-extra/trunk/clangd/Selection.cpp
@@ -8,7 +8,12 @@
 
 #include "Selection.h"
 #include "ClangdUnit.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/PrettyPrinter.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/TypeLoc.h"
+#include "llvm/ADT/STLExtras.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -16,6 +21,41 @@
 using Node = SelectionTree::Node;
 using ast_type_traits::DynTypedNode;
 
+// Stores a collection of (possibly-overlapping) integer ranges.
+// When new ranges are added, hit-tests them against existing ones.
+class RangeSet {
+public:
+  // Returns true if any new offsets are covered.
+  // This is naive (linear in number of successful add() calls), but ok for now.
+  bool add(unsigned Begin, unsigned End) {
+assert(std::is_sorted(Ranges.begin(), Ranges.end()));
+assert(Begin < End);
+
+if (covered(Begin, End))
+  return false;
+auto Pair = std::make_pair(Begin, End);
+Ranges.insert(llvm::upper_bound(Ranges, Pair), Pair);
+return true;
+  }
+
+private:
+  bool covered(unsigned Begin, unsigned End) {
+assert(Begin < End);
+for (const auto &R : Ranges) {
+  if (Begin < R.first)
+return false; // The prefix [Begin, R.first) is not covered.
+  if (Begin < R.second) {
+Begin = R.second; // Prefix is covered, truncate the range.
+if (Begin >= End)
+  return true;
+  }
+}
+return false;
+  }
+
+  std::vector> Ranges; // Always sorted.
+};
+
 // We find the selection by visiting written nodes in the AST, looking for nodes
 // that intersect with the selected character range.
 //
@@ -86,6 +126,7 @@
 
 private:
   using Base = RecursiveASTVisitor;
+
   SelectionVisitor(ASTContext &AST, unsigned SelBegin, unsigned SelEnd,
FileID SelFile)
   : SM(AST.getSourceManager()), LangOpts(AST.getLangOpts()),
@@ -112,6 +153,31 @@
 return Ret;
   }
 
+  // HIT TESTING
+  //
+  // We do rough hit testing on the way down the tree to avoid traversing
+  // subtrees that don't touch the selection (canSafelySkipNode), but
+  // fine-grained hit-testing is mostly done on the way back up (in pop()).
+  // This means children get to claim parts of the selection first, and parents
+  // are only selected if they own tokens that no child owned.
+  //
+  // Nodes *usually* nest nicely: a child's getSourceRange() lies within the
+  // parent's, and a node (transitively) owns all tokens in its range.
+  //
+  // Exception 1: child range claims tokens that should be owned by the parent.
+  //  e.g. in `void foo(int);`, the FunctionTypeLoc should own
+  //  `void (int)` but the parent FunctionDecl should own `foo`.
+  // To handle this case, certain nodes claim small token ranges *before*
+  // their children are traversed. (see earlySourceRange).
+  //
+  // Exception 2: siblings both claim the same node.
+  //  e.g. `int x, y;` produces two sibling VarDecls.
+  //~ x
+  // y
+  // Here the first ("leftmost") sibling claims the tokens it wants, and the
+  // other sibling gets what's left. So selecting "int" only includes the left
+  // VarDecl in the selection tree.
+
   // An optimization for a common case: nodes outside macro expansions that
   // don't intersect the selection may be recursively skipped.
   bool canSafelySkipNode(SourceRange S) {
@@ -123,18 +189,24 @@
   }
 
   // Pushes a node onto the ancestor stack. Pairs with pop().
+  // Performs early hit detection for some nodes (on the earlySourceRange).
   void push(DynTypedNode Node) {
+bool SelectedEarly = claimRange(earlySourceRange(Node));
 Nodes.emplace_back();
 Nodes.back().ASTNode = std::move(Node);
 Nodes.back().Parent = Stack.top();
-Nodes.back().Selected = SelectionTree::Unselected;
+// Early hit detection never selects the whole node.
+Nodes.back().Selected =
+SelectedEarly ? SelectionTree::Partial : SelectionTree::Unselected;
 Stack.push(&Nodes.back());
   }
 
   // Pops a node off the ancestor stack, and finalizes it. Pairs with push().
+  // Performs primary hit detection.
   vo

[PATCH] D63845: [WIP] Create a clang attribute that lets users specify LLVM attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

In D63845#1559995 , @lebedev.ri wrote:

> What's the target use-case here? What can't be solved with normal attributes?
>  I wonder if this should go to cfe+llvm -dev lists first, it's kinda 
> intrusive.
>  I also wonder if all these should cause a clang diagnostic, at least under 
> `-Wall`.
>  How is versioning expected to be handled? New attribute vs old clang, and 
> vice versa.


Also, we already have the `annotate` attribute for passing information through 
to LLVM. Why do we need four different ways to do this?




Comment at: clang/include/clang/Basic/Attr.td:1638
+def LLVMFN : InheritableAttr {
+  let Spellings = [GCC<"LLVMFN">];
+  let Args = [StringArgument<"AttrName">];

This is not a GCC attribute, so this needs a different spelling. Also, the 
all-caps names are a bit obnoxious, so we may want to pick a different name.

Do you envision these being attributes users will write in production code? 
What kind of guarantees do they have about the stability of the attribute 
interfaces that LLVM provides? For instance, are we promising that LLVM 
attributes will remain backwards compatible (e.g., won't be removed or renamed)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63845



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 206832.
jvikstrom marked 9 inline comments as done.
jvikstrom added a comment.

Separated test and gave consumer an empty definition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -841,6 +841,56 @@
   EXPECT_FALSE(PathResult.hasValue());
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+HighlightingsCounterDiagConsumer(std::promise StartSecondReparse)
+: StartSecondReparse(std::move(StartSecondReparse)) {}
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+
+virtual void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+  if (FirstRequest) {
+FirstRequest = false;
+StartSecondReparse.set_value();
+  }
+}
+
+  private:
+std::mutex Mutex;
+bool FirstRequest = true;
+std::promise StartSecondReparse;
+  };
+
+  const auto SourceContents1 = R"cpp(
+int a;
+)cpp";
+
+  const auto SourceContents2 = R"cpp(
+int a = ;
+)cpp";
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  std::promise StartSecondPromise;
+  std::future StartSecond = StartSecondPromise.get_future();
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer(std::move(StartSecondPromise));
+  ClangdServer Server(MCD, FS, DiagConsumer,
+  ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, SourceContents1);
+  StartSecond.wait();
+  Server.addDocument(FooCpp, SourceContents2);
+  ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
+  ASSERT_EQ(DiagConsumer.Count, 2);
+}
+
 TEST_F(ClangdThreadingTest, NoConcurrentDiagnostics) {
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus &Status){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer)
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext &Ctx,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST &AST) override {
 if (FIndex)
   FIndex-

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In terms of the code, I think this is ready to go. However, I'm still not happy 
with `'*' in boolean context` as a diagnostic. Perhaps appending something 
about the resulting value always being true|false would help most of these 
diagnostics be more obvious. `blah in boolean context will always evaluate to 
true|false` optionally followed by `; did you mean yada?` would make it more 
obvious what is wrong with the code.

Also, I'm not certain why this should be enabled by default when the other 
tautological comparison categories are not. I think it should follow the rest 
of the tautological comparisons in that regard, but I also would have expected 
those to be on by default. @rsmith, what are your opinions here?




Comment at: include/clang/Basic/DiagnosticGroups.td:767
 def IncompatibleExceptionSpec : DiagGroup<"incompatible-exception-spec">;
-
 def IntToVoidPointerCast : DiagGroup<"int-to-void-pointer-cast">;

Spurious change.


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

https://reviews.llvm.org/D63082



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay, ilya-biryukov.
Herald added a project: clang.

Failing case:

  #include "foo.h"
  void fo^o() {}

getRenameDecl() returns the decl of the symbol under the cursor (which is
in the current main file), instead, we use the canonical decl to determine
whether a symbol is declared in #included header.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63872

Files:
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -78,7 +78,6 @@
   for (const Test &T : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =
 renameWithinFile(AST, testPath(TU.Filename), Code.point(), "abcde");
@@ -92,58 +91,68 @@
 }
 
 TEST(RenameTest, Renameable) {
-  // Test cases where the symbol is declared in header.
   struct Case {
-const char* HeaderCode;
+const char *Code;
 const char* ErrorMessage; // null if no error
+bool IsHeaderFile;
   };
+  const bool HeaderFile = true;
   Case Cases[] = {
   {R"cpp(// allow -- function-local
 void f(int [[Lo^cal]]) {
   [[Local]] = 2;
 }
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// allow -- symbol is indexable and has no refs in index.
 void [[On^lyInThisFile]]();
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// disallow -- symbol is indexable and has other refs in index.
 void f() {
   Out^side s;
 }
   )cpp",
-   "used outside main file"},
+   "used outside main file", HeaderFile},
 
   {R"cpp(// disallow -- symbol is not indexable.
 namespace {
 class Unin^dexable {};
 }
   )cpp",
-   "not eligible for indexing"},
+   "not eligible for indexing", HeaderFile},
 
   {R"cpp(// disallow -- namespace symbol isn't supported
 namespace fo^o {}
   )cpp",
-   "not a supported kind"},
+   "not a supported kind", HeaderFile},
+
+  {R"cpp(// foo is declared outside the file.
+void fo^o() {}
+  )cpp", "used outside main file", !HeaderFile/*cc file*/},
   };
-  const char *CommonHeader = "class Outside {};";
-  TestTU OtherFile = TestTU::withCode("Outside s;");
+  const char *CommonHeader = R"cpp(
+class Outside {};
+void foo();
+  )cpp";
+  TestTU OtherFile = TestTU::withCode("Outside s; auto ss = &foo;");
   OtherFile.HeaderCode = CommonHeader;
   OtherFile.Filename = "other.cc";
-  // The index has a "Outside" reference.
+  // The index has a "Outside" reference and a "foo" reference.
   auto OtherFileIndex = OtherFile.index();
 
   for (const auto& Case : Cases) {
-Annotations T(Case.HeaderCode);
-// We open the .h file as the main file.
+Annotations T(Case.Code);
 TestTU TU = TestTU::withCode(T.code());
-TU.Filename = "test.h";
 TU.HeaderCode = CommonHeader;
-// Parsing the .h file as C++ include.
-TU.ExtraArgs.push_back("-xobjective-c++-header");
+if (Case.IsHeaderFile) {
+  // We open the .h file as the main file.
+  TU.Filename = "test.h";
+  // Parsing the .h file as C++ include.
+  TU.ExtraArgs.push_back("-xobjective-c++-header");
+}
 auto AST = TU.build();
 
 auto Results = renameWithinFile(AST, testPath(TU.Filename), T.point(),
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -154,6 +154,7 @@
 
   const auto *RenameDecl = Rename->getRenameDecl();
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {
 auto Message = [](ReasonToReject Reason) {
   switch (Reason) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62960: SVE opaque type for C intrinsics demo

[Diana Picus via Phabricator via cfe-commits]

rovka added a comment.

Just a few nits/suggestions.




Comment at: include/clang/Basic/AArch64SVEACLETypes.def:10
+//
+//  This file defines the database about various builtin singleton types.
+//

You can be more specific :)



Comment at: include/clang/Basic/AArch64SVEACLETypes.def:29
+#define SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP)\
+  BUILTIN_TYPE(Name, Id, SingletonId)
+#endif

Maybe use SVE_TYPE instead of BUILTIN_TYPE, to avoid any confusion?  You can't 
re-use a defition of BUILTIN_TYPE between this header and BuiltinTypes.def 
anyway, since they both undefine it at the end.



Comment at: include/clang/Serialization/ASTBitCodes.h:1021
 #include "clang/Basic/OpenCLExtensionTypes.def"
+// SVE Types
+#define SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP)\

super nit: /// \brief SVE types with auto numeration



Comment at: lib/AST/ASTContext.cpp:6645
+  case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(KIND, ID)

Here and in most other places: no need for 2 defines, you can just #define 
BUILTIN_TYPE (or if you choose to rename it to SVE_TYPE) since it's the same 
code for both vectors and predicates.



Comment at: lib/AST/ItaniumMangle.cpp:2680
+break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

erik.pilkington wrote:
> rsandifo-arm wrote:
> > erik.pilkington wrote:
> > > jfb wrote:
> > > > @rjmccall you probably should review this part.
> > > Sorry for the drive by comment, but: All of these mangling should really 
> > > be using the "vendor extension" production IMO:
> > > 
> > > ` ::= u `
> > > 
> > > As is, these manglings intrude on the users's namespace, (i.e. if they 
> > > had a type named `objc_selector` or something), and confuse demanglers 
> > > which incorrectly assume these are substitutable (vendor extension 
> > > builtin types are substitutable too though, but that should be handled 
> > > here).
> > It isn't obvious from the patch, but the SVE names that we're mangling are 
> > predefined names like __SVInt8_t. rather than user-facing names like 
> > svint8_t  The predefined names and their mangling are defined by the 
> > platform ABI (https://developer.arm.com/docs/100986/), so it wouldn't 
> > be valid for another part of the implementation to use those names for 
> > something else.
> > 
> > I realise you were making a general point here though, sorry.
> > 
> The mangling in the document you linked does use the vendor extension 
> production here though, i.e. the example is `void f(int8x8_t)`, which mangles 
> to _Z1f**u10__Int8x8_t**. It is true that this shouldn't ever collide with 
> another mangling in practice, but my point is there isn't any need to smuggle 
> it into the mangling by pretending it's a user defined type, when the itanium 
> grammar and related tools have a special way for vendors to add builtin types.
I agree with Erik here, the example in the PCS document seems to suggest using 
u. I think either the patch needs to be updated or the document needs to be 
more clear about what the mangling is supposed to look like.



Comment at: lib/AST/MicrosoftMangle.cpp:2110
+llvm_unreachable("mangling an sve type not yet supported");
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

Should we have llvm_unreachable or report a proper error? I like the 
unreachable if we're checking elsewhere that SVE isn't supported on Windows, 
but I notice we report errors for some of the other types.



Comment at: lib/CodeGen/CGDebugInfo.cpp:709
+  case BuiltinType::Id: \
+return nullptr;
+#include "clang/Basic/AArch64SVEACLETypes.def"

I don't really know this code, but I can't help but notice that nullptr is only 
ever used for the void type. Is it safe to also use it for the SVE types, or 
can we do something else instead?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62960



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

[PATCH] D63276: [AST] Add FunctionDecl::getParametersSourceRange()

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Decl.h:2331
+  /// Attempt to compute an informative source range covering the
+  /// function parameters. This omits the ellipsis of a variadic function.
+  SourceRange getParametersSourceRange() const;

nicolas wrote:
> aaron.ballman wrote:
> > Why does this omit the ellipsis? It's part of the parameter list and it 
> > seems like a strange design decision to leave that out of the source range 
> > for the parameter list.
> I haven't found a correct way to access the position of the ellipsis. There 
> is no corresponding `ParmVarDecl` in `ParamInfo`.
> Did I miss something? It doesn't seem to be easily accessible.
I don't think you've missed anything; I think we need to track/dig out that 
information in order for this API to be usefully correct. I don't see a lot of 
value in getting a source range that's sometimes wrong.

I would recommend seeing if you can go back to the function type location 
information as-needed to figure out where the ellipsis is and include it in the 
range here.



Comment at: clang/unittests/AST/SourceLocationTest.cpp:676
+}
+
 TEST(CXXMethodDecl, CXXMethodDeclWithThrowSpecification) {

nicolas wrote:
> aaron.ballman wrote:
> > I'd like to see tests that include an ellipsis, as well as tests that use 
> > the preprocessor in creative ways. e.g.,
> > ```
> > #define FOO  int a, int b
> > 
> > void func(FOO);
> > void bar(float f, FOO, float g);
> > void baz(FOO, float f);
> > void quux(float f, FOO);
> > ```
> > Also, tests for member functions (both static and instance functions) and 
> > parameters with leading attributes would be useful. e.g.,
> > ```
> > void func([[]] int *i);
> > ```
> Source locations with macros always looked inconsistent to me. For example:
> ```
> #define RET int
> RET f(void);
> ```
> 
> Here, `getReturnTypeSourceRange` returns ` -input.cc:2:1 >`, where I 
> would expect (and I could be wrong) ` -input.cc:2:3 >`
> 
> The same thing happens with `getParametersSourceRange`. Should I test the 
> current behavior?
> 
> I added the other tests you requested.
I'd test current behavior.


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

https://reviews.llvm.org/D63276



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

[PATCH] D63874: [clangd] No need to setTraversalScope in SemanticHighlighting.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: jvikstrom.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay, ilya-biryukov.
Herald added a project: clang.

We have already set it when the AST is being built, and setting TraversalScope
is not free (it will clear the cache, which is expensive to build).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63874

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h


Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ 
-*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ 
-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST &AST) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 


Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 //===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ -*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST &AST) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

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

xbolva00 added a comment.

I wanted to follow GCC’s behaviour -Wall but then dicussion moved to 
“tautological compare group” - I was fine with that too..
I can again revert it to -Wall...
If this should be off by default even on -Wall, then all work was useless..


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

https://reviews.llvm.org/D63082



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:157
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {

This cast isn't safe. I can't remember the exact case, but if you really need a 
NamedDecl you need to decide what to do if the canonical one isn't.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872



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

[PATCH] D63874: [clangd] No need to setTraversalScope in SemanticHighlighting.

[Johan Vikström via Phabricator via cfe-commits]

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

lgtm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63874



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

[clang-tools-extra] r364528 - [clangd] No need to setTraversalScope in SemanticHighlighting.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Thu Jun 27 05:22:18 2019
New Revision: 364528

URL: http://llvm.org/viewvc/llvm-project?rev=364528&view=rev
Log:
[clangd] No need to setTraversalScope in SemanticHighlighting.

Summary:
We have already set it when the AST is being built, and setting TraversalScope
is not free (it will clear the cache, which is expensive to build).

Reviewers: jvikstrom

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
clang-tools-extra/trunk/clangd/SemanticHighlighting.h

Modified: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp?rev=364528&r1=364527&r2=364528&view=diff
==
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp (original)
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp Thu Jun 27 05:22:18 
2019
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ 
-*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ 
-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@ bool operator==(const HighlightingToken
 }
 
 std::vector getSemanticHighlightings(ParsedAST &AST) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 

Modified: clang-tools-extra/trunk/clangd/SemanticHighlighting.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/SemanticHighlighting.h?rev=364528&r1=364527&r2=364528&view=diff
==
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.h (original)
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.h Thu Jun 27 05:22:18 
2019
@@ -6,8 +6,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 


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

[PATCH] D63874: [clangd] No need to setTraversalScope in SemanticHighlighting.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364528: [clangd] No need to setTraversalScope in 
SemanticHighlighting. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63874?vs=206834&id=206835#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63874

Files:
  clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
  clang-tools-extra/trunk/clangd/SemanticHighlighting.h


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.h
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ 
-*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ 
-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST &AST) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.h
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 //===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ -*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST &AST) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

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

xbolva00 added a comment.

“Perhaps appending something about the resulting value always being true|false 
would help most of these diagnostics be more obvious”

I dont know, this could only diagnose constant multiplications (maybe this is 
already handled by some “always true” check). Anyway, I have no motivation to 
diagnose constant muls, sorry. My goal is to make this warning atleast as good 
as GCC’s implementation.

Okay, we could make it better and append “; did you mean “index * 3 != 0”?


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

https://reviews.llvm.org/D63082



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

nit: you can remove this override, since we have provided an empty default 
implementation.



Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:881
+
+  std::promise StartSecondPromise;
+  std::future StartSecond = StartSecondPromise.get_future();

Looks like the current test could be simplified, I think we want to test that 
when the AST is build/rebuild, we will emit the highlighting tokens. 
Just use `Count` and check the count is to 1?

```
Server.addDocument(FooCpp, "int a;");
ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
ASSERT_EQ(DiagConsumer.Count, 1);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63559: [clangd] Added functionality for getting semantic highlights for variable and function declarations

[Haojian Wu via Phabricator via cfe-commits]

hokein closed this revision.
hokein added a comment.

the patch was landed in rL364421 , not sure 
why it was not associated with this review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63559



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

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

xbolva00 added a comment.

Alternative “* in boolean context; did you mean to compare it?”


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

https://reviews.llvm.org/D63082



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

[clang-tools-extra] r364535 - [clang-tidy] Fix NDEBUG build [NFC]

[Mikael Holmen via cfe-commits]

Author: uabelho
Date: Thu Jun 27 05:47:57 2019
New Revision: 364535

URL: http://llvm.org/viewvc/llvm-project?rev=364535&view=rev
Log:
[clang-tidy] Fix NDEBUG build [NFC]

Modified:
clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp?rev=364535&r1=364534&r2=364535&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp Thu 
Jun 27 05:47:57 2019
@@ -14,9 +14,11 @@ namespace tidy {
 namespace utils {
 using tooling::RewriteRule;
 
+#ifndef NDEBUG
 static bool hasExplanation(const RewriteRule::Case &C) {
   return C.Explanation != nullptr;
 }
+#endif
 
 // This constructor cannot dispatch to the simpler one (below), because, in
 // order to get meaningful results from `getLangOpts` and `Options`, we need 
the


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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 206841.
jvikstrom marked an inline comment as done.
jvikstrom added a comment.

Simplified test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -13,6 +13,7 @@
 #include "GlobalCompilationDatabase.h"
 #include "Matchers.h"
 #include "SyncAPI.h"
+#include "TUScheduler.h"
 #include "TestFS.h"
 #include "Threading.h"
 #include "URI.h"
@@ -841,6 +842,29 @@
   EXPECT_FALSE(PathResult.hasValue());
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 TEST_F(ClangdThreadingTest, NoConcurrentDiagnostics) {
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus &Status){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer)
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext &Ctx,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST &AST) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer &DiagConsumer;
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@
   // is p

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

hokein wrote:
> nit: you can remove this override, since we have provided an empty default 
> implementation.
I get an `-Winconsistent-missing-override` warnings without the override.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

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

xbolva00 updated this revision to Diff 206842.

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

https://reviews.llvm.org/D63082

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/Analysis/misc-ps.c
  test/Sema/integer-overflow.c
  test/Sema/parentheses.c
  test/Sema/parentheses.cpp
  test/Sema/warn-int-in-bool-context.c
  test/Sema/warn-unreachable.c
  test/SemaCXX/constexpr-printing.cpp
  test/SemaCXX/integer-overflow.cpp
  test/SemaCXX/nested-name-spec.cpp
  test/SemaCXX/warn-int-in-bool-context.cpp

Index: test/SemaCXX/warn-int-in-bool-context.cpp
===
--- test/SemaCXX/warn-int-in-bool-context.cpp
+++ test/SemaCXX/warn-int-in-bool-context.cpp
@@ -0,0 +1,170 @@
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wint-in-bool-context %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify %s
+
+#define ONE 1
+#define TWO 2
+
+enum answer {
+  foo,
+  bar,
+  yes,
+  no,
+  unknown,
+};
+
+enum fruit {
+  orange = -3,
+  lemon,
+  banana,
+  apple,
+};
+
+void g(bool b);
+
+template 
+void h() {}
+template 
+void h() {}
+
+bool test(int a, int b, enum answer ans, enum fruit f) {
+  bool r = TWO * 7; // expected-warning {{'*' in boolean context}}
+  r = 3 * 7;// expected-warning {{'*' in boolean context}}
+  r = a * 7;// expected-warning {{'*' in boolean context}}
+  r = a * b;// expected-warning {{'*' in boolean context}}
+  g(3 * 9); // expected-warning {{'*' in boolean context}}
+  h<3 * 9>();
+
+  r = TWO << 7; // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+
+  r = a ? ONE : TWO; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? (1) : TWO;
+  r = a ? 3 : TWO; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? -2 : 0;
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in boolean context}}
+  r = a ? 3 : ONE; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? ONE : 0;
+  r = a ? 0 : 0;
+  r = a ? ONE : 0;
+  r = a ? ONE : ONE;
+  g(a ? 3 : 9); // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+
+  r = a ? yes   // expected-warning {{enum constant in boolean context}}
+: no;   // expected-warning {{enum constant in boolean context}}
+  r = ans == yes || no; // expected-warning {{enum constant in boolean context}}
+  r = yes || ans == no; // expected-warning {{enum constant in boolean context}}
+  r = ans == yes || ans == no;
+  r = !foo;
+  r = !bar;
+  r = !yes;// expected-warning {{enum constant in boolean context}}
+  g(ans == yes || no); // expected-warning {{enum constant in boolean context}}
+
+  if (8 * 4) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (a * 4) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (-TWO * b) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (TWO << 4) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (a << TWO) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (ONE << b) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (a ? ONE : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (a ? 32 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (ans == yes || foo)
+return a;
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (ans == yes || no) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (yes || ans == no) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (r || a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (b && a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if ((a ? 7 : TWO) && b == 32) // expected-warning {{'?:' with integer constants in boolean context, the expression will always ev

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 206844.
hokein marked 2 inline comments as done.
hokein added a comment.

Address comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872

Files:
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -78,7 +78,6 @@
   for (const Test &T : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =
 renameWithinFile(AST, testPath(TU.Filename), Code.point(), "abcde");
@@ -92,58 +91,68 @@
 }
 
 TEST(RenameTest, Renameable) {
-  // Test cases where the symbol is declared in header.
   struct Case {
-const char* HeaderCode;
+const char *Code;
 const char* ErrorMessage; // null if no error
+bool IsHeaderFile;
   };
+  const bool HeaderFile = true;
   Case Cases[] = {
   {R"cpp(// allow -- function-local
 void f(int [[Lo^cal]]) {
   [[Local]] = 2;
 }
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// allow -- symbol is indexable and has no refs in index.
 void [[On^lyInThisFile]]();
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// disallow -- symbol is indexable and has other refs in index.
 void f() {
   Out^side s;
 }
   )cpp",
-   "used outside main file"},
+   "used outside main file", HeaderFile},
 
   {R"cpp(// disallow -- symbol is not indexable.
 namespace {
 class Unin^dexable {};
 }
   )cpp",
-   "not eligible for indexing"},
+   "not eligible for indexing", HeaderFile},
 
   {R"cpp(// disallow -- namespace symbol isn't supported
 namespace fo^o {}
   )cpp",
-   "not a supported kind"},
+   "not a supported kind", HeaderFile},
+
+  {R"cpp(// foo is declared outside the file.
+void fo^o() {}
+  )cpp", "used outside main file", !HeaderFile/*cc file*/},
   };
-  const char *CommonHeader = "class Outside {};";
-  TestTU OtherFile = TestTU::withCode("Outside s;");
+  const char *CommonHeader = R"cpp(
+class Outside {};
+void foo();
+  )cpp";
+  TestTU OtherFile = TestTU::withCode("Outside s; auto ss = &foo;");
   OtherFile.HeaderCode = CommonHeader;
   OtherFile.Filename = "other.cc";
-  // The index has a "Outside" reference.
+  // The index has a "Outside" reference and a "foo" reference.
   auto OtherFileIndex = OtherFile.index();
 
   for (const auto& Case : Cases) {
-Annotations T(Case.HeaderCode);
-// We open the .h file as the main file.
+Annotations T(Case.Code);
 TestTU TU = TestTU::withCode(T.code());
-TU.Filename = "test.h";
 TU.HeaderCode = CommonHeader;
-// Parsing the .h file as C++ include.
-TU.ExtraArgs.push_back("-xobjective-c++-header");
+if (Case.IsHeaderFile) {
+  // We open the .h file as the main file.
+  TU.Filename = "test.h";
+  // Parsing the .h file as C++ include.
+  TU.ExtraArgs.push_back("-xobjective-c++-header");
+}
 auto AST = TU.build();
 
 auto Results = renameWithinFile(AST, testPath(TU.Filename), T.point(),
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -67,15 +67,14 @@
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl &Decl,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl &D, StringRef MainFile,
 const SymbolIndex &Index) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID(&Decl))
+  if (auto ID = getSymbolID(&D))
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref &R) {
@@ -97,16 +96,16 @@
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl &Decl,
+llvm::Optional renamableWithinFile(const Decl &RenameDecl,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa(&Decl))
+  if (llvm::isa(&RenameDecl))
 return ReasonToReject::Unsup

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:157
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {

sammccall wrote:
> This cast isn't safe. I can't remember the exact case, but if you really need 
> a NamedDecl you need to decide what to do if the canonical one isn't.
Thanks, it is a little surprising this is not safe (I don't have a corner case 
in mind either).

The `shouldCollectSymbol` requires a NamedDecl, I think when the CanonicalDecl 
is not a NamedDecl, we think this symbol is not indexable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[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/refactor/Rename.cpp:157
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {

hokein wrote:
> sammccall wrote:
> > This cast isn't safe. I can't remember the exact case, but if you really 
> > need a NamedDecl you need to decide what to do if the canonical one isn't.
> Thanks, it is a little surprising this is not safe (I don't have a corner 
> case in mind either).
> 
> The `shouldCollectSymbol` requires a NamedDecl, I think when the 
> CanonicalDecl is not a NamedDecl, we think this symbol is not indexable.
Sounds good.

See the comment in SymbolCollector about `ObjCPropertyDecl`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

jvikstrom wrote:
> hokein wrote:
> > nit: you can remove this override, since we have provided an empty default 
> > implementation.
> I get an `-Winconsistent-missing-override` warnings without the override.
sorry for the confusion, I meant we remove `onHighlightingsReady`, not the 
`override` keyword.



Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:864
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_EQ(DiagConsumer.Count, 1);

this is not safe, we need to wait until the server finishes building AST.

add `ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server"; `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[clang-tools-extra] r364537 - [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Thu Jun 27 06:24:10 2019
New Revision: 364537

URL: http://llvm.org/viewvc/llvm-project?rev=364537&view=rev
Log:
[clangd] Fix a case where we fail to detect a header-declared symbol in rename.

Summary:
Failing case:

```
 #include "foo.h"
 void fo^o() {}
```

getRenameDecl() returns the decl of the symbol under the cursor (which is
in the current main file), instead, we use the canonical decl to determine
whether a symbol is declared in #included header.

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/refactor/Rename.cpp
clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp

Modified: clang-tools-extra/trunk/clangd/refactor/Rename.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/Rename.cpp?rev=364537&r1=364536&r2=364537&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/Rename.cpp (original)
+++ clang-tools-extra/trunk/clangd/refactor/Rename.cpp Thu Jun 27 06:24:10 2019
@@ -67,15 +67,14 @@ llvm::Optional filePath(con
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl &Decl,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl &D, StringRef MainFile,
 const SymbolIndex &Index) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID(&Decl))
+  if (auto ID = getSymbolID(&D))
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref &R) {
@@ -97,16 +96,16 @@ enum ReasonToReject {
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl &Decl,
+llvm::Optional renamableWithinFile(const Decl &RenameDecl,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa(&Decl))
+  if (llvm::isa(&RenameDecl))
 return ReasonToReject::UnsupportedSymbol;
-  auto &ASTCtx = Decl.getASTContext();
+  auto &ASTCtx = RenameDecl.getASTContext();
   const auto &SM = ASTCtx.getSourceManager();
   bool MainFileIsHeader = ASTCtx.getLangOpts().IsHeaderFile;
   bool DeclaredInMainFile =
-  SM.isWrittenInMainFile(SM.getExpansionLoc(Decl.getLocation()));
+  SM.isWrittenInMainFile(SM.getExpansionLoc(RenameDecl.getLocation()));
 
   // If the symbol is declared in the main file (which is not a header), we
   // rename it.
@@ -115,18 +114,19 @@ llvm::Optional renamable
 
   // Below are cases where the symbol is declared in the header.
   // If the symbol is function-local, we rename it.
-  if (Decl.getParentFunctionOrMethod())
+  if (RenameDecl.getParentFunctionOrMethod())
 return None;
 
   if (!Index)
 return ReasonToReject::NoIndexProvided;
 
-  bool IsIndexable =
-  SymbolCollector::shouldCollectSymbol(Decl, ASTCtx, {}, false);
+  bool IsIndexable = isa(RenameDecl) &&
+ SymbolCollector::shouldCollectSymbol(
+ cast(RenameDecl), ASTCtx, {}, false);
   // If the symbol is not indexable, we disallow rename.
   if (!IsIndexable)
 return ReasonToReject::NonIndexable;
-  auto OtherFile = getOtherRefFile(Decl, MainFile, *Index);
+  auto OtherFile = getOtherRefFile(RenameDecl, MainFile, *Index);
   // If the symbol is indexable and has no refs from other files in the index,
   // we rename it.
   if (!OtherFile)
@@ -154,7 +154,8 @@ renameWithinFile(ParsedAST &AST, llvm::S
 
   const auto *RenameDecl = Rename->getRenameDecl();
   assert(RenameDecl && "symbol must be found at this point");
-  if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {
+  if (auto Reject =
+  renamableWithinFile(*RenameDecl->getCanonicalDecl(), File, Index)) {
 auto Message = [](ReasonToReject Reason) {
   switch (Reason) {
   case NoIndexProvided:

Modified: clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp?rev=364537&r1=364536&r2=364537&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp Thu Jun 27 
06:24:10 2019
@@ -78,7 +78,6 @@ TEST(RenameTest, SingleFile) {
   for (const Test &T : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; //

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364537: [clangd] Fix a case where we fail to detect a 
header-declared symbol in rename. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63872?vs=206844&id=206847#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63872

Files:
  clang-tools-extra/trunk/clangd/refactor/Rename.cpp
  clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/trunk/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/trunk/clangd/refactor/Rename.cpp
+++ clang-tools-extra/trunk/clangd/refactor/Rename.cpp
@@ -67,15 +67,14 @@
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl &Decl,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl &D, StringRef MainFile,
 const SymbolIndex &Index) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID(&Decl))
+  if (auto ID = getSymbolID(&D))
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref &R) {
@@ -97,16 +96,16 @@
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl &Decl,
+llvm::Optional renamableWithinFile(const Decl &RenameDecl,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa(&Decl))
+  if (llvm::isa(&RenameDecl))
 return ReasonToReject::UnsupportedSymbol;
-  auto &ASTCtx = Decl.getASTContext();
+  auto &ASTCtx = RenameDecl.getASTContext();
   const auto &SM = ASTCtx.getSourceManager();
   bool MainFileIsHeader = ASTCtx.getLangOpts().IsHeaderFile;
   bool DeclaredInMainFile =
-  SM.isWrittenInMainFile(SM.getExpansionLoc(Decl.getLocation()));
+  SM.isWrittenInMainFile(SM.getExpansionLoc(RenameDecl.getLocation()));
 
   // If the symbol is declared in the main file (which is not a header), we
   // rename it.
@@ -115,18 +114,19 @@
 
   // Below are cases where the symbol is declared in the header.
   // If the symbol is function-local, we rename it.
-  if (Decl.getParentFunctionOrMethod())
+  if (RenameDecl.getParentFunctionOrMethod())
 return None;
 
   if (!Index)
 return ReasonToReject::NoIndexProvided;
 
-  bool IsIndexable =
-  SymbolCollector::shouldCollectSymbol(Decl, ASTCtx, {}, false);
+  bool IsIndexable = isa(RenameDecl) &&
+ SymbolCollector::shouldCollectSymbol(
+ cast(RenameDecl), ASTCtx, {}, false);
   // If the symbol is not indexable, we disallow rename.
   if (!IsIndexable)
 return ReasonToReject::NonIndexable;
-  auto OtherFile = getOtherRefFile(Decl, MainFile, *Index);
+  auto OtherFile = getOtherRefFile(RenameDecl, MainFile, *Index);
   // If the symbol is indexable and has no refs from other files in the index,
   // we rename it.
   if (!OtherFile)
@@ -154,7 +154,8 @@
 
   const auto *RenameDecl = Rename->getRenameDecl();
   assert(RenameDecl && "symbol must be found at this point");
-  if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {
+  if (auto Reject =
+  renamableWithinFile(*RenameDecl->getCanonicalDecl(), File, Index)) {
 auto Message = [](ReasonToReject Reason) {
   switch (Reason) {
   case NoIndexProvided:
Index: clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
@@ -78,7 +78,6 @@
   for (const Test &T : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =
 renameWithinFile(AST, testPath(TU.Filename), Code.point(), "abcde");
@@ -92,58 +91,68 @@
 }
 
 TEST(RenameTest, Renameable) {
-  // Test cases where the symbol is declared in header.
   struct Case {
-const char* HeaderCode;
+const char *Code;
 const char* ErrorMessage; // null if no error
+bool IsHeaderFile;
   };
+  const bool HeaderFile = true;
   Case Cases[] = {
   {R"cpp(// allow -- function-local
 void f(int [[Lo^cal]]) {
   [[Local]] = 2;
 }
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// allo

[PATCH] D63876: [OpenCL] Define CLK_NULL_EVENT without cast

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh created this revision.
svenvh added reviewers: Anastasia, yaxunl.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Defining CLK_NULL_EVENT with a `(void*)` cast has the (unintended?)
side-effect that the address space will be fixed (as generic in OpenCL
2.0 mode).  The consequence is that any target specific address space
for the clk_event_t type will not be applied.

It is not clear why the void pointer cast was needed in the first
place, and it seems we can do without it.


Repository:
  rC Clang

https://reviews.llvm.org/D63876

Files:
  lib/Headers/opencl-c-base.h
  test/SemaOpenCL/clk_event_t.cl


Index: test/SemaOpenCL/clk_event_t.cl
===
--- test/SemaOpenCL/clk_event_t.cl
+++ test/SemaOpenCL/clk_event_t.cl
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=c++
 
 // Taken from opencl-c.h
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 global clk_event_t ce; // expected-error {{the '__global clk_event_t' type 
cannot be used to declare a program scope variable}}
 
@@ -10,6 +10,7 @@
   event_t e;
   clk_event_t ce1;
   clk_event_t ce2;
+  clk_event_t ce3 = CLK_NULL_EVENT;
 
   if (e == ce1) { // expected-error {{invalid operands to binary expression 
('event_t' and 'clk_event_t')}}
 return 9;
Index: lib/Headers/opencl-c-base.h
===
--- lib/Headers/opencl-c-base.h
+++ lib/Headers/opencl-c-base.h
@@ -413,7 +413,7 @@
 #define CLK_OUT_OF_RESOURCES-5
 
 #define CLK_NULL_QUEUE  0
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 // execution model related definitions
 #define CLK_ENQUEUE_FLAGS_NO_WAIT   0x0


Index: test/SemaOpenCL/clk_event_t.cl
===
--- test/SemaOpenCL/clk_event_t.cl
+++ test/SemaOpenCL/clk_event_t.cl
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=c++
 
 // Taken from opencl-c.h
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 global clk_event_t ce; // expected-error {{the '__global clk_event_t' type cannot be used to declare a program scope variable}}
 
@@ -10,6 +10,7 @@
   event_t e;
   clk_event_t ce1;
   clk_event_t ce2;
+  clk_event_t ce3 = CLK_NULL_EVENT;
 
   if (e == ce1) { // expected-error {{invalid operands to binary expression ('event_t' and 'clk_event_t')}}
 return 9;
Index: lib/Headers/opencl-c-base.h
===
--- lib/Headers/opencl-c-base.h
+++ lib/Headers/opencl-c-base.h
@@ -413,7 +413,7 @@
 #define CLK_OUT_OF_RESOURCES-5
 
 #define CLK_NULL_QUEUE  0
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 // execution model related definitions
 #define CLK_ENQUEUE_FLAGS_NO_WAIT   0x0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 206854.
jvikstrom marked 2 inline comments as done.
jvikstrom added a comment.

Made test safe again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -841,6 +841,30 @@
   EXPECT_FALSE(PathResult.hasValue());
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 TEST_F(ClangdThreadingTest, NoConcurrentDiagnostics) {
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus &Status){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer)
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext &Ctx,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST &AST) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer &DiagConsumer;
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@
   // is parsed.
   // FIXME(ioeric): this can be slow and we may be able to index on less
   // critical paths.
-  WorkScheduler(CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
- 

[PATCH] D63878: [CTU] Add missing statistics

[Gabor Marton via Phabricator via cfe-commits]

martong created this revision.
martong added a reviewer: xazax.hun.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp, rnkovacs.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63878

Files:
  clang/lib/CrossTU/CrossTranslationUnit.cpp


Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -40,6 +40,10 @@
 STATISTIC(NumGetCTUSuccess,
   "The # of getCTUDefinition successfully returned the "
   "requested function's body");
+STATISTIC(NumUnsupportedNodeFound, "The # of imports when the ASTImporter "
+   "encountered an unsupported AST Node");
+STATISTIC(NumNameConflicts, "The # of imports when the ASTImporter "
+"encountered an ODR error");
 STATISTIC(NumTripleMismatch, "The # of triple mismatches");
 STATISTIC(NumLangMismatch, "The # of language mismatches");
 STATISTIC(NumLangDialectMismatch, "The # of language dialect mismatches");
@@ -404,10 +408,10 @@
 [&](const ImportError &IE) {
   switch (IE.Error) {
   case ImportError::NameConflict:
-// FIXME: Add statistic.
+++NumNameConflicts;
  break;
   case ImportError::UnsupportedConstruct:
-// FIXME: Add statistic.
+++NumUnsupportedNodeFound;
 break;
   case ImportError::Unknown:
 llvm_unreachable("Unknown import error happened.");


Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -40,6 +40,10 @@
 STATISTIC(NumGetCTUSuccess,
   "The # of getCTUDefinition successfully returned the "
   "requested function's body");
+STATISTIC(NumUnsupportedNodeFound, "The # of imports when the ASTImporter "
+   "encountered an unsupported AST Node");
+STATISTIC(NumNameConflicts, "The # of imports when the ASTImporter "
+"encountered an ODR error");
 STATISTIC(NumTripleMismatch, "The # of triple mismatches");
 STATISTIC(NumLangMismatch, "The # of language mismatches");
 STATISTIC(NumLangDialectMismatch, "The # of language dialect mismatches");
@@ -404,10 +408,10 @@
 [&](const ImportError &IE) {
   switch (IE.Error) {
   case ImportError::NameConflict:
-// FIXME: Add statistic.
+++NumNameConflicts;
  break;
   case ImportError::UnsupportedConstruct:
-// FIXME: Add statistic.
+++NumUnsupportedNodeFound;
 break;
   case ImportError::Unknown:
 llvm_unreachable("Unknown import error happened.");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

[Alex Strelnikov via Phabricator via cfe-commits]

astrelni updated this revision to Diff 206855.

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

https://reviews.llvm.org/D62977

Files:
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-upgrade-googletest-case.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest.h
  
clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest.h
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
@@ -28,6 +28,7 @@
 "OverloadedUnaryAndCheck.cpp",
 "TodoCommentCheck.cpp",
 "UnnamedNamespaceInHeaderCheck.cpp",
+"UpgradeGoogletestCaseCheck.cpp",
 "UsingNamespaceDirectiveCheck.cpp",
   ]
 }
Index: clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
@@ -0,0 +1,991 @@
+// RUN: %check_clang_tidy %s google-upgrade-googletest-case %t -- -- -I%S/Inputs
+
+#include "gtest/gtest.h"
+
+// 
+// Macros
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case' are deprecated; use equivalent APIs named with 'suite'
+// CHECK-FIXES: TYPED_TEST_SUITE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: TYPED_TEST_SUITE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: REGISTER_TYPED_TEST_SUITE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: INSTANTIATE_TYPED_TEST_SUITE_P(FooPrefix, FooTest, FooTypes);
+
+#ifdef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE TYPED_TEST_SUITE
+#endif
+
+#ifdef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE_P TYPED_TEST_SUITE_P
+#endif
+
+#ifdef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define REGISTER_TYPED_TEST_CASE_P REGISTER_TYPED_TEST_SUITE_P
+#endif
+
+#ifdef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define INSTANTIATE_TYPED_TEST_CASE_P INSTANTIATE_TYPED_TEST_SUITE_P
+#endif
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+
+// 
+// testing::Test
+
+class FooTest : public testing::Test {
+public:
+  static void SetUpTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void SetUpTestSuite();
+  static void TearDownTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void TearDownTestSuite();
+};
+
+void FooTest::SetUpTestCase() {}
+// CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: void FooTest::SetUpTestSuite() {}
+
+void FooTest::TearDownTestCase() {}
+// CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: void FooTest::TearDownTestSuite() {}
+
+template  class F

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

[Alex Strelnikov via Phabricator via cfe-commits]

astrelni added a comment.

In D62977#1559649 , @lebedev.ri wrote:

> In D62977#1559637 , @astrelni wrote:
>
> > In D62977#1559628 , @lebedev.ri 
> > wrote:
> >
> > > It //sounds// correct, but i don't see accompanying test changes, so i 
> > > can't be sure.
> >
> >
> > The tests as they are cover the positive case in that they would not show 
> > warning or fixes if we didn't find the replacements.
>
>
> Yep
>
> In D62977#1559637 , @astrelni wrote:
>
> > The only way to test the negative is to make a second test with a second 
> > set of mock googletest headers that declare things in the v1.8 way. Is this 
> > what you would prefer?
>
>
> If that is what it takes to get the test coverage, i suppose so.


What do you think of this?


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

https://reviews.llvm.org/D62977



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

[PATCH] D63773: [clangd] dummy variable extraction on a function scope

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Please forgive the mix of high-level and low-level comments here.
Happy to discuss further of course!




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:55
+// checks whether any variable in a given expr is declared in the DeclStmt
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager &M) {

nit: why take a DeclStmt instead of just the Decl here?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:55
+// checks whether any variable in a given expr is declared in the DeclStmt
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager &M) {

sammccall wrote:
> nit: why take a DeclStmt instead of just the Decl here?
This function name is confusing - it's unclear which of DeclStmt vs Exp is 
declared in which, and that it's subexpressions of Exp that are being checked

maybe `bool referencesLocalDecls`? and rename Decl -> Scope, as it provides the 
meaning of "local"



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:56
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager &M) {
+

nit: SourceManager is almost universally `SM` (or something more verbose)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:62
+  public:
+std::vector DeclRefExprs;
+bool VisitDeclRefExpr(DeclRefExpr *DeclRef) { // NOLINT

nit: seems a little clearer to collect the referenced decls rather than the 
referencing exprs.
(It will also generalize better if we want to do things like notice referenced 
local classes, which we don't yet)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:73
+// Beginning location of the ValueDecl of the DeclRef
+auto ValueDeclLoc = DeclRef->getDecl()->getBeginLoc();
+// return true if this ValueDecl location is within the DeclStmt

nit: "ValueDecl" is not usually a very interesting class conceptually, I'd just 
call this DeclLoc



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:73
+// Beginning location of the ValueDecl of the DeclRef
+auto ValueDeclLoc = DeclRef->getDecl()->getBeginLoc();
+// return true if this ValueDecl location is within the DeclStmt

sammccall wrote:
> nit: "ValueDecl" is not usually a very interesting class conceptually, I'd 
> just call this DeclLoc
throughout you're using `auto` a bit too heavily - usually doesn't aid 
readability when the type is a single word like `SourceLocation` here and isn't 
named in the expression



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:130
+// TODO: Add more unit tests after SelectionTree ancestor bug is fixed
+static bool extractionAllowed(const Stmt *ParStmt, const SelectionTree::Node 
*N,
+  const SourceManager &M) {

Another general style point: LLVM does use short variable names (like `N`) 
sometimes when the type unambiguously describes the role of the variable and 
the scope is small.

That's not the case here: a `SelectionTree::Node` could be almost anything so 
I'd suggest TargetExpr or so.

Conversely I think `Parent` or `NewParent` would be clearer than `ParStmt` 
which repeats more info from the type.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:132
+  const SourceManager &M) {
+  if (isa(ParStmt) &&
+  !checkForStmt(dyn_cast(ParStmt), N->ASTNode.get(), M))

I might be missing something, but as I understand:
 - you're proposing moving the expr N out of the scope ParStmt
 - you're testing whether any subexpression of N references anything declared 
in certain substmts of ParStmt
 - because of "certain substmts" you're only supporting this for some types of 
ParStmt

why can't we just check for anything declared inside ParStmt, and make this 
fully general (applied for all stmts)?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:157
+// we also check if doing the extraction will take a variable out of scope
+static const clang::Stmt *getStmt(const SelectionTree::Node *N,
+  const SourceManager &M) {

this needs a much more descriptive name.
maybe `getInsertionPoint()`?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:159
+  const SourceManager &M) {
+  auto CurN = N;
+  while (CurN->Parent) {

auto* (or `const auto*`) - we typically spell out the pointer-ness



Comment at: clang-tools-extra/clangd/refactor

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

[Sanjay Patel via Phabricator via cfe-commits]

spatel added a comment.

I skimmed D63174  but haven't applied either 
of these patches to test locally, so I may not have the full picture.

IMO, we do not want clang regression tests running -instcombine/-instsimplify. 
That can cause clang tests to break when an underlying LLVM change is made. 
Forcing LLVM devs to depend on clang and fix the resulting breakage is 
backwards and unexpected extra work. This has happened to me several times.

As a compromise to the -O0 IR explosion, we do have precedent for running the 
optimizer's -mem2reg pass since that doesn't change frequently at this point.

And I haven't tried this, but we do have utils/update_cc_test_checks.py - this 
is supposed to take the manual labor out of generating assertions in the same 
way that we do in the optimizer and codegen regression tests with 
utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you start 
with that and remove the irrelevant CHECK lines, so only the common/important 
lines remain? Or just use independent FileCheck '--check-prefixes'?


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

https://reviews.llvm.org/D63638



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

[PATCH] D60455: [SYCL] Implement SYCL device code outlining

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon updated this revision to Diff 206861.
Fznamznon added a comment.

Added warning diagnostic for `sycl_kernel` attribute.

Now if the `sycl_kernel` attribute applied to a function which doesn't meet 
requirements for OpenCL kernel generation, attribute will be ignored and 
diagnostic will be emitted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaSYCL.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGenSYCL/device-functions.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
  clang/test/SemaSYCL/device-attributes.cpp
  clang/test/SemaSYCL/device-code-outlining.cpp

Index: clang/test/SemaSYCL/device-code-outlining.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-code-outlining.cpp
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -std=c++11 -fsycl-is-device -ast-dump %s | FileCheck %s
+
+template 
+T bar(T arg);
+// CHECK: FunctionTemplateDecl {{.*}} bar
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void foo() {
+  int a = 1 + 1 + bar(1);
+}
+// CHECK: FunctionDecl {{.*}} foo
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+template 
+T bar(T arg) {
+  return arg;
+}
+
+template 
+__attribute__((sycl_kernel)) void kernel_single_task(Func kernelFunc) {
+  kernelFunc();
+}
+// CHECK: FunctionTemplateDecl {{.*}} kernel_single_task
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void host_foo() {
+  int b = 0;
+}
+// CHECK: FunctionDecl {{.*}} host_foo
+// CHECK-NOT: SYCLDeviceAttr
+// CHECK: FunctionDecl {{.*}} main
+
+int main() {
+  kernel_single_task([]() { foo(); });
+  host_foo();
+  return 0;
+}
Index: clang/test/SemaSYCL/device-attributes.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attributes.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fsycl-is-device -verify %s
+
+[[clang::sycl_kernel]] int gv2 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+__attribute__((sycl_kernel)) int gv3 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+
+__attribute__((sycl_kernel(1))) void foo(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+[[clang::sycl_kernel(1)]] void foo2(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+
+// Only template functions
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// At least two template parameters
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Both first two template parameters must be a typenames
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must return void
+template 
+__attribute__((sycl_kernel)) int foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] int foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must take at least one argument
+template 
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// No

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri resigned from this revision.
lebedev.ri added a comment.

Looks reasonable. I did not review the check itself though.
Are `test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp` and 
`test/clang-tidy/google-upgrade-googletest-case.cpp ` identical other than the 
included header and expected output?
I'd recommend to condense it into a single file, and just have two `RUN` lines 
each one checking different message prefixes




Comment at: clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h:34
+private:
+  std::unordered_set MatchedTemplateLocations;
+};

Have you tried `llvm::DenseSet` instead?
This //may// not matter *here*, but `std::unordered_set` usually results in 
horrible perf.



Comment at: 
clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp:9
+void DummyFixTarget() {}
+// CHECK-FIXES: void DummyFixTarget() {}
+

Hm?


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

https://reviews.llvm.org/D62977



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Haojian Wu via Phabricator via cfe-commits]

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

Let's rephrase the commit message, I think this patch is just to "emit the 
semantic highlighting tokens when the main AST is built".




Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:844
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {

maybe move this test to SemanticHighlightingTests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D63638#1560846 , @spatel wrote:

> I skimmed D63174  but haven't applied either 
> of these patches to test locally, so I may not have the full picture.
>
> IMO, we do not want clang regression tests running 
> -instcombine/-instsimplify. That can cause clang tests to break when an 
> underlying LLVM change is made. Forcing LLVM devs to depend on clang and fix 
> the resulting breakage is backwards and unexpected extra work.


+1

> This has happened to me several times.



> As a compromise to the -O0 IR explosion, we do have precedent for running the 
> optimizer's -mem2reg pass since that doesn't change frequently at this point.
> 
> And I haven't tried this, but we do have utils/update_cc_test_checks.py - 
> this is supposed to take the manual labor out of generating assertions in the 
> same way that we do in the optimizer and codegen regression tests with 
> utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you 
> start with that and remove the irrelevant CHECK lines, so only the 
> common/important lines remain? Or just use independent FileCheck 
> '--check-prefixes'?

That script has bitrot and is unusable last time i checked; everyone preferred 
to manually write broken checklines here :)


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

https://reviews.llvm.org/D63638



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

[clang-tools-extra] r364551 - [clangd] Emit semantic highlighting tokens when the main AST is built.

[Johan Vikstrom via cfe-commits]

Author: jvikstrom
Date: Thu Jun 27 08:13:03 2019
New Revision: 364551

URL: http://llvm.org/viewvc/llvm-project?rev=364551&view=rev
Log:
[clangd] Emit semantic highlighting tokens when the main AST is built.

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=364551&r1=364550&r2=364551&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Thu Jun 27 08:13:03 2019
@@ -48,8 +48,10 @@ namespace {
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer)
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext &Ctx,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@ struct UpdateIndexCallbacks : public Par
   void onMainAST(PathRef Path, ParsedAST &AST) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@ struct UpdateIndexCallbacks : public Par
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer &DiagConsumer;
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@ ClangdServer::Options ClangdServer::opts
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@ ClangdServer::ClangdServer(const GlobalC
   // is parsed.
   // FIXME(ioeric): this can be slow and we may be able to index on less
   // critical paths.
-  WorkScheduler(CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
-llvm::make_unique(DynamicIdx.get(),
-DiagConsumer),
-Opts.UpdateDebounce, Opts.RetentionPolicy) {
+  WorkScheduler(
+  CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
+  llvm::make_unique(
+  DynamicIdx.get(), DiagConsumer, Opts.SemanticHighlighting),
+  Opts.UpdateDebounce, Opts.RetentionPolicy) {
   // Adds an index to the stack, at higher priority than existing indexes.
   auto AddIndex = [&](SymbolIndex *Idx) {
 if (this->Index != nullptr) {

Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=364551&r1=364550&r2=364551&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.h Thu Jun 27 08:13:03 2019
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@ public:
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus &Status){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each 
particular
@@ -131,6 +137,9 @@ public:
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@ private:
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;

Modifie

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

[Johan Vikström via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364551: [clangd] Emit semantic highlighting tokens when the 
main AST is built. (authored by jvikstrom, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63821?vs=206854&id=206867#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/trunk/clangd/ClangdServer.cpp
  clang-tools-extra/trunk/clangd/ClangdServer.h
  clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/trunk/clangd/ClangdServer.h
===
--- clang-tools-extra/trunk/clangd/ClangdServer.h
+++ clang-tools-extra/trunk/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus &Status){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
@@ -7,7 +7,9 @@
 //===--===//
 
 #include "Annotations.h"
+#include "ClangdServer.h"
 #include "SemanticHighlighting.h"
+#include "TestFS.h"
 #include "TestTU.h"
 #include "gmock/gmock.h"
 
@@ -64,6 +66,30 @@
   }
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/trunk/clangd/ClangdServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer)
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer &DiagConsumer,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext &Ctx,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST &AST) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer &DiagConsumer;
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 206870.
dgoldman marked 9 inline comments as done.
dgoldman added a comment.

- Minor fixes


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-recursive.cpp

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,120 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; }  // expected-note {{'getX' declared here}}
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; }  // expected-note {{'getY0' declared here}}
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2().  // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+  getM(). // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+  triggee();  // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2().  // expected-error {{no member named 'getY2' in 'Z'}}
+  getM().
+  thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D();  // expected-note {{'get_me_a_D' declared here}}
+};
+class Scope {
+public:
+  A make_an_A();
+  B make_a_B();  // expected-note {{'make_a_B' declared here}}
+};
+
+Scope scope_obj;
+
+int testDiscardedCorrections() {
+  return scope_obj.make_an_E().  // expected-error {{no member named 'make_an_E' in 'Scope'; did you mean 'make_a_B'}}
+  get_me_a_Z().value;// expected-error {{no member named 'get_me_a_Z' in 'B'; did you mean 'get_me_a_D'}}
+}
+
+class AmbiguousHelper {
+public:
+  int helpMe();
+  int helpBe();
+};
+class Ambiguous {
+public:
+  int calculateA();
+  int calculateB();
+
+  AmbiguousHelper getHelp1();
+  AmbiguousHelper getHelp2();
+};
+
+Ambiguous ambiguous_obj;
+
+int testDirectAmbiguousCorrection() {
+  return ambiguous_obj.calculateZ();  // expected-error {{no member named 'calculateZ' in 'Ambiguous'}}
+}
+
+int testRecursiveAmbiguousCorrection() {
+  return ambiguous_obj.getHelp3().// expected-error {{no member named 'getHelp3' in 'Ambiguous'}}
+  helpCe();
+}
+
+
+class DeepAmbiguityHelper {
+public:
+  DeepAmbiguityHelper& help1();
+  DeepAmbiguityHelper& help2();
+
+  DeepAmbiguityHelper& methodA();
+  DeepAmbiguityHelper& somethingMethodB();
+  DeepAmbiguityHelper& functionC();
+  DeepAmbiguityHelper& deepMethodD();
+  DeepAmbiguityHelper& asDeepAsItGets();
+};
+
+DeepAmbiguityHelper deep_obj;
+
+int testDeepAmbiguity() {
+  deep_obj.
+  methodB(). // expected-error {{no member named 'methodB' in 'DeepAmbiguityHelper'}}
+  somethingMethodC().
+  functionD().
+  deepMethodD().
+  help3().
+  asDeepASItGet().
+  functionE();
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7610,15 +7610,22 @@
   llvm::SmallDenseMap OverloadResolution;
 
   /// Emit diagnostics for all of the TypoExprs encountered.
+  ///
   /// If the TypoExprs were successfully corrected, then the diagnostics should
   /// suggest the corrections. Otherwise the diagnostics will not suggest
   /// anything (having been passed an empty TypoCorrection).
-  void EmitAllDiagnostics() {
+  ///
+  /// If we've failed to correct due to ambiguous corrections, we need to
+  /// be sure to pass empty corrections and replacements. Otherwise it's
+  /// possible that the Consumer has a TypoCorrection that failed to ambiguity
+  /// and we don't want to report those diagnostics.
+  void EmitAllDiagnostics(bool IsAmbiguous) {
 for (TypoExpr *TE : TypoExprs) {
   auto &State = SemaRef.getTypoExprState(TE);
   if (State.DiagHandler) {
-TypoCorrection TC = State.Consumer->getCurrentCorrection();
-ExprResult Replacement = TransformCache[TE];
+TypoCorrection TC = IsAmbiguous
+? TypoCorrection() : State.Consumer->getCurrentCorrection();
+ExprResult Replacement = IsAmbiguous ? ExprError() : TransformCache[TE];
 
 // Extract the NamedDecl from the transformed TypoExpr and add it to the
 // TypoCorrection, replacing the existing decls. This ensures the ri

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7764
+  llvm::SmallDenseMap NewTransformCache;
+  auto SavedTransformCache = TransformCache;
+  TransformCache = NewTransformCache;

Should I do the same `std::move` and `clear` here as well?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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

[PATCH] D60455: [SYCL] Implement SYCL device code outlining

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon updated this revision to Diff 206873.
Fznamznon added a comment.

Minor fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaSYCL.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGenSYCL/device-functions.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
  clang/test/SemaSYCL/device-attributes.cpp
  clang/test/SemaSYCL/device-code-outlining.cpp

Index: clang/test/SemaSYCL/device-code-outlining.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-code-outlining.cpp
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -std=c++11 -fsycl-is-device -ast-dump %s | FileCheck %s
+
+template 
+T bar(T arg);
+// CHECK: FunctionTemplateDecl {{.*}} bar
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void foo() {
+  int a = 1 + 1 + bar(1);
+}
+// CHECK: FunctionDecl {{.*}} foo
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+template 
+T bar(T arg) {
+  return arg;
+}
+
+template 
+__attribute__((sycl_kernel)) void kernel_single_task(Func kernelFunc) {
+  kernelFunc();
+}
+// CHECK: FunctionTemplateDecl {{.*}} kernel_single_task
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void host_foo() {
+  int b = 0;
+}
+// CHECK: FunctionDecl {{.*}} host_foo
+// CHECK-NOT: SYCLDeviceAttr
+// CHECK: FunctionDecl {{.*}} main
+
+int main() {
+  kernel_single_task([]() { foo(); });
+  host_foo();
+  return 0;
+}
Index: clang/test/SemaSYCL/device-attributes.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attributes.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fsycl-is-device -verify %s
+
+[[clang::sycl_kernel]] int gv2 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+__attribute__((sycl_kernel)) int gv3 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+
+__attribute__((sycl_kernel(1))) void foo(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+[[clang::sycl_kernel(1)]] void foo2(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+
+// Only template functions
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// At least two template parameters
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Both first two template parameters must be a typenames
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must return void
+template 
+__attribute__((sycl_kernel)) int foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] int foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must take at least one argument
+template 
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// No diagnosticts
+template 
+__attribute__((sycl_kernel)) void foo(T P);
+template 
+[[clang::sycl_kernel]] void foo1(T P);
Ind

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D63638#1560846 , @spatel wrote:

> I skimmed D63174  but haven't applied either 
> of these patches to test locally, so I may not have the full picture.
>
> IMO, we do not want clang regression tests running 
> -instcombine/-instsimplify. That can cause clang tests to break when an 
> underlying LLVM change is made. Forcing LLVM devs to depend on clang and fix 
> the resulting breakage is backwards and unexpected extra work. This has 
> happened to me several times.
>
> As a compromise to the -O0 IR explosion, we do have precedent for running the 
> optimizer's -mem2reg pass since that doesn't change frequently at this point.
>
> And I haven't tried this, but we do have utils/update_cc_test_checks.py - 
> this is supposed to take the manual labor out of generating assertions in the 
> same way that we do in the optimizer and codegen regression tests with 
> utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you 
> start with that and remove the irrelevant CHECK lines, so only the 
> common/important lines remain? Or just use independent FileCheck 
> '--check-prefixes'?


I definitely agree running -instcombine would be bad since it can replace 
squences with other sequences. -instsimplify is a little less scary because our 
intrinsic tests shouldn't really have a lot of things that are trivially 
reducible. Though that may not be as true as I want it to be. The main issue we 
seemed to need -instsimplify for with the new pass manager is to merge 
redundant bitcasts. The inliner in the old pass manager seemed to do that 
itself, but the new pass manager's always inliner doesn't.


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

https://reviews.llvm.org/D63638



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

[PATCH] D63878: [CTU] Add missing statistics

[Gábor Horváth via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63878



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

[PATCH] D63518: BitStream reader: propagate errors

[JF Bastien via Phabricator via cfe-commits]

jfb marked 2 inline comments as done.
jfb added a subscriber: hans.
jfb added inline comments.



Comment at: llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp:205
+  return MaybeBitCode.takeError();
+switch (unsigned BitCode = MaybeBitCode.get()) {
 default: // Default behavior: reject

abrachet wrote:
> This and an identical switch on line 5367 cause an unused variable warning 
> from this commit. I don't know if the build bots report on this, or the 
> proper way to tell you about this but hopefully you will see it :)
Thanks, looks like @Hans fixed it in r364505. Odd that it wasn't warning 
locally for me.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63518



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > Currently `currentComponent` is generated 
> > > > > > > > > > > > > > > > > > > by the compiler. But can we instead pass 
> > > > > > > > > > > > > > > > > > > this data as an extra parameter to this 
> > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > components as an argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > function, it means that the runtime needs 
> > > > > > > > > > > > > > > > > > to generate all components related to a map 
> > > > > > > > > > > > > > > > > > clause. I don't think the runtime is able 
> > > > > > > > > > > > > > > > > > to do that efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > in the current scheme, these components are 
> > > > > > > > > > > > > > > > > > naturally generated by the compiler, and 
> > > > > > > > > > > > > > > > > > the runtime only needs to know the base 
> > > > > > > > > > > > > > > > > > pointer, pointer, type, size. etc.
> > > > > > > > > > > > > > > > > With the current scheme, we may end with the 
> > > > > > > > > > > > > > > > > code blowout. We need to generate very 
> > > > > > > > > > > > > > > > > similar code for different types and 
> > > > > > > > > > > > > > > > > variables. The worst thing here is that we 
> > > > > > > > > > > > > > > > > will be unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > of code because the codegen relies on the 
> > > > > > > > > > > > > > > > > runtime functions and the code cannot be 
> > > > > > > > > > > > > > > > > inlined. That's why I would like to move as 
> > > > > > > > > > > > > > > > > much as possible code to the runtime rather 
> > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > I understand your concerns. I think this is the 
> > > > > > > > > > > > > > > > best we can do right now.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > The most worrisome case will be when we have 
> > > > > > > > > > > > > > > > nested mappers within each other. In this case, 
> > > > > > > > > > > > > > > > a mapper function will call another mapper 
> > > > > > > > > > > > > > > > function. We can inline the inner mapper 
> > > > > > > > > > > > > > > > functions in this scenario, so that these 
> > > > > > > > > > > > > > > > mapper function can be properly optimized. As a 
> > > > > > > > > > > > > > > > result, I think the performance should be fine.
> > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > passed in the array to the runtime. Do you think 
> > > > > > > > > > > > > > > it is going to be slower? In your current scheme, 
> > > > > > > > > > > > > > > we generate many runtime calls instead. Could you 
> > > > > > > > > > > > > > > try to estimate the number of calls in cases if 
> > > > > > > > > > > > > > > we'll call the mappers through the indirect 
> > > > > > > > > > > > > > > function calls and in your cuurent scheme, where 
> > > > > > > > > > > > > > > we need to call the runtime functions many times 
> > > > > > > > > > > > > > > in each particular mapper?
> > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The number of function calls will be exactly equal 
> > > > > > > > > > > > > > to the number of components mapped, no matter 
> > > > > > > > > > > > > > whether there are nested mappers or not. The number 
> > > > > > > > > > > > > > of components depend on the program. E.g., if we 
> > > > > > > > > > > > > > map a large array section, then there will be ma

[PATCH] D63756: [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and HIP (CLANG).

[Christudasan Devadasan via Phabricator via cfe-commits]

cdevadas added a comment.

I have created the review for adding the metadata in the backend. 
https://reviews.llvm.org/D63886 
Marking the current review depended on D63886 .


Repository:
  rC Clang

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

https://reviews.llvm.org/D63756



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > generated by the compiler. But can we 
> > > > > > > > > > > > > > > > > > > > instead pass this data as an extra 
> > > > > > > > > > > > > > > > > > > > parameter to this `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > components as an argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > > function, it means that the runtime needs 
> > > > > > > > > > > > > > > > > > > to generate all components related to a 
> > > > > > > > > > > > > > > > > > > map clause. I don't think the runtime is 
> > > > > > > > > > > > > > > > > > > able to do that efficiently. On the other 
> > > > > > > > > > > > > > > > > > > hand, in the current scheme, these 
> > > > > > > > > > > > > > > > > > > components are naturally generated by the 
> > > > > > > > > > > > > > > > > > > compiler, and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > > > > With the current scheme, we may end with 
> > > > > > > > > > > > > > > > > > the code blowout. We need to generate very 
> > > > > > > > > > > > > > > > > > similar code for different types and 
> > > > > > > > > > > > > > > > > > variables. The worst thing here is that we 
> > > > > > > > > > > > > > > > > > will be unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > of code because the codegen relies on the 
> > > > > > > > > > > > > > > > > > runtime functions and the code cannot be 
> > > > > > > > > > > > > > > > > > inlined. That's why I would like to move as 
> > > > > > > > > > > > > > > > > > much as possible code to the runtime rather 
> > > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > > I understand your concerns. I think this is 
> > > > > > > > > > > > > > > > > the best we can do right now.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > The most worrisome case will be when we have 
> > > > > > > > > > > > > > > > > nested mappers within each other. In this 
> > > > > > > > > > > > > > > > > case, a mapper function will call another 
> > > > > > > > > > > > > > > > > mapper function. We can inline the inner 
> > > > > > > > > > > > > > > > > mapper functions in this scenario, so that 
> > > > > > > > > > > > > > > > > these mapper function can be properly 
> > > > > > > > > > > > > > > > > optimized. As a result, I think the 
> > > > > > > > > > > > > > > > > performance should be fine.
> > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > think it is going to be slower? In your current 
> > > > > > > > > > > > > > > > scheme, we generate many runtime calls instead. 
> > > > > > > > > > > > > > > > Could you try to estimate the number of calls 
> > > > > > > > > > > > > > > > in cases if we'll call the mappers through the 
> > > > > > > > > > > > > > > > indirect function calls and in your cuurent 
> > > > > > > > > > > > > > > > scheme, where we need to call the runtime 
> > > > > > > > > > > > > > > > functions many times in each particular mapper?
> > > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > The number of function calls will be exactly 
> > > > > > > > > > > > > > > equal to the number of components mapped, no 
> > > > > > > > > > > > > > > matter whether there a

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > generated by the compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > instead pass this data as an extra 
> > > > > > > > > > > > > > > > > > > > > parameter to this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means that 
> > > > > > > > > > > > > > > > > > > > the runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > components related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > don't think the runtime is able to do 
> > > > > > > > > > > > > > > > > > > > that efficiently. On the other hand, in 
> > > > > > > > > > > > > > > > > > > > the current scheme, these components 
> > > > > > > > > > > > > > > > > > > > are naturally generated by the 
> > > > > > > > > > > > > > > > > > > > compiler, and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > > know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > > > > > With the current scheme, we may end with 
> > > > > > > > > > > > > > > > > > > the code blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > very similar code for different types and 
> > > > > > > > > > > > > > > > > > > variables. The worst thing here is that 
> > > > > > > > > > > > > > > > > > > we will be unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > amount of code because the codegen relies 
> > > > > > > > > > > > > > > > > > > on the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > like to move as much as possible code to 
> > > > > > > > > > > > > > > > > > > the runtime rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > I understand your concerns. I think this is 
> > > > > > > > > > > > > > > > > > the best we can do right now.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > have nested mappers within each other. In 
> > > > > > > > > > > > > > > > > > this case, a mapper function will call 
> > > > > > > > > > > > > > > > > > another mapper function. We can inline the 
> > > > > > > > > > > > > > > > > > inner mapper functions in this scenario, so 
> > > > > > > > > > > > > > > > > > that these mapper function can be properly 
> > > > > > > > > > > > > > > > > > optimized. As a result, I think the 
> > > > > > > > > > > > > > > > > > performance should be fine.
> > > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > > think it is going to be slower? In your 
> > > > > > > > > > > > > > > > > current scheme, we generate many runtime 
> > > > > > > > > > > > > > > > > calls instead. Could you try to estimate the 
> > > > > > > > > > > > > > > > > number of calls in cases if we'll call the 
> > > > > > > > > > > > > > > > > mappers through the indirect function calls 
> > > > > > > > > > > > > > > > > and in your cuurent scheme, where we need to 
> > > > > > > > > > > > > > > > > call the runtime functions many times in each 
> > > > > > > > > > > > > > > > > particular mapper?
> > > > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Sorry I don't understand your idea. What 
> > > > > > > > > > > > > > > > indirect function call

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But can 
> > > > > > > > > > > > > > > > > > > > > > we instead pass this data as an 
> > > > > > > > > > > > > > > > > > > > > > extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means that 
> > > > > > > > > > > > > > > > > > > > > the runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > > components related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > > don't think the runtime is able to do 
> > > > > > > > > > > > > > > > > > > > > that efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > > > > in the current scheme, these 
> > > > > > > > > > > > > > > > > > > > > components are naturally generated by 
> > > > > > > > > > > > > > > > > > > > > the compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount of 
> > > > > > > > > > > > > > > > > > > > code because the codegen relies on the 
> > > > > > > > > > > > > > > > > > > > runtime functions and the code cannot 
> > > > > > > > > > > > > > > > > > > > be inlined. That's why I would like to 
> > > > > > > > > > > > > > > > > > > > move as much as possible code to the 
> > > > > > > > > > > > > > > > > > > > runtime rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > I understand your concerns. I think this 
> > > > > > > > > > > > > > > > > > > is the best we can do right now.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > > have nested mappers within each other. In 
> > > > > > > > > > > > > > > > > > > this case, a mapper function will call 
> > > > > > > > > > > > > > > > > > > another mapper function. We can inline 
> > > > > > > > > > > > > > > > > > > the inner mapper functions in this 
> > > > > > > > > > > > > > > > > > > scenario, so that these mapper function 
> > > > > > > > > > > > > > > > > > > can be properly optimized. As a result, I 
> > > > > > > > > > > > > > > > > > > think the performance should be fine.
> > > > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > > > think it is going to be slower? In your 
> > > > > > > > > > > > > > > > > > current scheme, we generate many runtime 
> > > > > > > > > > > > > > > > > > calls instead. Could you try to estimate 
> > > > > > > > > > > > > > > > > > the number of calls in cases if we'll call 
> > > > > > > > > > > > > > > > > > the mappers through the indirect function 
> > > > > > > > > > > > > > > > > > calls and in your cuurent scheme, where we 
> > > > > > > > > > > > > > > > > > need to call the runtime functions many 
> > > > > > > > > > > > > > > > > > times in each particular mapper?
> > > > > > > > > > > > > > > > > Hi Alexey,
> 

[PATCH] D61809: [BPF] Preserve debuginfo array/union/struct type/access index

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added a comment.

@eli.friedman Hi, Just ping. I have removed getParents() for ASTContext and 
added description of the new intrinsic in language doc. Could you take a look? 
Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D61809



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But 
> > > > > > > > > > > > > > > > > > > > > > > can we instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > an extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be 
> > > > > > > > > > > > > > > > > > > > > > very difficult and inefficient. If 
> > > > > > > > > > > > > > > > > > > > > > we pass components as an argument 
> > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > that the runtime needs to generate 
> > > > > > > > > > > > > > > > > > > > > > all components related to a map 
> > > > > > > > > > > > > > > > > > > > > > clause. I don't think the runtime 
> > > > > > > > > > > > > > > > > > > > > > is able to do that efficiently. On 
> > > > > > > > > > > > > > > > > > > > > > the other hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > scheme, these components are 
> > > > > > > > > > > > > > > > > > > > > > naturally generated by the 
> > > > > > > > > > > > > > > > > > > > > > compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > > > > of code because the codegen relies on 
> > > > > > > > > > > > > > > > > > > > > the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > > > like to move as much as possible code 
> > > > > > > > > > > > > > > > > > > > > to the runtime rather than to emit it 
> > > > > > > > > > > > > > > > > > > > > in the compiler. 
> > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > this is the best we can do right now.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > > > have nested mappers within each other. 
> > > > > > > > > > > > > > > > > > > > In this case, a mapper function will 
> > > > > > > > > > > > > > > > > > > > call another mapper function. We can 
> > > > > > > > > > > > > > > > > > > > inline the inner mapper functions in 
> > > > > > > > > > > > > > > > > > > > this scenario, so that these mapper 
> > > > > > > > > > > > > > > > > > > > function can be properly optimized. As 
> > > > > > > > > > > > > > > > > > > > a result, I think the performance 
> > > > > > > > > > > > > > > > > > > > should be fine.
> > > > > > > > > > > > > > > > > > > Instead, we can use indirect function 
> > > > > > > > > > > > > > > > > > > calls passed in the array to the runtime. 
> > > > > > > > > > > > > > > > > > > Do you think it is going to be slower? In 
> > > > > > > > > > > > > > > > > > > your current scheme, we generate many 
> > > > > > > > > > > > > > > > > > > runtime calls instead. Could you try to 
> > > > > > > > > > > > > > > > > > > estimate the number of calls in cases if 
> > > > > > > > > > > > > > > > > > > we'll call the mappers through the 
> > > > > 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But 
> > > > > > > > > > > > > > > > > > > > > > > > can we instead pass this data 
> > > > > > > > > > > > > > > > > > > > > > > > as an extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be 
> > > > > > > > > > > > > > > > > > > > > > > very difficult and inefficient. 
> > > > > > > > > > > > > > > > > > > > > > > If we pass components as an 
> > > > > > > > > > > > > > > > > > > > > > > argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > > > function, it means that the 
> > > > > > > > > > > > > > > > > > > > > > > runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > > > > components related to a map 
> > > > > > > > > > > > > > > > > > > > > > > clause. I don't think the runtime 
> > > > > > > > > > > > > > > > > > > > > > > is able to do that efficiently. 
> > > > > > > > > > > > > > > > > > > > > > > On the other hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > > scheme, these components are 
> > > > > > > > > > > > > > > > > > > > > > > naturally generated by the 
> > > > > > > > > > > > > > > > > > > > > > > compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > > > > > of code because the codegen relies 
> > > > > > > > > > > > > > > > > > > > > > on the runtime functions and the 
> > > > > > > > > > > > > > > > > > > > > > code cannot be inlined. That's why 
> > > > > > > > > > > > > > > > > > > > > > I would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > possible code to the runtime rather 
> > > > > > > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > > this is the best we can do right now.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > The most worrisome case will be when 
> > > > > > > > > > > > > > > > > > > > > we have nested mappers within each 
> > > > > > > > > > > > > > > > > > > > > other. In this case, a mapper 
> > > > > > > > > > > > > > > > > > > > > function will call another mapper 
> > > > > > > > > > > > > > > > > > > > > function. We can inline the inner 
> > > > > > > > > > > > > > > > > > > > > mapper functions in this scenario, so 
> > > > > > > > > > > > > > > > > > > > > that these mapper function can be 
> > > > > > > > > > > > > > > > > > > > > properly optimized. As a result, I 
> > > > > > > > > > > > > > > > > > > > > think the performance should be fine.
> > > > > > > > > > > > > > > > > > > > Instead, we can use indirect function 
> > > > > > > > > > > > > > > > > > > > calls passed in the array to the 
> > > > > > > > > > > > > > > > > > > > runtime. Do you think it is going to be 
> > > > > > > > > > > > > > > > > > > > slower? In your current scheme, we 
> > > > > > > > > > > > > > > > > > > > generate many runtime calls instead. 
> > > > > > > > > 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` 
> > > > > > > > > > > > > > > > > > > > > > > > > is generated by the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > > But can we instead pass this 
> > > > > > > > > > > > > > > > > > > > > > > > > data as an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will 
> > > > > > > > > > > > > > > > > > > > > > > > be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > > > that the runtime needs to 
> > > > > > > > > > > > > > > > > > > > > > > > generate all components related 
> > > > > > > > > > > > > > > > > > > > > > > > to a map clause. I don't think 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > > > > > > > in the current scheme, these 
> > > > > > > > > > > > > > > > > > > > > > > > components are naturally 
> > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler, and 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may 
> > > > > > > > > > > > > > > > > > > > > > > end with the code blowout. We 
> > > > > > > > > > > > > > > > > > > > > > > need to generate very similar 
> > > > > > > > > > > > > > > > > > > > > > > code for different types and 
> > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing here 
> > > > > > > > > > > > > > > > > > > > > > > is that we will be unable to 
> > > > > > > > > > > > > > > > > > > > > > > optimize this huge amount of code 
> > > > > > > > > > > > > > > > > > > > > > > because the codegen relies on the 
> > > > > > > > > > > > > > > > > > > > > > > runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > > > this is the best we can do right 
> > > > > > > > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > > > > > > > > > > > > > > > > > > > > > when we have nested mappers within 
> > > > > > > > > > > > > > > > > > > > > > each other. In this case, a mapper 
> > > > > > > > > > > > > > > > > > > > > > function will call another mapper 
> > > > > > > > > > > > > > > > > > > > > > function. We can inline the inner 
> > > > > > > > > > > > > > > > > > > > > > mapper functions in this scenario, 
> > > > > > > > > > > > > > > > > > > > > > so that these mapper function can 
> > > > > > > > > > > > > > > > > > > > > > be properly optimized. As a result, 
> > > > > > > > > > > > > > > > > > > > > > I think the performance should be 
> > > > > > > > > > > > > > > > 

[PATCH] D63773: [clangd] dummy variable extraction on a function scope

[Shaurya Gupta via Phabricator via cfe-commits]

SureYeaah marked 14 inline comments as done.
SureYeaah added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:173
+  // give up if extraction will take a variable out of scope
+  if (!extractionAllowed(ParStmt, N, M))
+break;

sammccall wrote:
> here you're traversing the whole Expr to find the referenced decls at each 
> iteration of this loop.
> Can you analyse the expr just once, and reuse the list of decls?
I thought it'll only be analyzed once but actually it's at max twice in the 
case where the selected expression is a part of a DeclStmt in the  of a 
ForStmt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63773



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Currently 
> > > > > > > > > > > > > > > > > > > > > > > > > > `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > > > But can we instead pass 
> > > > > > > > > > > > > > > > > > > > > > > > > > this data as an extra 
> > > > > > > > > > > > > > > > > > > > > > > > > > parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will 
> > > > > > > > > > > > > > > > > > > > > > > > > be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it 
> > > > > > > > > > > > > > > > > > > > > > > > > means that the runtime needs 
> > > > > > > > > > > > > > > > > > > > > > > > > to generate all components 
> > > > > > > > > > > > > > > > > > > > > > > > > related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > > > > > > don't think the runtime is 
> > > > > > > > > > > > > > > > > > > > > > > > > able to do that efficiently. 
> > > > > > > > > > > > > > > > > > > > > > > > > On the other hand, in the 
> > > > > > > > > > > > > > > > > > > > > > > > > current scheme, these 
> > > > > > > > > > > > > > > > > > > > > > > > > components are naturally 
> > > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler, 
> > > > > > > > > > > > > > > > > > > > > > > > > and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > > > > > > > know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may 
> > > > > > > > > > > > > > > > > > > > > > > > end with the code blowout. We 
> > > > > > > > > > > > > > > > > > > > > > > > need to generate very similar 
> > > > > > > > > > > > > > > > > > > > > > > > code for different types and 
> > > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing here 
> > > > > > > > > > > > > > > > > > > > > > > > is that we will be unable to 
> > > > > > > > > > > > > > > > > > > > > > > > optimize this huge amount of 
> > > > > > > > > > > > > > > > > > > > > > > > code because the codegen relies 
> > > > > > > > > > > > > > > > > > > > > > > > on the runtime functions and 
> > > > > > > > > > > > > > > > > > > > > > > > the code cannot be inlined. 
> > > > > > > > > > > > > > > > > > > > > > > > That's why I would like to move 
> > > > > > > > > > > > > > > > > > > > > > > > as much as possible code to the 
> > > > > > > > > > > > > > > > > > > > > > > > runtime rather than to emit it 
> > > > > > > > > > > > > > > > > > > > > > > > in the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I 
> > > > > > > > > > > > > > > > > > > > > > > think this is the best we can do 
> > > > > > > > > > > > > > > > > > > > > > > right now.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > > > > > > > > > > > > > > > > > > > > > > when we have nested mappers 
> > > > > > > > > > > > > > > > > > > > > > > within each other. In this case, 
> > > > > > > > > > > > > > > > > > > > > > > a mapper function will call 
> > > > > > > > > > > > > > > > > > > > > > > another mapper function. We can 
> > > > > > > > > > > > > > > > > > > > > > > inline the inner mapper functions 
> > > > > > > > > 

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D63856#1560213 , @erik.pilkington 
wrote:

> In D63856#1560180 , @rjmccall wrote:
>
> > This only applies to relational operators, right?  I'm a little 
> > uncomfortable with calling this "tautological" since it's not like it's 
> > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as long 
> > as we aren't warning about reasonable idioms that are intended to handle 
> > unfortunate situations — like other code that might have left a non-`{0,1}` 
> > value in the `BOOL` — I think this is fine.
>
>
> I think the party line is that it is undefined behaviour (in some sense), 
> since UBSan will happily crash if you try to load a non-boolean value from a 
> BOOL.


What?  Since when?

> It is a bit unfortunate that "defensive" code will start warning here though 
> :/. Maybe we can try to detect and permit something like `B < NO || B > YES`, 
> or emit a note with some canonical way of checking for non-boolean BOOLs. 
> Even if we end up having to disable it default, I think its still a good 
> diagnostic to have. A warning on stores to BOOL would probably be a lot 
> higher value, though.

I'm not sure this is a problem because I'm not sure there's any reason to write 
defensive code besides `B != NO` or `B == NO`.  It's potentially problematic if 
someone writes `B == YES`, though.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Currently 
> > > > > > > > > > > > > > > > > > > > > > > > > > > `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > > > > generated by the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > > > > > > > instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > > > > > an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme 
> > > > > > > > > > > > > > > > > > > > > > > > > > will be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > > > components as an argument 
> > > > > > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, 
> > > > > > > > > > > > > > > > > > > > > > > > > > it means that the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > > needs to generate all 
> > > > > > > > > > > > > > > > > > > > > > > > > > components related to a map 
> > > > > > > > > > > > > > > > > > > > > > > > > > clause. I don't think the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other 
> > > > > > > > > > > > > > > > > > > > > > > > > > hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > > > > > scheme, these components 
> > > > > > > > > > > > > > > > > > > > > > > > > > are naturally generated by 
> > > > > > > > > > > > > > > > > > > > > > > > > > the compiler, and the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we 
> > > > > > > > > > > > > > > > > > > > > > > > > may end with the code 
> > > > > > > > > > > > > > > > > > > > > > > > > blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > > > > > > > very similar code for 
> > > > > > > > > > > > > > > > > > > > > > > > > different types and 
> > > > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing 
> > > > > > > > > > > > > > > > > > > > > > > > > here is that we will be 
> > > > > > > > > > > > > > > > > > > > > > > > > unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > > > > > > > amount of code because the 
> > > > > > > > > > > > > > > > > > > > > > > > > codegen relies on the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > functions and the code cannot 
> > > > > > > > > > > > > > > > > > > > > > > > > be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I 
> > > > > > > > > > > > > > > > > > > > > > > > think this is the best we can 
> > > > > > > > > > > > > > > > > > > > > > > > do right now.
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > >

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

[Alex Strelnikov via Phabricator via cfe-commits]

astrelni updated this revision to Diff 206889.

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

https://reviews.llvm.org/D62977

Files:
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-upgrade-googletest-case.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest.h
  
clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest.h
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
@@ -28,6 +28,7 @@
 "OverloadedUnaryAndCheck.cpp",
 "TodoCommentCheck.cpp",
 "UnnamedNamespaceInHeaderCheck.cpp",
+"UpgradeGoogletestCaseCheck.cpp",
 "UsingNamespaceDirectiveCheck.cpp",
   ]
 }
Index: clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
@@ -0,0 +1,1016 @@
+// RUN: %check_clang_tidy %s google-upgrade-googletest-case %t -- -- -I%S/Inputs
+// RUN: %check_clang_tidy -check-suffix=NOSUITE %s google-upgrade-googletest-case %t -- -- -DNOSUITE -I%S/Inputs/gtest/nosuite
+
+#include "gtest/gtest.h"
+
+// When including a version of googletest without the replacement names, this
+// check should not produce any diagnostics. The following dummy fix is present
+// because `check_clang_tidy.py` requires at least one warning, fix or note. 
+void Dummy() {}
+// CHECK-FIXES-NOSUITE: void Dummy() {}
+
+// 
+// Macros
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case' are deprecated; use equivalent APIs named with 'suite'
+// CHECK-FIXES: TYPED_TEST_SUITE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: TYPED_TEST_SUITE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: REGISTER_TYPED_TEST_SUITE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: INSTANTIATE_TYPED_TEST_SUITE_P(FooPrefix, FooTest, FooTypes);
+
+#ifdef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE(CaseName, Types, ...)
+#endif
+
+#ifdef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE_P(SuiteName)
+#endif
+
+#ifdef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define REGISTER_TYPED_TEST_CASE_P(SuiteName, ...)
+#endif
+
+#ifdef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define INSTANTIATE_TYPED_TEST_CASE_P(Prefix, SuiteName, Types, ...)
+#endif
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+
+// 
+// testing::Test
+
+class FooTest : public testing::Test {
+public:
+  static void SetUpTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void SetUpTestSuite();
+  static void TearDownTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void TearDownTestSuite();
+};
+
+void FooTest::SetUpTest

[PATCH] D62960: SVE opaque type for C intrinsics demo

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm updated this revision to Diff 206891.
rsandifo-arm added a comment.

- Fix comments in AArch64SVEACLETypes.def
- Rename BUILTIN_TYPE to SVE_TYPE and use it where possible
- Report errors for TODOs instead of using llvm_unreachable
- Add a test for the errors
- Formatting fixes


Repository:
  rC Clang

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

https://reviews.llvm.org/D62960

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/AArch64SVEACLETypes.def
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/PrintfFormatString.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Index/USRGeneration.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExpr.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/CodeGen/aarch64-sve.c
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1527,6 +1527,9 @@
   case BuiltinType::OCLClkEvent:
   case BuiltinType::OCLQueue:
   case BuiltinType::OCLReserveID:
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(Id, SingletonId)
 #define SIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define UNSIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
Index: test/CodeGen/aarch64-sve.c
===
--- /dev/null
+++ test/CodeGen/aarch64-sve.c
@@ -0,0 +1,9 @@
+// RUN: not %clang_cc1 -triple arm64-none-linux-gnu -target-feature +sve \
+// RUN:  -emit-llvm -o - %s -debug-info-kind=limited 2>&1 | FileCheck %s
+
+// Placeholder test for SVE types
+
+// CHECK: cannot yet generate code for SVE type '__SVInt8_t'
+// CHECK: cannot yet generate debug info for SVE type '__SVInt8_t'
+
+__SVInt8_t *ptr;
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7037,6 +7037,12 @@
 case PREDEF_TYPE_OMP_ARRAY_SECTION:
   T = Context.OMPArraySectionTy;
   break;
+// SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) \
+case PREDEF_TYPE_##Id##_ID: \
+  T = Context.SingletonId; \
+  break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
 }
 
 assert(!T.isNull() && "Unknown predefined type");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -232,6 +232,12 @@
   case BuiltinType::OCLReserveID:
 ID = PREDEF_TYPE_RESERVE_ID_ID;
 break;
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) \
+  case BuiltinType::Id: \
+ID = PREDEF_TYPE_##Id##_ID; \
+break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
   case BuiltinType::BuiltinFn:
 ID = PREDEF_TYPE_BUILTIN_FN;
 break;
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -5243,6 +5243,9 @@
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
   case BuiltinType::Id:
 #include "clang/Basic/OpenCLExtensionTypes.def"
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define PLACEHOLDER_TYPE(ID, SINGLETON_ID)
 #define BUILTIN_TYPE(ID, SINGLETON_ID) case BuiltinType::ID:
 #include "clang/AST/BuiltinTypes.def"
@@ -17049,6 +17052,9 @@
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
   case BuiltinType::Id:
 #include "clang/Basic/OpenCLExtensionTypes.def"
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define PLACEHOLDER_TYPE(Id, SingletonId)
 #include "clang/AST/BuiltinTypes.def"
Index: lib/Sema/Sema.cpp
===
--- lib/Sema/Sema.cpp
+++ lib/Sema/Sema.cpp
@@ -336,7 +336,13 @@
 addImplicitTypedef(#ExtType, Context.Id##Ty); \
 setOpenCLExtensionForType(Context.Id##Ty, #Ext);
 #include "clang/Basic/OpenCLExtensionTypes.def"
-};
+  }
+
+  // SVE Types
+  // TODO: Check target?
+#define SVE_TYPE(Name, Id, SingletonId) \
+  addImplicitTypedef(Name, Context.SingletonId);
+#include "clang/Basic/AArch64SVEACLETypes.def"
 
   if (Context.getTargetInfo().hasBuiltinMSVaList()) {
 DeclarationName MSVaList = &Context.Idents.get("__builtin_ms_va_list");
Index: lib/Index/USRGeneration.cpp
===
--- lib/Inde

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

[Alex Strelnikov via Phabricator via cfe-commits]

astrelni marked 4 inline comments as done.
astrelni added a comment.

In D62977#1560879 , @lebedev.ri wrote:

> Looks reasonable. I did not review the check itself though.
>  Are `test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp` and 
> `test/clang-tidy/google-upgrade-googletest-case.cpp ` identical other than 
> the included header and expected output?
>  I'd recommend to condense it into a single file, and just have two `RUN` 
> lines each one checking different message prefixes


The nosuite test was a strict subset. I've combined them with a few lines that 
needed to be turned via preprocessor branches. Thank you, I actually wasn't 
aware that these tests can have multiple `RUN` lines.




Comment at: clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h:34
+private:
+  std::unordered_set MatchedTemplateLocations;
+};

lebedev.ri wrote:
> Have you tried `llvm::DenseSet` instead?
> This //may// not matter *here*, but `std::unordered_set` usually results in 
> horrible perf.
Thanks, I wasn't aware of what is available.



Comment at: 
clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp:9
+void DummyFixTarget() {}
+// CHECK-FIXES: void DummyFixTarget() {}
+

lebedev.ri wrote:
> Hm?
I added a comment to better explain this in the combined test. 
check_clang_tidy.py asserts that there is at least one message, fix or note 
comment present in the file. If there isn't one, the script returns without 
even running the test. I couldn't see an option to pass that would turn of this 
check, please let me know if you are aware of one.


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

https://reviews.llvm.org/D62977



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

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added a comment.

In D63856#1561112 , @rjmccall wrote:

> In D63856#1560213 , @erik.pilkington 
> wrote:
>
> > In D63856#1560180 , @rjmccall 
> > wrote:
> >
> > > This only applies to relational operators, right?  I'm a little 
> > > uncomfortable with calling this "tautological" since it's not like it's 
> > > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as long 
> > > as we aren't warning about reasonable idioms that are intended to handle 
> > > unfortunate situations — like other code that might have left a 
> > > non-`{0,1}` value in the `BOOL` — I think this is fine.
> >
> >
> > I think the party line is that it is undefined behaviour (in some sense), 
> > since UBSan will happily crash if you try to load a non-boolean value from 
> > a BOOL.
>
>
> What?  Since when?


https://reviews.llvm.org/D27607

> 
> 
>> It is a bit unfortunate that "defensive" code will start warning here though 
>> :/. Maybe we can try to detect and permit something like `B < NO || B > 
>> YES`, or emit a note with some canonical way of checking for non-boolean 
>> BOOLs. Even if we end up having to disable it default, I think its still a 
>> good diagnostic to have. A warning on stores to BOOL would probably be a lot 
>> higher value, though.
> 
> I'm not sure this is a problem because I'm not sure there's any reason to 
> write defensive code besides `B != NO` or `B == NO`.  It's potentially 
> problematic if someone writes `B == YES`, though.

I was thinking about something like the following, which probably isn't worth 
warning on. Another way of handling it would be only emitting the diagnostic if 
`!InRange`. Not exactly sure how common that pattern actually is though.

  void myAPI(BOOL DoAThing) {
if (DoAThing > YES || DoAThing < NO) DoAThing = YES;
// ...
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D62960: SVE opaque type for C intrinsics demo

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm marked 7 inline comments as done.
rsandifo-arm added a comment.

Thanks for the reviews!




Comment at: include/clang/Basic/AArch64SVEACLETypes.def:10
+//
+//  This file defines the database about various builtin singleton types.
+//

rovka wrote:
> You can be more specific :)
Yeah, there were a few cut-&-pastos here, sorry.  Hopefully fixed in the 
updated version.



Comment at: include/clang/Basic/AArch64SVEACLETypes.def:29
+#define SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP)\
+  BUILTIN_TYPE(Name, Id, SingletonId)
+#endif

rovka wrote:
> Maybe use SVE_TYPE instead of BUILTIN_TYPE, to avoid any confusion?  You 
> can't re-use a defition of BUILTIN_TYPE between this header and 
> BuiltinTypes.def anyway, since they both undefine it at the end.
Yeah, that's definitely better, especially given the different number of 
arguments.  Done in the updated version.



Comment at: lib/AST/ASTContext.cpp:6645
+  case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(KIND, ID)

rovka wrote:
> Here and in most other places: no need for 2 defines, you can just #define 
> BUILTIN_TYPE (or if you choose to rename it to SVE_TYPE) since it's the same 
> code for both vectors and predicates.
Thanks, that shaved quite a lot of lines off the patch :-)



Comment at: lib/AST/ItaniumMangle.cpp:2680
+break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

rovka wrote:
> erik.pilkington wrote:
> > rsandifo-arm wrote:
> > > erik.pilkington wrote:
> > > > jfb wrote:
> > > > > @rjmccall you probably should review this part.
> > > > Sorry for the drive by comment, but: All of these mangling should 
> > > > really be using the "vendor extension" production IMO:
> > > > 
> > > > ` ::= u `
> > > > 
> > > > As is, these manglings intrude on the users's namespace, (i.e. if they 
> > > > had a type named `objc_selector` or something), and confuse demanglers 
> > > > which incorrectly assume these are substitutable (vendor extension 
> > > > builtin types are substitutable too though, but that should be handled 
> > > > here).
> > > It isn't obvious from the patch, but the SVE names that we're mangling 
> > > are predefined names like __SVInt8_t. rather than user-facing names like 
> > > svint8_t  The predefined names and their mangling are defined by the 
> > > platform ABI (https://developer.arm.com/docs/100986/), so it wouldn't 
> > > be valid for another part of the implementation to use those names for 
> > > something else.
> > > 
> > > I realise you were making a general point here though, sorry.
> > > 
> > The mangling in the document you linked does use the vendor extension 
> > production here though, i.e. the example is `void f(int8x8_t)`, which 
> > mangles to _Z1f**u10__Int8x8_t**. It is true that this shouldn't ever 
> > collide with another mangling in practice, but my point is there isn't any 
> > need to smuggle it into the mangling by pretending it's a user defined 
> > type, when the itanium grammar and related tools have a special way for 
> > vendors to add builtin types.
> I agree with Erik here, the example in the PCS document seems to suggest 
> using u. I think either the patch needs to be updated or the document needs 
> to be more clear about what the mangling is supposed to look like.
Thanks for highlighting this problem, and sorry for not noticing myself when 
pointing you at the doc.

Unfortunately, the specification and implementation already difer for the 
Advanced SIMD types, with both clang and GCC omitting the 'u' despite the spec 
saying it should be present.  So we're considering changing the spec to match 
what's now the de facto ABI.

For SVE we do still have the opportunity to use 'u'.  I've left it as-is for 
now though, until we've reached a decision about whether to follow existing 
practice for Advanced SIMD or whether to do what the spec says.



Comment at: lib/AST/MicrosoftMangle.cpp:2110
+llvm_unreachable("mangling an sve type not yet supported");
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

rovka wrote:
> Should we have llvm_unreachable or report a proper error? I like the 
> unreachable if we're checking elsewhere that SVE isn't supported on Windows, 
> but I notice we report errors for some of the other types.
Fixed to report the error, since this wouldn't be trapped earlier.



Comment at: lib/CodeGen/CGDebugInfo.cpp:709
+  case BuiltinType::Id: \
+return nullptr;
+#include "clang/Basic/AArch64SVEACLETypes.def"

rovka wrote:
> I don't really know this code, but I can't help but notice that nullptr is 
> only ever used for the void type. Is it safe to also use it for the SVE 
> types, or can we do something else instead?
Fixed to report an error here too and return a "safe" value until the TODO 

[PATCH] D62961: [AST] Add new Type queries for sizeless types

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm updated this revision to Diff 206894.
rsandifo-arm added a comment.

- Update for new version of D62960 


Repository:
  rC Clang

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

https://reviews.llvm.org/D62961

Files:
  include/clang/AST/CanonicalType.h
  include/clang/AST/Type.h
  lib/AST/Type.cpp
  unittests/AST/CMakeLists.txt
  unittests/AST/SizelessTypesTest.cpp

Index: unittests/AST/SizelessTypesTest.cpp
===
--- /dev/null
+++ unittests/AST/SizelessTypesTest.cpp
@@ -0,0 +1,105 @@
+//===- unittests/AST/SizelessTypesTest.cpp --- Sizeless type 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
+//
+//===--===//
+//
+// This file contains tests for clang::Type queries related to sizeless types.
+//
+//===--===//
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Type.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+struct SizelessTypeTester : public ::testing::Test {
+  // Declare an incomplete structure type.
+  std::unique_ptr AST = tooling::buildASTFromCode("struct foo;");
+  ASTContext &Ctx = AST->getASTContext();
+  TranslationUnitDecl &TU = *Ctx.getTranslationUnitDecl();
+  TypeDecl *Foo = cast(TU.lookup(&Ctx.Idents.get("foo")).front());
+  const Type *FooTy = Foo->getTypeForDecl();
+};
+
+TEST_F(SizelessTypeTester, TestSizeless) {
+  ASSERT_TRUE(Ctx.SveInt8Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveUint8Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveFloat16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveFloat32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveFloat64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveBoolTy->isSizelessType());
+
+  ASSERT_FALSE(Ctx.VoidTy->isSizelessType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isSizelessType());
+  ASSERT_FALSE(FooTy->isSizelessType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isSizelessType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isSizelessType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isSizelessType());
+}
+
+TEST_F(SizelessTypeTester, TestIndefinite) {
+  ASSERT_FALSE(Ctx.SveInt8Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveUint8Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveFloat16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveFloat32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveFloat64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveBoolTy->isIndefiniteType());
+
+  ASSERT_TRUE(Ctx.VoidTy->isIndefiniteType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isIndefiniteType());
+  ASSERT_TRUE(FooTy->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isIndefiniteType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isIndefiniteType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isIndefiniteType());
+}
+
+TEST_F(SizelessTypeTester, TestIncomplete) {
+  ASSERT_TRUE(Ctx.SveInt8Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveUint8Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveFloat16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveFloat32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveFloat64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveBoolTy->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.VoidTy->isIncompleteType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isIncompleteType());
+  ASSERT_TRUE(FooTy->isIncompleteType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isIncompleteType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isIncompleteType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isIncompleteType());
+}
Index: unittests/AST/CMakeLists.txt
=

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D63856#1561132 , @erik.pilkington 
wrote:

> In D63856#1561112 , @rjmccall wrote:
>
> > In D63856#1560213 , 
> > @erik.pilkington wrote:
> >
> > > In D63856#1560180 , @rjmccall 
> > > wrote:
> > >
> > > > This only applies to relational operators, right?  I'm a little 
> > > > uncomfortable with calling this "tautological" since it's not like it's 
> > > > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as 
> > > > long as we aren't warning about reasonable idioms that are intended to 
> > > > handle unfortunate situations — like other code that might have left a 
> > > > non-`{0,1}` value in the `BOOL` — I think this is fine.
> > >
> > >
> > > I think the party line is that it is undefined behaviour (in some sense), 
> > > since UBSan will happily crash if you try to load a non-boolean value 
> > > from a BOOL.
> >
> >
> > What?  Since when?
>
>
> https://reviews.llvm.org/D27607


Interesting; I'm not sure I find that convincing.  Probably the least 
convincing part is where it links to its own behavioral documentation as 
justification for doing what it does.  But okay, I guess we do this.

>>> It is a bit unfortunate that "defensive" code will start warning here 
>>> though :/. Maybe we can try to detect and permit something like `B < NO || 
>>> B > YES`, or emit a note with some canonical way of checking for 
>>> non-boolean BOOLs. Even if we end up having to disable it default, I think 
>>> its still a good diagnostic to have. A warning on stores to BOOL would 
>>> probably be a lot higher value, though.
>> 
>> I'm not sure this is a problem because I'm not sure there's any reason to 
>> write defensive code besides `B != NO` or `B == NO`.  It's potentially 
>> problematic if someone writes `B == YES`, though.
> 
> I was thinking about something like the following, which probably isn't worth 
> warning on. Another way of handling it would be only emitting the diagnostic 
> if `!InRange`. Not exactly sure how common that pattern actually is though.
> 
>   void myAPI(BOOL DoAThing) {
> if (DoAThing > YES || DoAThing < NO) DoAThing = YES;
> // ...
>   }

I don't think it's a problem to warn about this; this is just a silly way of 
writing `if (DoAThing != NO) { DoAThing = YES; }`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 206895.
lildmh added a comment.

Change the type of size from `size_t` to `int64_t`, and rebase


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

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fope

[PATCH] D62829: [clang-tidy] Check for dynamically initialized statics in headers.

[Charles Zhang via Phabricator via cfe-commits]

czhang added a comment.

ping


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

https://reviews.llvm.org/D62829



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

r364575 - [OPENMP]Generate correctly implicit flags for mapped data.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Thu Jun 27 11:53:07 2019
New Revision: 364575

URL: http://llvm.org/viewvc/llvm-project?rev=364575&view=rev
Log:
[OPENMP]Generate correctly implicit flags for mapped data.

Implicit flag must not be emitted for explicitly specified firstprivate
variables, but for implicitly captured sizes of the VLAs.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/test/OpenMP/nvptx_lambda_capturing.cpp
cfe/trunk/test/OpenMP/target_codegen.cpp
cfe/trunk/test/OpenMP/target_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/target_map_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_codegen.cpp
cfe/trunk/test/OpenMP/target_simd_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_simd_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=364575&r1=364574&r2=364575&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Jun 27 11:53:07 2019
@@ -7155,7 +7155,9 @@ private:
   CodeGenFunction &CGF;
 
   /// Set of all first private variables in the current directive.
-  llvm::SmallPtrSet FirstPrivateDecls;
+  /// bool data is set to true if the variable is implicitly marked as
+  /// firstprivate, false otherwise.
+  llvm::DenseMap, bool> FirstPrivateDecls;
 
   /// Map between device pointer declarations and their expression components.
   /// The key value for declarations in 'this' is null.
@@ -7836,8 +7838,8 @@ public:
 // Extract firstprivate clause information.
 for (const auto *C : Dir.getClausesOfKind())
   for (const auto *D : C->varlists())
-FirstPrivateDecls.insert(
-
cast(cast(D)->getDecl())->getCanonicalDecl());
+FirstPrivateDecls.try_emplace(
+cast(cast(D)->getDecl()), C->isImplicit());
 // Extract device pointer clause information.
 for (const auto *C : Dir.getClausesOfKind())
   for (auto L : C->component_lists())
@@ -8354,6 +8356,7 @@ public:
   MapValuesArrayTy &CurPointers,
   MapValuesArrayTy &CurSizes,
   MapFlagsArrayTy &CurMapTypes) const {
+bool IsImplicit = true;
 // Do the default mapping.
 if (CI.capturesThis()) {
   CurBasePointers.push_back(CV);
@@ -8379,6 +8382,10 @@ public:
 CurMapTypes.push_back(OMP_MAP_NONE);
 CurSizes.push_back(llvm::Constant::getNullValue(CGF.Int64Ty));
   }
+  const VarDecl *VD = CI.getCapturedVar();
+  auto I = FirstPrivateDecls.find(VD);
+  if (I != FirstPrivateDecls.end())
+IsImplicit = I->getSecond();
 } else {
   assert(CI.capturesVariable() && "Expected captured reference.");
   const auto *PtrTy = cast(RI.getType().getTypePtr());
@@ -8390,7 +8397,8 @@ public:
   // type, the default is 'tofrom'.
   CurMapTypes.push_back(getMapModifiersForPrivateClauses(CI));
   const VarDecl *VD = CI.getCapturedVar();
-  if (FirstPrivateDecls.count(VD) &&
+  auto I = FirstPrivateDecls.find(VD);
+  if (I != FirstPrivateDecls.end() &&
   VD->getType().isConstant(CGF.getContext())) {
 llvm::Constant *Addr =
 CGF.CGM.getOpenMPRuntime().registerTargetFirstprivateCopy(CGF, VD);
@@ -8404,7 +8412,7 @@ public:
 CurPointers.push_back(Addr);
   } else {
 CurBasePointers.push_back(CV);
-if (FirstPrivateDecls.count(VD) && ElementType->isAnyPointerType()) {
+if (I != FirstPrivateDecls.end() && ElementType->isAnyPointerType()) {
   Address PtrAddr = CGF.EmitLoadOfReference(CGF.MakeAddrLValue(
   CV, ElementType, CGF.getContext().getDeclAlign(VD),
   AlignmentSource::Decl));
@@ -8413,12 +8421,15 @@ public:
   CurPointers.push_back(CV);
 }
   }
+  if (I != FirstPrivateDecls.end())
+IsImplicit = I->getSecond();
 }
 // Every default map produces a single argument which is a target 
parameter.
 CurMapTypes.back() |= OMP_MAP_TARGET_PARAM;
 
 // Add flag stating this is an implicit map.
-CurMapTypes.back() |= OMP_MAP_IMPLICIT;
+if (IsImplicit)
+  CurMapTypes.back() |= OMP_MAP_IMPLICIT;
   }
 };
 } // anonymous namespace
@@ -8884,7 +8895,8 @@ void CGOpenMPRuntime::emitTargetCall(Cod
 CGF.getTypeSize(RI->getType()), CGF.Int64Ty, /*isSigned=*/true));
 // Copy to the device as an argument. No need to retrieve it.
 CurMapTypes.push_back(MappableExprsHandler::OMP_MAP_LITERAL |
-  MappableExprsHandler::OMP_MAP_TARGET_PARAM);
+

[PATCH] D63538: [analyzer][CFG] Return the correct terminator condition

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

This change will be really useful for the lifetime analysis as well! Thanks!

I have one concern though. The analyzer is using linerarized (or threaded) CFGs 
with every subexpression being a separate entry in the basic blocks. Will your 
change give sensible answers for non-linearized CFGs? If not, this should be 
documented. Do we have users of this API with non-linearized CFGs?


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

https://reviews.llvm.org/D63538



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

[PATCH] D63889: Check possible warnings on global initializers for reachability

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Create CFG for initializers and perform analysis based warnings on global 
variables


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63889

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Sema/AnalysisBasedWarnings.h
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/warn-unreachable-warning-var-decl.cpp

Index: clang/test/Sema/warn-unreachable-warning-var-decl.cpp
===
--- /dev/null
+++ clang/test/Sema/warn-unreachable-warning-var-decl.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -verify %s
+int e = 1 ? 0 : 1/0;
+int g = 1 ? 1/0 : 0;// expected-warning{{division by zero is undefined}}
+
+#define SHIFT(n)(((n) == 32) ? 0 : ((1<<(n))-1))
+
+int x = SHIFT(32);
+int y = SHIFT(0);
+
+// FIXME: Expressions in lambdas aren't ignored
+int z = [](){
+  return 1 ? 0 : 1/0; // expected-warning{{division by zero is undefined}}
+}();
+
+int f(void)
+{
+int x = 1 ? 0 : 1/0;
+return x;
+}
+
+template
+struct X0 {
+static T value;
+};
+
+template
+struct X1 {
+static T value;
+};
+
+template
+T X0::value = 3.14; // expected-warning{{implicit conversion from 'double' to 'int' changes value from 3.14 to 3}}
+
+template
+T X1::value = 1 ? 0 : 1/0;
+
+template struct X0; // expected-note{{in instantiation of static data member 'X0::value' requested here}}
+
+constexpr signed char c1 = 100 * 2; // ok expected-warning{{changes value}}
+constexpr signed char c2 = '\x64' * '\2'; // also ok  expected-warning{{changes value}}
+constexpr int shr_32 = 0 >> 32; // expected-error {{constant expression}} expected-note {{shift count 32 >= width of type}}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -4881,6 +4881,8 @@
"default argument expression has capturing blocks?");
   }
 
+  AnalysisWarnings.IssueWarningsForRegisteredVarDecl(Param);
+
   // We already type-checked the argument, so we know it works.
   // Just mark all of the declarations in this potentially-evaluated expression
   // as being "referenced".
@@ -16662,7 +16664,7 @@
   case ExpressionEvaluationContext::PotentiallyEvaluatedIfUsed:
 if (!Stmts.empty() && getCurFunctionOrMethodDecl()) {
   FunctionScopes.back()->PossiblyUnreachableDiags.
-push_back(sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
+push_back(clang::sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
   return true;
 }
 
@@ -16671,17 +16673,36 @@
 // but nonetheless is always required to be a constant expression, so we
 // can skip diagnosing.
 // FIXME: Using the mangling context here is a hack.
+//
+// Mangling context seems to only be defined on constexpr vardecl that
+// displayed errors
+// This skips warnings that were already emitted as notes on errors.
 if (auto *VD = dyn_cast_or_null(
 ExprEvalContexts.back().ManglingContextDecl)) {
   if (VD->isConstexpr() ||
   (VD->isStaticDataMember() && VD->isFirstDecl() && !VD->isInline()))
 break;
+}
+
+// For any other kind of variable, we should build a CFG for its
+// initializer and check whether the context in question is reachable.
+if(auto *VD = dyn_cast_or_null(
+CurContext->getLastDecl())) {
+  if(VD->getDefinition()) {
+VD = VD->getDefinition();
+  }
   // FIXME: For any other kind of variable, we should build a CFG for its
   // initializer and check whether the context in question is reachable.
+  // Some cases aren't picked up by path analysis currently
+  if(!Stmts.empty() && VD->isFileVarDecl()) {
+AnalysisWarnings.RegisterVarDeclWarning(VD, clang::sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
+return true;
+  }
 }
 
 Diag(Loc, PD);
 return true;
+
   }
 
   return false;
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -288,6 +288,9 @@
 UnparsedDefaultArgInstantiations.erase(InstPos);
   }
 
+  // Check for delayed warnings
+  AnalysisWarnings.IssueWarningsForRegisteredVarDecl(Param);
+
   return false;
 }
 
@@ -333,7 +336,21 @@
 return;
   }
 
+  // Temporarily change the context and add param to it
+  // Allows DiagRuntimeBehavior to register this param with
+  // any possibly warnings
+  // Param gets added back to context when function is added
+  // to context
+  // FIXME: Params should probably be diagnosed after being
+  // actually added to context. Either params get added to
+  // context before the function sc

[PATCH] D62293: [modules] Add PP callbacks for entering and leaving a submodule.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 206887.
v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

Add comments, add missing callbacks. Thanks Richard!


Repository:
  rC Clang

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

https://reviews.llvm.org/D62293

Files:
  include/clang/Lex/PPCallbacks.h
  lib/Lex/PPLexerChange.cpp


Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -647,6 +647,8 @@
 BuildingSubmoduleStack.push_back(
 BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
   PendingModuleMacroNames.size()));
+if (Callbacks)
+  Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
 return;
   }
 
@@ -691,6 +693,9 @@
   BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
 PendingModuleMacroNames.size()));
 
+  if (Callbacks)
+Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
+
   // Switch to this submodule as the current submodule.
   CurSubmoduleState = &State;
 
@@ -731,6 +736,10 @@
 // are tracking macro visibility, don't build any, and preserve the list
 // of pending names for the surrounding submodule.
 BuildingSubmoduleStack.pop_back();
+
+if (Callbacks)
+  Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
 makeModuleVisible(LeavingMod, ImportLoc);
 return LeavingMod;
   }
@@ -815,6 +824,9 @@
 
   BuildingSubmoduleStack.pop_back();
 
+  if (Callbacks)
+Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
   // A nested #include makes the included submodule visible.
   makeModuleVisible(LeavingMod, ImportLoc);
   return LeavingMod;
Index: include/clang/Lex/PPCallbacks.h
===
--- include/clang/Lex/PPCallbacks.h
+++ include/clang/Lex/PPCallbacks.h
@@ -132,6 +132,28 @@
   SrcMgr::CharacteristicKind FileType) {
   }
 
+  /// Callback invoked whenever a submodule was entered.
+  ///
+  /// \param M The submodule we have entered.
+  ///
+  /// \param ImportLoc The location of import directive token.
+  ///
+  /// \param ForPragma If entering from pragma directive.
+  ///
+  virtual void EnteredSubmodule(Module *M, SourceLocation ImportLoc,
+bool ForPragma) { }
+
+  /// Callback invoked whenever a submodule was left.
+  ///
+  /// \param M The submodule we have left.
+  ///
+  /// \param ImportLoc The location of import directive token.
+  ///
+  /// \param ForPragma If entering from pragma directive.
+  ///
+  virtual void LeftSubmodule(Module *M, SourceLocation ImportLoc,
+ bool ForPragma) { }
+
   /// Callback invoked whenever there was an explicit module-import
   /// syntax.
   ///
@@ -395,6 +417,18 @@
Imported, FileType);
   }
 
+  void EnteredSubmodule(Module *M, SourceLocation ImportLoc,
+bool ForPragma) override {
+First->EnteredSubmodule(M, ImportLoc, ForPragma);
+Second->EnteredSubmodule(M, ImportLoc, ForPragma);
+  }
+
+  void LeftSubmodule(Module *M, SourceLocation ImportLoc,
+ bool ForPragma) override {
+First->LeftSubmodule(M, ImportLoc, ForPragma);
+Second->LeftSubmodule(M, ImportLoc, ForPragma);
+  }
+
   void moduleImport(SourceLocation ImportLoc, ModuleIdPath Path,
 const Module *Imported) override {
 First->moduleImport(ImportLoc, Path, Imported);


Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -647,6 +647,8 @@
 BuildingSubmoduleStack.push_back(
 BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
   PendingModuleMacroNames.size()));
+if (Callbacks)
+  Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
 return;
   }
 
@@ -691,6 +693,9 @@
   BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
 PendingModuleMacroNames.size()));
 
+  if (Callbacks)
+Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
+
   // Switch to this submodule as the current submodule.
   CurSubmoduleState = &State;
 
@@ -731,6 +736,10 @@
 // are tracking macro visibility, don't build any, and preserve the list
 // of pending names for the surrounding submodule.
 BuildingSubmoduleStack.pop_back();
+
+if (Callbacks)
+  Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
 makeModuleVisible(LeavingMod, ImportLoc);
 return LeavingMod;
   }
@@ -815,6 +824,9 @@
 
   BuildingSubmoduleStack.pop_back();
 
+  if (Callbacks)
+Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
   // A nested #include makes the included submodule visible.
   m

[PATCH] D63892: [LibTooling] Extend `RewriteRule` with support for adding includes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: ilya-biryukov, gribozavr.
Herald added a project: clang.

This revision allows users to specify the insertion of an included directive (at
the top of the file being rewritten) as part of a rewrite rule.  These
directives are bundled with `RewriteRule` cases, so that different cases can
potentially result in different include actions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63892

Files:
  clang/include/clang/Tooling/Refactoring/Transformer.h
  clang/lib/Tooling/Refactoring/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -198,6 +198,42 @@
   testRule(std::move(Rule), Input, Expected);
 }
 
+TEST_F(TransformerTest, AddIncludeQuoted) {
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")));
+  addInclude(Rule, "clang/OtherLib.h");
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include "clang/OtherLib.h"
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  testRule(Rule, Input, Expected);
+}
+
+TEST_F(TransformerTest, AddIncludeAngled) {
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")));
+  addInclude(Rule, "clang/OtherLib.h", IncludeFormat::Angled);
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include 
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  testRule(Rule, Input, Expected);
+}
+
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
   RewriteRule Rule = makeRule(functionDecl(hasName("bad")).bind(Fun),
Index: clang/lib/Tooling/Refactoring/Transformer.cpp
===
--- clang/lib/Tooling/Refactoring/Transformer.cpp
+++ clang/lib/Tooling/Refactoring/Transformer.cpp
@@ -98,8 +98,14 @@
 
 RewriteRule tooling::makeRule(DynTypedMatcher M, SmallVector Edits,
   TextGenerator Explanation) {
-  return RewriteRule{{RewriteRule::Case{std::move(M), std::move(Edits),
-std::move(Explanation)}}};
+  return RewriteRule{{RewriteRule::Case{
+  std::move(M), std::move(Edits), std::move(Explanation), {;
+}
+
+void tooling::addInclude(RewriteRule &Rule, StringRef Header,
+ IncludeFormat Format) {
+  for (auto &Case : Rule.Cases)
+Case.AddedIncludes.emplace_back(Header.str(), Format);
 }
 
 // Determines whether A is a base type of B in the class hierarchy, including
@@ -217,8 +223,8 @@
   Root->second.getSourceRange().getBegin());
   assert(RootLoc.isValid() && "Invalid location for Root node of match.");
 
-  auto Transformations = tooling::detail::translateEdits(
-  Result, tooling::detail::findSelectedCase(Result, Rule).Edits);
+  RewriteRule::Case Case = tooling::detail::findSelectedCase(Result, Rule);
+  auto Transformations = tooling::detail::translateEdits(Result, Case.Edits);
   if (!Transformations) {
 Consumer(Transformations.takeError());
 return;
@@ -241,5 +247,17 @@
 }
   }
 
+  for (const auto &I : Case.AddedIncludes) {
+auto &Header = I.first;
+switch (I.second) {
+  case IncludeFormat::Quoted:
+AC.addHeader(Header);
+break;
+  case IncludeFormat::Angled:
+AC.addHeader((llvm::Twine("<") + Header + ">").str());
+break;
+}
+  }
+
   Consumer(std::move(AC));
 }
Index: clang/include/clang/Tooling/Refactoring/Transformer.h
===
--- clang/include/clang/Tooling/Refactoring/Transformer.h
+++ clang/include/clang/Tooling/Refactoring/Transformer.h
@@ -86,6 +86,12 @@
   TextGenerator Note;
 };
 
+/// Format of the path in an include directive -- angle brackets or quotes.
+enum class IncludeFormat {
+  Quoted,
+  Angled,
+};
+
 /// Description of a source-code transformation.
 //
 // A *rewrite rule* describes a transformation of source code. A simple rule
@@ -114,6 +120,10 @@
 ast_matchers::internal::DynTypedMatcher Matcher;
 SmallVector Edits;
 TextGenerator Explanation;
+// Include paths that to add to the file affected by this case.  These are
+// bundled with the `Case`, rather than the `RewriteRule`, because each case
+// might have different associated changes to the includes.
+std::vector> AddedIncludes;
   };
   // We expect RewriteRules will most commonly include only one case.
   SmallVector Cases;
@@ -137,6 +147,16 @@
   return makeRule(std::move(M), std::move(Edits), std::move(Explanation));
 }
 
+//

[PATCH] D63893: [clang-tidy] Extend TransformerClangTidyCheck to support adding includes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: ilya-biryukov, gribozavr.
Herald added a subscriber: xazax.hun.
Herald added a project: clang.
ymandel added a parent revision: D63892: [LibTooling] Extend `RewriteRule` with 
support for adding includes..

This revision implements support for the `AddedIncludes` field in
RewriteRule cases; that is, it supports specifying the addition of include
directives in files modified by the clang tidy check.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63893

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -19,6 +19,7 @@
 namespace utils {
 namespace {
 using tooling::change;
+using tooling::IncludeFormat;
 using tooling::RewriteRule;
 using tooling::text;
 using tooling::stencil::cat;
@@ -121,6 +122,54 @@
   Input, nullptr, "input.cc", None, Options));
 }
 
+RewriteRule replaceCall(IncludeFormat Format) {
+  using namespace ::clang::ast_matchers;
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")), text("no message"));
+  addInclude(Rule, "clang/OtherLib.h", Format);
+  return Rule;
+}
+
+template 
+class IncludeCheck : public TransformerClangTidyCheck {
+public:
+  IncludeCheck(StringRef Name, ClangTidyContext *Context)
+  : TransformerClangTidyCheck(replaceCall(Format), Name, Context) {}
+};
+
+TEST(TransformerClangTidyCheckTest, AddIncludeQuoted) {
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include "clang/OtherLib.h"
+
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  EXPECT_EQ(Expected,
+test::runCheckOnCode>(Input));
+}
+
+TEST(TransformerClangTidyCheckTest, AddIncludeAngled) {
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include 
+
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  EXPECT_EQ(Expected,
+test::runCheckOnCode>(Input));
+}
+
 } // namespace
 } // namespace utils
 } // namespace tidy
Index: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
===
--- clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
+++ clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
@@ -10,7 +10,9 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_TRANSFORMER_CLANG_TIDY_CHECK_H
 
 #include "../ClangTidy.h"
+#include "../utils/IncludeInserter.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
 #include "clang/Tooling/Refactoring/Transformer.h"
 #include 
 #include 
@@ -52,11 +54,14 @@
   TransformerClangTidyCheck(tooling::RewriteRule R, StringRef Name,
 ClangTidyContext *Context);
 
+  void registerPPCallbacks(const SourceManager &SM, Preprocessor *PP,
+   Preprocessor *ModuleExpanderPP) override;
   void registerMatchers(ast_matchers::MatchFinder *Finder) final;
   void check(const ast_matchers::MatchFinder::MatchResult &Result) final;
 
 private:
   Optional Rule;
+  std::unique_ptr Inserter;
 };
 
 } // namespace utils
Index: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
===
--- clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
+++ clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
@@ -44,6 +44,15 @@
  " explicitly provide an empty explanation if none is desired");
 }
 
+void TransformerClangTidyCheck::registerPPCallbacks(
+const SourceManager &SM, Preprocessor *PP, Preprocessor *ModuleExpanderPP) {
+  if (Rule) {
+Inserter = llvm::make_unique(
+SM, getLangOpts(), utils::IncludeSorter::IS_LLVM);
+PP->addPPCallbacks(Inserter->CreatePPCallbacks());
+  }
+}
+
 void TransformerClangTidyCheck::registerMatchers(
 ast_matchers::MatchFinder *Finder) {
   if (Rule)
@@ -87,6 +96,15 @@
   for (const auto &T : *Transformations) {
 Diag << FixItHint::CreateReplacement(T.Range, T.Replacement);
   }
+
+  for (const auto &I : Case.AddedIncludes) {
+auto &Header = I.first;
+if (Optional Fix = Inserter->CreateIncludeInsertion(
+Result.SourceManager->getMainFileID(), Header,
+/*IsAngled=*/I.second == tooling::IncludeFormat::Angled)) {
+  Diag << *Fix;
+}
+  }
 }
 
 } // namespace utils
__

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 206919.
Nathan-Huckleberry added a comment.

- Add assertion message and simplify test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533

Files:
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered 
GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63857: [clang-doc] Structured HTML generator

[Diego Astiazarán via Phabricator via cfe-commits]

DiegoAstiazaran updated this revision to Diff 206920.
DiegoAstiazaran marked 7 inline comments as done.
DiegoAstiazaran added a comment.

Fix TagType enum name and members.
Add anonymous namespace.
Separate the implementation from the definition for some functions.
Use emplace_back instead of push_back for instantiation of vector members.


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

https://reviews.llvm.org/D63857

Files:
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/MDGenerator.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -40,16 +40,31 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(&I, Actual);
   assert(!Err);
-  std::string Expected = R"raw(namespace Namespace
-Namespaces
-ChildNamespace
-Records
-ChildStruct
-Functions
-OneFunction
- OneFunction()
-Enums
-enum OneEnum
+  std::string Expected = R"raw(
+
+namespace Namespace
+
+  namespace Namespace
+  Namespaces
+  
+ChildNamespace
+  
+  Records
+  
+ChildStruct
+  
+  Functions
+  
+OneFunction
+
+   OneFunction()
+
+  
+  Enums
+  
+enum OneEnum
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -80,18 +95,37 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(&I, Actual);
   assert(!Err);
-  std::string Expected = R"raw(class r
-Defined at line 10 of test.cpp
-Inherits from F, G
-Members
-private int X
-Records
-ChildStruct
-Functions
-OneFunction
- OneFunction()
-Enums
-enum OneEnum
+  std::string Expected = R"raw(
+
+class r
+
+  class r
+  
+Defined at line 10 of test.cpp
+  
+  
+Inherits from F, G
+  
+  Members
+  
+private int X
+  
+  Records
+  
+ChildStruct
+  
+  Functions
+  
+OneFunction
+
+   OneFunction()
+
+  
+  Enums
+  
+enum OneEnum
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -116,9 +150,18 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(&I, Actual);
   assert(!Err);
-  std::string Expected = R"raw(f
-void f(int P)
-Defined at line 10 of test.cpp
+  std::string Expected = R"raw(
+
+
+
+  f
+  
+void f(int P)
+  
+  
+Defined at line 10 of test.cpp
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -141,11 +184,18 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(&I, Actual);
   assert(!Err);
-  std::string Expected = R"raw(enum class e
-
-X
-
-Defined at line 10 of test.cpp
+  std::string Expected = R"raw(
+
+
+
+  enum class e
+  
+X
+  
+  
+Defined at line 10 of test.cpp
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -194,12 +244,29 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(&I, Actual);
   assert(!Err);
-  std::string Expected = R"raw(f
-void f(int I, int J)
-Defined at line 10 of test.cpp
-
- Brief description.
- Extended description that continues onto the next line.
+  std::string Expected = R"raw(
+
+
+
+  f
+  
+void f(int I, int J)
+  
+  
+Defined at line 10 of test.cpp
+  
+  
+
+  
+ Brief description.
+  
+  
+ Extended description that
+ continues onto the next line.
+  
+
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
Index: clang-tools-extra/clang-doc/MDGenerator.cpp
===
--- clang-tools-extra/clang-doc/MDGenerator.cpp
+++ clang-tools-extra/clang-doc/MDGenerator.cpp
@@ -20,11 +20,11 @@
 
 // Markdown generation
 
-std::string genItalic(const Twine &Text) { return "*" + Text.str() + "*"; }
+static std::string genItalic(const Twine &Text) { return "*" + Text.str() + "*"; }
 
-std::string genEmphasis(const Twine &Text) { return "**" + Text.str() + "**"; }
+static std::string genEmphasis(const Twine &Text) { return "**" + Text.str() + "**"; }
 
-std::string genLink(const Twine &Text, const Twine &Link) {
+static std::string genLink(const Twine &Text, const Twine &Link) {
   return "[" + Text.str() + "](" + Link.str() + ")";
 }
 
@@ -92,7 +92,7 @@
   }
 }
 
-void genMarkdown(const EnumInfo &I, llvm::raw_ostream &OS) {
+static void genMarkdown(const EnumInfo &I, llvm::raw_ostream &OS) {
   if (I.Scoped)
 writeLine("| enum class " + I.Name + " |", OS);
   else
@@ -112,7 +112,7 @@
 writeDescription(C, OS);
 }
 
-void genMarkdown(const FunctionInfo &I, llvm::raw_ostream &OS) {
+static void genMarkdown(const FunctionInfo &I, llvm::raw_ostream &OS) {
   std::string Buffer;
   llvm::raw_string_ostream Stream(Buffer);
   bool First = true;
@@ -139,7 +139,7 @@
 writeDescription(C, OS);
 }
 
-void genMarkdown(const NamespaceInfo &I, llvm::raw_ostream &OS) {
+static void g

[PATCH] D63894: [CXX] Exercise all paths through these tests

[Paul Robinson via Phabricator via cfe-commits]

probinson created this revision.
probinson added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

These 3 tests have dialect-based conditionals, but weren't running Clang with 
enough different dialects to actually enable those conditional sections.


Repository:
  rC Clang

https://reviews.llvm.org/D63894

Files:
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
  clang/test/SemaCXX/class.cpp
  clang/test/SemaCXX/linkage2.cpp


Index: clang/test/SemaCXX/linkage2.cpp
===
--- clang/test/SemaCXX/linkage2.cpp
+++ clang/test/SemaCXX/linkage2.cpp
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=gnu++11 %s
-// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args %s -std=gnu++98
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args -fmodules %s
 
 namespace test1 {
Index: clang/test/SemaCXX/class.cpp
===
--- clang/test/SemaCXX/class.cpp
+++ clang/test/SemaCXX/class.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s 
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s -std=c++98
 class C {
 public:
   auto int errx; // expected-error {{storage class specified for a member 
declaration}}
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 // C++03 [namespace.udecl]p4:


Index: clang/test/SemaCXX/linkage2.cpp
===
--- clang/test/SemaCXX/linkage2.cpp
+++ clang/test/SemaCXX/linkage2.cpp
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=gnu++11 %s
-// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args %s -std=gnu++98
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args -fmodules %s
 
 namespace test1 {
Index: clang/test/SemaCXX/class.cpp
===
--- clang/test/SemaCXX/class.cpp
+++ clang/test/SemaCXX/class.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s 
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s -std=c++98
 class C {
 public:
   auto int errx; // expected-error {{storage class specified for a member declaration}}
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 // C++03 [namespace.udecl]p4:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Artem Dergachev via Phabricator via cfe-commits]

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

Looks great now, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533



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

r364595 - Pattern match struct types in test case.

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Thu Jun 27 14:16:19 2019
New Revision: 364595

URL: http://llvm.org/viewvc/llvm-project?rev=364595&view=rev
Log:
Pattern match struct types in test case.

This simplifies the test cases in a patch I'm planning to send later.

Modified:
cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m

Modified: cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m?rev=364595&r1=364594&r2=364595&view=diff
==
--- cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m (original)
+++ cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m Thu Jun 27 14:16:19 2019
@@ -90,10 +90,16 @@ StrongOuter2 getStrongOuter2(void);
 void calleeStrongSmall(StrongSmall);
 void func(Strong *);
 
+// CHECK: %[[STRUCT_STRONGOUTER:.*]] = type { %[[STRUCT_STRONG:.*]], i8*, 
double }
+// CHECK: %[[STRUCT_STRONG]] = type { %[[STRUCT_TRIVIAL:.*]], i8* }
+// CHECK: %[[STRUCT_TRIVIAL]] = type { [4 x i32] }
+// CHECK: %[[STRUCT_BLOCK_BYREF_T:.*]] = type { i8*, 
%[[STRUCT_BLOCK_BYREF_T]]*, i32, i32, i8*, i8*, i8*, %[[STRUCT_STRONGOUTER]] }
+// CHECK: %[[STRUCT_STRONGSMALL:.*]] = type { i32, i8* }
+// CHECK: %[[STRUCT_STRONGBLOCK:.*]] = type { void ()* }
 // CHECK: %[[STRUCT_BITFIELD1:.*]] = type { i8, i8, i8*, i32, i8*, [3 x i32], 
i8*, double, i8, i8 }
 
 // CHECK: define void @test_constructor_destructor_StrongOuter()
-// CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER:.*]], align 8
+// CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
 // CHECK: call void @__default_constructor_8_S_s16_s24(i8** %[[V0]])
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
@@ -148,7 +154,7 @@ void test_constructor_destructor_StrongO
   StrongOuter t;
 }
 
-// CHECK: define void 
@test_copy_constructor_StrongOuter(%[[STRUCT_STRONGOUTER:.*]]* %[[S:.*]])
+// CHECK: define void 
@test_copy_constructor_StrongOuter(%[[STRUCT_STRONGOUTER]]* %[[S:.*]])
 // CHECK: %[[S_ADDR:.*]] = alloca %[[STRUCT_STRONGOUTER]]*, align 8
 // CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER]], align 8
 // CHECK: store %[[STRUCT_STRONGOUTER]]* %[[S]], %[[STRUCT_STRONGOUTER]]** 
%[[S_ADDR]], align 8
@@ -235,7 +241,7 @@ void test_copy_assignment_StrongOuter(St
 }
 
 // CHECK: define void @test_move_constructor_StrongOuter()
-// CHECK: %[[T1:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T:.*]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
+// CHECK: %[[T1:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T1]] to i8**
 // CHECK: call void @__default_constructor_8_S_s16_s24(i8** %[[V1]])
 // CHECK: %[[T2:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
@@ -411,10 +417,10 @@ void test_move_assignment_StrongOuter2(S
 }
 
 // CHECK: define void @test_parameter_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONG:.*]], align 8
-// CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONG]]* %[[A]] to [2 x i64]*
+// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
-// CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONG]]* %[[A]] to i8**
+// CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to i8**
 // CHECK: call void @__destructor_8_s8(i8** %[[V1]])
 // CHECK: ret void
 
@@ -422,7 +428,7 @@ void test_parameter_StrongSmall(StrongSm
 }
 
 // CHECK: define void @test_argument_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[TEMP_LVALUE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
@@ -441,7 +447,7 @@ void test_argument_StrongSmall(StrongSma
 }
 
 // CHECK: define [2 x i64] @test_return_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[RETVAL:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[RETVAL:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
@@ -459,7 +465,7 @@ StrongSmall test_return_StrongSmall(Stro
 }
 
 // CHECK: define void @test_destructor_ignored_result()
-// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[CALL:.*]] = call [2 x i64] @getStrongSmall()
 // CHECK: %[[V0:.*]] 

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:401
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered 
GCCAsmStmt without labels");
+// TODO: Handle jumping to labels

prefer: `assert(shouldBeTrue() && "asdfasdf")` to `assert(shouldBeTrue() == 
true && "asfas")`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533



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

[PATCH] D63857: [clang-doc] Structured HTML generator

[Jake Ehrlich via Phabricator via cfe-commits]

jakehehrlich added a comment.

Overall looks better. One of my comments causes a sweeping change to occur so 
I'll respond back after thats done.




Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:91
+struct HTMLFile {
+  llvm::SmallString<16> DoctypeDecl{""};
+  std::vector> Children; // List of child nodes

Does this ever change? If not this should be a global constexpr constant char* 
inside of an anon-namespace.

e.g.

namespace {
  constexpr const char* kDoctypeDecl = "...";
}



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:170
+OS << " " << A.getKey() << "=\"" << A.getValue() << "\"";
+  OS << (SelfClosing ? "/>" : ">");
+  if (!InlineChildren)

You can exit here if its self closing right?



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:187
 
-std::string genTag(const Twine &Text, const Twine &Tag) {
-  return "<" + Tag.str() + ">" + Text.str() + "";
+static void genHTML(const EnumInfo &I, TagNode *N);
+static void genHTML(const FunctionInfo &I, TagNode *N);

You should return TagNodes, not assign to them by ref. Preferably via retruning 
a unique pointer. It doesn't make sense to have the consumer do the constructor 
I would imagine. For instance what tag is the right tag type? The consumer 
shouldn't decide, the producer should. 



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:190
+
+static void genEnumsBlock(const std::vector &Enums, TagNode *N) {
+  if (Enums.empty())

Same comment here these function should look like (at a very high an imprecise 
level, obviously some functions will be more complicated.)

```
std::unique_ptr genFoo(info) {
  auto out = llvm::make_unique<...>(...);
  for (const auto &B : info.bars)
out->Children.emplace_back(genBar(B));
  return out;
}
```

This goes for all of these functions


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

https://reviews.llvm.org/D63857



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

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

[Jian Cai via Phabricator via cfe-commits]

jcai19 updated this revision to Diff 206946.
jcai19 added a comment.

Update the check to catch redundant code and update the warning message to be 
more speicific.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-posix-return.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
@@ -0,0 +1,124 @@
+// RUN: %check_clang_tidy %s bugprone-posix-return %t
+
+#define NULL nullptr
+#define ZERO 0
+#define NEGATIVE_ONE -1
+
+typedef long off_t;
+typedef decltype(sizeof(int)) size_t;
+typedef int pid_t;
+typedef struct __posix_spawn_file_actions* posix_spawn_file_actions_t;
+typedef struct __posix_spawnattr* posix_spawnattr_t;
+
+extern "C" int posix_fadvise(int fd, off_t offset, off_t len, int advice);
+extern "C" int posix_fallocate(int fd, off_t offset, off_t len);
+extern "C" int posix_madvise(void *addr, size_t len, int advice);
+extern "C" int posix_memalign(void **memptr, size_t alignment, size_t size);
+extern "C" int posix_openpt(int flags);
+extern "C" int posix_spawn(pid_t *pid, const char *path,
+const posix_spawn_file_actions_t *file_actions,
+const posix_spawnattr_t *attrp,
+char *const argv[], char *const envp[]);
+extern "C" int posix_spawnp(pid_t *pid, const char *file,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argv[], char *const envp[]);
+
+void warningLEZero() {
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > 0
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fallocate(0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  // CHECK-FIXES: posix_fallocate(0, 0, 0) > 0
+  if (posix_madvise(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_madvise(NULL, 0, 0) > 0
+  if (posix_memalign(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  // CHECK-FIXES: posix_memalign(NULL, 0, 0) > 0
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  // CHECK-FIXES: posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+  // CHECK-FIXES: posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+}
+
+void warningEqualsNegative() {
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fadvise(0, 0, 0, 0) != -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fallocate(0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  if (posix_madvise(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_memalign(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+}
+
+void WarningWithMacro() {
+  if (posix_fadvise(0, 0, 0, 0) < ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > ZERO
+  if (posix_fadvise(0, 0, 0, 0) >= ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) == NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) != NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+}
+
+void noWarning() {
+  if (posix_openpt(0) < 0) {}
+  if (posix_openpt(0) <= 0) {}
+  if (posix_openpt(0) == -1) {}
+  if (posix_openpt(0) != -1) {}
+  if (posix_openpt(0) <= -1) {}
+  if (posi

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

[Jian Cai via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp:96
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {} else {}
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}

gribozavr wrote:
> jcai19 wrote:
> > gribozavr wrote:
> > > Shouldn't there be a warning in the else branch?
> > This check only matches calls to the POSIX functions in the global scope, 
> > not member functions or functions defined within namespaces. Although in 
> > the global scope,  this particular case will still pass as there won't be a 
> > ``<`` binary operator for the else branch so no matching will happen.
> Sorry, yes, that's what I meant -- if we warn on `< 0`, then we should warn 
> on the else branch of `>=`. I just commented on the wrong test -- sorry about 
> that.
Thanks for the clarification. Actually >= 0 is always true since the call 
return 0 on success and a positive value on error, so the else branch will 
never be reached. I have update my check and the warning message to reflect 
this. Good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623



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

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

[Jian Cai via Phabricator via cfe-commits]

jcai19 updated this revision to Diff 206947.
jcai19 added a comment.

Update test names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-posix-return.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
@@ -0,0 +1,127 @@
+// RUN: %check_clang_tidy %s bugprone-posix-return %t
+
+#define NULL nullptr
+#define ZERO 0
+#define NEGATIVE_ONE -1
+
+typedef long off_t;
+typedef decltype(sizeof(int)) size_t;
+typedef int pid_t;
+typedef struct __posix_spawn_file_actions* posix_spawn_file_actions_t;
+typedef struct __posix_spawnattr* posix_spawnattr_t;
+
+extern "C" int posix_fadvise(int fd, off_t offset, off_t len, int advice);
+extern "C" int posix_fallocate(int fd, off_t offset, off_t len);
+extern "C" int posix_madvise(void *addr, size_t len, int advice);
+extern "C" int posix_memalign(void **memptr, size_t alignment, size_t size);
+extern "C" int posix_openpt(int flags);
+extern "C" int posix_spawn(pid_t *pid, const char *path,
+const posix_spawn_file_actions_t *file_actions,
+const posix_spawnattr_t *attrp,
+char *const argv[], char *const envp[]);
+extern "C" int posix_spawnp(pid_t *pid, const char *file,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argv[], char *const envp[]);
+
+void warningLessThanZero() {
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > 0
+  if (posix_fallocate(0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  // CHECK-FIXES: posix_fallocate(0, 0, 0) > 0
+  if (posix_madvise(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_madvise(NULL, 0, 0) > 0
+  if (posix_memalign(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  // CHECK-FIXES: posix_memalign(NULL, 0, 0) > 0
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  // CHECK-FIXES: posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+  // CHECK-FIXES: posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+}
+
+void warningAlwaysTrue() {
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+}
+
+void warningEqualsNegative() {
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fadvise(0, 0, 0, 0) != -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fallocate(0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  if (posix_madvise(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_memalign(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+}
+
+void WarningWithMacro() {
+  if (posix_fadvise(0, 0, 0, 0) < ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > ZERO
+  if (posix_fadvise(0, 0, 0, 0) >= ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) == NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) != NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+}
+
+void noWarning() {
+  if (posix_openpt(0) < 0) {}
+  if (posix_openpt(0) <= 0) {}
+  if (posix_openpt(0) == -1) {}
+  if (posix_openpt(0) != -1) {}
+  if (posix_openpt(0) <= -1) {}
+  if (posix_openpt(0) < -1) {}
+  if (posix_fad

[PATCH] D62441: [analyzer] NFC: Introduce a convenient CallDescriptionMap class.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 206951.
NoQ added a comment.

Indeed. Subtle!


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

https://reviews.llvm.org/D62441

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
  clang/unittests/StaticAnalyzer/Reusables.h

Index: clang/unittests/StaticAnalyzer/Reusables.h
===
--- clang/unittests/StaticAnalyzer/Reusables.h
+++ clang/unittests/StaticAnalyzer/Reusables.h
@@ -17,16 +17,24 @@
 namespace clang {
 namespace ento {
 
+// Find a node in the current AST that matches a matcher.
+template 
+const T *findNode(const Decl *Where, MatcherT What) {
+  using namespace ast_matchers;
+  auto Matches = match(decl(hasDescendant(What.bind("root"))),
+   *Where, Where->getASTContext());
+  assert(Matches.size() <= 1 && "Ambiguous match!");
+  assert(Matches.size() >= 1 && "Match not found!");
+  const T *Node = selectFirst("root", Matches);
+  assert(Node && "Type mismatch!");
+  return Node;
+}
+
 // Find a declaration in the current AST by name.
 template 
 const T *findDeclByName(const Decl *Where, StringRef Name) {
   using namespace ast_matchers;
-  auto Matcher = decl(hasDescendant(namedDecl(hasName(Name)).bind("d")));
-  auto Matches = match(Matcher, *Where, Where->getASTContext());
-  assert(Matches.size() == 1 && "Ambiguous name!");
-  const T *Node = selectFirst("d", Matches);
-  assert(Node && "Name not found!");
-  return Node;
+  return findNode(Where, namedDecl(hasName(Name)));
 }
 
 // A re-usable consumer that constructs ExprEngine out of CompilerInvocation.
Index: clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
@@ -0,0 +1,109 @@
+//===- unittests/StaticAnalyzer/CallDescriptionTest.cpp ---===//
+//
+// 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 "Reusables.h"
+
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace ento {
+namespace {
+
+// Test that we can put a value into an int-type variable and load it
+// back from that variable. Test what happens if default bindings are used.
+class CallDescriptionConsumer : public ExprEngineConsumer {
+  const CallDescriptionMap &CDM;
+  void performTest(const Decl *D) {
+using namespace ast_matchers;
+
+if (!D->hasBody())
+  return;
+
+const CallExpr *CE = findNode(D, callExpr());
+const StackFrameContext *SFC =
+Eng.getAnalysisDeclContextManager().getStackFrame(D);
+ProgramStateRef State = Eng.getInitialState(SFC);
+CallEventRef<> Call =
+Eng.getStateManager().getCallEventManager().getCall(CE, State, SFC);
+
+const bool *LookupResult = CDM.lookup(*Call);
+// Check that we've found the function in the map
+// with the correct description.
+assert(LookupResult && *LookupResult);
+  }
+
+public:
+  CallDescriptionConsumer(CompilerInstance &C,
+  const CallDescriptionMap &CDM)
+  : ExprEngineConsumer(C), CDM(CDM) {}
+
+  bool HandleTopLevelDecl(DeclGroupRef DG) override {
+for (const auto *D : DG)
+  performTest(D);
+return true;
+  }
+};
+
+class CallDescriptionAction : public ASTFrontendAction {
+  const CallDescriptionMap &CDM;
+
+public:
+  CallDescriptionAction(const CallDescriptionMap &CDM) : CDM(CDM) {}
+
+  std::unique_ptr CreateASTConsumer(CompilerInstance &Compiler,
+ StringRef File) override {
+return llvm::make_unique(Compiler, CDM);
+  }
+};
+
+TEST(CallEvent, CallDescription) {
+  // Test simple name matching.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{"bar"}, false},
+  {{"foo"}, true},
+  }), "void foo(); void bar() { foo(); }"));
+
+  // Test arguments check.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{"foo", 1}, true},
+  {{"foo", 2}, false},
+  }), "void foo(int); void foo(int, int); void bar() { foo(1); }"));
+
+  // Test qualified names.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{{"std", "basic_string", "c_str"}}, true},
+  }),
+  "namespace std { inline namespace __1 {"
+  "  template class basic_string {"
+  "  public:"
+  "T *c_str();"
+  "  };"
+  "}}"
+  "void foo() {"
+  "  using namespace std;"
+  "  basic_string 

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

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

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



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7764
+  llvm::SmallDenseMap NewTransformCache;
+  auto SavedTransformCache = TransformCache;
+  TransformCache = NewTransformCache;

dgoldman wrote:
> Should I do the same `std::move` and `clear` here as well?
Yes, please.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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

[libclc] r364604 - Creating release candidate rc3 from release_801 branch

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Thu Jun 27 15:33:04 2019
New Revision: 364604

URL: http://llvm.org/viewvc/llvm-project?rev=364604&view=rev
Log:
Creating release candidate rc3 from release_801 branch

Added:
libclc/tags/RELEASE_801/rc3/
  - copied from r364603, libclc/branches/release_80/

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

[libunwind] r364604 - Creating release candidate rc3 from release_801 branch

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Thu Jun 27 15:33:04 2019
New Revision: 364604

URL: http://llvm.org/viewvc/llvm-project?rev=364604&view=rev
Log:
Creating release candidate rc3 from release_801 branch

Added:
libunwind/tags/RELEASE_801/rc3/
  - copied from r364603, libunwind/branches/release_80/

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

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 206954.
Nathan-Huckleberry added a comment.

- Minor style change on assert


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533

Files:
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r364605 - [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Nathan Huckleberry via cfe-commits]

Author: nathan-huckleberry
Date: Thu Jun 27 15:46:40 2019
New Revision: 364605

URL: http://llvm.org/viewvc/llvm-project?rev=364605&view=rev
Log:
[analyzer] Fix clang-tidy crash on GCCAsmStmt

Summary:
Added entry in switch statement to recognize GCCAsmStmt
as a possible block terminator.

Handling to build CFG using GCCAsmStmt was already implemented.

Reviewers: nickdesaulniers, george.karpenkov, NoQ

Reviewed By: nickdesaulniers, NoQ

Subscribers: xbolva00, tmroeder, xazax.hun, baloghadamsoftware, szepet, 
a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, cfe-commits

Tags: #clang

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

Added:
cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp?rev=364605&r1=364604&r2=364605&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp Thu Jun 27 15:46:40 2019
@@ -396,6 +396,11 @@ void CoreEngine::HandleBlockExit(const C
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 

Added: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp?rev=364605&view=auto
==
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp (added)
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp Thu Jun 27 15:46:40 
2019
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}


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

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

[Nathan Huckleberry via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364605: [analyzer] Fix clang-tidy crash on GCCAsmStmt 
(authored by Nathan-Huckleberry, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63533?vs=206954&id=206956#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63533

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
  cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63048: Update __VERSION__ to remove the hardcoded 4.2.1 version

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I'd be in favor of removing them.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63048



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