[PATCH] D14484: Formatting constructor initializer lists by putting them always on different lines

2019-06-21 Thread Nikolai Hlubek via Phabricator via cfe-commits
nhlubek added a comment.

Is it possible to discuss about this feature again?

This is only a corner case if you allow only 80 characters per line.
If you allow more characters (e.g. you use doxygen for inline formatting and 
want some space on the right) this quickly becomes very relevant, because then 
each initializer list gets very unreadable.

Currently it is even not possible, to reproduce the mock up example in the 
original implementation 
(only by setting the line limit at 40 or so which is a bit unreasonable).
https://reviews.llvm.org/D32479

  // When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
  Constructor() :
  initializer1(),
  initializer2()
  {}


Repository:
  rL LLVM

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

https://reviews.llvm.org/D14484



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


[clang-tools-extra] r364008 - [clang-tidy] Move test files of rL363975 into Inputs directory

2019-06-21 Thread Kadir Cetinkaya via cfe-commits
Author: kadircet
Date: Fri Jun 21 00:54:27 2019
New Revision: 364008

URL: http://llvm.org/viewvc/llvm-project?rev=364008&view=rev
Log:
[clang-tidy] Move test files of rL363975 into Inputs directory

Added:
clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/

clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/compile_commands.json
Removed:
clang-tools-extra/trunk/test/clang-tidy/empty-database/
Modified:
clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp

Added: 
clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/compile_commands.json
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/compile_commands.json?rev=364008&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/compile_commands.json
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/Inputs/empty-database/compile_commands.json
 Fri Jun 21 00:54:27 2019
@@ -0,0 +1,4 @@
+[{
+"directory":"",
+"file":"/tmp/","arguments":[]
+}]

Modified: clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp?rev=364008&r1=364007&r2=364008&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp Fri Jun 21 
00:54:27 2019
@@ -1,3 +1,3 @@
-// RUN: not clang-tidy -p %S/empty-database %s 2>&1 | FileCheck %s
+// RUN: not clang-tidy -p %S/Inputs/empty-database %s 2>&1 | FileCheck %s
 
 // CHECK: LLVM ERROR: Cannot chdir into ""!


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


[clang-tools-extra] r364010 - [clang-tidy] Fix a typo in the doc.

2019-06-21 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Fri Jun 21 00:58:19 2019
New Revision: 364010

URL: http://llvm.org/viewvc/llvm-project?rev=364010&view=rev
Log:
[clang-tidy] Fix a typo in the doc.

Modified:
clang-tools-extra/trunk/docs/clang-tidy/checks/abseil-duration-addition.rst

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/abseil-duration-addition.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/abseil-duration-addition.rst?rev=364010&r1=364009&r2=364010&view=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/abseil-duration-addition.rst 
(original)
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/abseil-duration-addition.rst 
Fri Jun 21 00:58:19 2019
@@ -18,4 +18,4 @@ Examples:
   int result = absl::ToUnixSeconds(t) + x;
 
   // Suggestion - Addition in the absl::Time domain
-  int result = absl::TounixSeconds(t + absl::Seconds(x));
+  int result = absl::ToUnixSeconds(t + absl::Seconds(x));


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


Re: [PATCH] D63451: P0840R2: support for [[no_unique_address]] attribute

2019-06-21 Thread Yvan Roux via cfe-commits
Hi Richard,

This commit broke ARM bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/13576/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Atail-padding.cpp

Thanks,
Yvan

On Thu, 20 Jun 2019 at 23:06, John McCall via Phabricator via
llvm-commits  wrote:
>
> rjmccall added a comment.
>
> In D63451#1552609 , @rsmith wrote:
>
> > In D63451#1549563 , @rjmccall 
> > wrote:
> >
> > > Can this attribute not be applied to a base class, or to a type?
> >
> >
> > The standard attribute forbids that right now. We could add a custom 
> > attribute that permits it, but we're required to diagnose application of 
> > the standard attribute to a type -- though a warning would suffice to 
> > satisfy that requirement. (Because this gives "same as a base class" 
> > layout, adding it to a base class wouldn't have any effect right now, but 
> > we could certainly say that the attribute on a class type also implies the 
> > class is not POD for the purpose of layout, to permit tail padding reuse.)
>
>
> I think we're talking about slightly different things.
>
> You're trying to make sure that fields can take advantage of the layout 
> optimizations available to base classes so that library code doesn't need to 
> contort to e.g. use the empty-base-class optimization just to avoid wasting 
> an entire pointer to store an empty allocator.  This attribute seems 
> well-targeted for that.
>
> Totally separately from that — but perhaps better-related to the name of the 
> attribute — I know that some projects have, in the past, had surprising 
> problems with the rule that class layout can't place empty base classes at 
> the same offset as other objects of the same type.  For example, IIRC WebKit 
> used to have a `Noncopyable` class that deleted its copy constructor and 
> copy-assignment operators, and there was an idiom to inherit from this in 
> order to disable copying, and at one point they discovered that some fairly 
> important class was quite a bit larger than expected because of this rule — I 
> think they were also using the base class redundantly throughout the 
> hierarchy because they didn't expect there to be any harm to doing so.  They 
> would've no doubt appreciated the ability to just put the attribute on 
> `Noncopyable`.  But of course they fixed that years ago, so I can't say that 
> it's a serious issue for them now.
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D63451/new/
>
> https://reviews.llvm.org/D63451
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon empty database fields

2019-06-21 Thread via cfe-commits
Hi Serge,

The test you added here is failing on the PS4 Windows build bot, can you take a 
look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26513/steps/test/logs/stdio

FAIL: Clang Tools :: clang-tidy/empty-database.cpp (14917 of 50455)
 TEST 'Clang Tools :: clang-tidy/empty-database.cpp' FAILED 

Script:
--
: 'RUN: at line 1';   not clang-tidy -p 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database
 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
 2>&1 | FileCheck 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "not" "clang-tidy" "-p" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database"
 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
note: command had no output on stdout or stderr
error: command failed with exit status: 1
$ "FileCheck" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
# command stderr:
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp:3:11:
 error: CHECK: expected string not found in input

// CHECK: LLVM ERROR: Cannot chdir into ""!

  ^

:1:1: note: scanning from here

Skipping 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
 Compile command not found.

^

:1:150: note: possible intended match here

Skipping 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
 Compile command not found.


 ^


error: command failed with exit status: 1

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Serge 
Guelton via cfe-commits
Sent: Thursday, June 20, 2019 13:26
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon empty 
database fields

Author: serge_sans_paille
Date: Thu Jun 20 13:25:59 2019
New Revision: 363975

URL: http://llvm.org/viewvc/llvm-project?rev=363975&view=rev
Log:
[clang-tidy] Fail gracefully upon empty database fields

Fix bz#42281

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

Added:
clang-tools-extra/trunk/test/clang-tidy/empty-database/
clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json

Added: clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp?rev=363975&view=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp (added)
+++ clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp Thu Jun 20 
13:25:59 2019
@@ -0,0 +1,3 @@
+// RUN: not clang-tidy -p %S/empty-database %s 2>&1 | FileCheck %s
+
+// CHECK: LLVM ERROR: Cannot chdir into ""!

Added: 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json?rev=363975&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
(added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
Thu Jun 20 13:25:59 2019
@@ -0,0 +1,4 @@
+[{
+"directory":"",
+"file":"/tmp/","arguments":[]
+}]


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


r364011 - [clang] Small improvments after Adding APValue to ConstantExpr

2019-06-21 Thread Gauthier Harnisch via cfe-commits
Author: tyker
Date: Fri Jun 21 01:26:21 2019
New Revision: 364011

URL: http://llvm.org/viewvc/llvm-project?rev=364011&view=rev
Log:
[clang] Small improvments after Adding APValue to ConstantExpr

Summary:
this patch has multiple small improvements related to the APValue in 
ConstantExpr.

changes:
 - APValue in ConstantExpr are now cleaned up using ASTContext::addDestruction 
instead of there own system.
 - ConstantExprBits Stores the ValueKind of the result beaing stored.
 - VerifyIntegerConstantExpression now stores the evaluated value in 
ConstantExpr.
 - the Constant Evaluator uses the stored value of ConstantExpr when available.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=364011&r1=364010&r2=364011&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jun 21 01:26:21 2019
@@ -2751,12 +2751,11 @@ public:
   ///
   /// \param Data Pointer data that will be provided to the callback function
   /// when it is called.
-  void AddDeallocation(void (*Callback)(void*), void *Data);
+  void AddDeallocation(void (*Callback)(void *), void *Data) const;
 
   /// If T isn't trivially destructible, calls AddDeallocation to register it
   /// for destruction.
-  template 
-  void addDestruction(T *Ptr) {
+  template  void addDestruction(T *Ptr) const {
 if (!std::is_trivially_destructible::value) {
   auto DestroyPtr = [](void *V) { static_cast(V)->~T(); };
   AddDeallocation(DestroyPtr, Ptr);
@@ -2819,10 +2818,6 @@ public:
   APValue *getMaterializedTemporaryValue(const MaterializeTemporaryExpr *E,
  bool MayCreate);
 
-  /// Adds an APValue that will be destructed during the destruction of the
-  /// ASTContext.
-  void AddAPValueCleanup(APValue *Ptr) const { APValueCleanups.push_back(Ptr); 
}
-
   /// Return a string representing the human readable name for the specified
   /// function declaration or file name. Used by SourceLocExpr and
   /// PredefinedExpr to cache evaluated results.
@@ -2989,7 +2984,7 @@ private:
   // in order to track and run destructors while we're tearing things down.
   using DeallocationFunctionsAndArguments =
   llvm::SmallVector, 16>;
-  DeallocationFunctionsAndArguments Deallocations;
+  mutable DeallocationFunctionsAndArguments Deallocations;
 
   // FIXME: This currently contains the set of StoredDeclMaps used
   // by DeclContext objects.  This probably should not be in ASTContext,

Modified: cfe/trunk/include/clang/AST/Expr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=364011&r1=364010&r2=364011&view=diff
==
--- cfe/trunk/include/clang/AST/Expr.h (original)
+++ cfe/trunk/include/clang/AST/Expr.h Fri Jun 21 01:26:21 2019
@@ -998,6 +998,9 @@ public:
EmptyShell Empty);
 
   static ResultStorageKind getStorageKind(const APValue &Value);
+  static ResultStorageKind getStorageKind(const Type *T,
+  const ASTContext &Context);
+
   SourceLocation getBeginLoc() const LLVM_READONLY {
 return SubExpr->getBeginLoc();
   }
@@ -1009,25 +1012,20 @@ public:
 return T->getStmtClass() == ConstantExprClass;
   }
 
-  void SetResult(APValue Value) { MoveIntoResult(Value); }
-  void MoveIntoResult(APValue &Value);
+  void SetResult(APValue Value, const ASTContext &Context) {
+MoveIntoResult(Value, Context);
+  }
+  void MoveIntoResult(APValue &Value, const ASTContext &Context);
 
   APValue::ValueKind getResultAPValueKind() const {
-switch (ConstantExprBits.ResultKind) {
-case ConstantExpr::RSK_APValue:
-  return APValueResult().getKind();
-case ConstantExpr::RSK_Int64:
-  return APValue::Int;
-case ConstantExpr::RSK_None:
-  return APValue::None;
-}
-llvm_unreachable("invalid ResultKind");
+return static_cast(ConstantExprBits.APValueKind);
   }
   ResultStorageKind getResultStorageKind() const {
 return static_cast(ConstantExprBits.ResultKind);
   }
   APValue getAPValueResult() const;
-
+  const APValue &getResultAsAPValue() const { return APValueResult(); }
+  llvm::APSInt getResultAsAPSInt() const;
   // Iterators
   child_range children() { return child_range(&SubExpr, &SubExpr+1); }
   const_child_range children() const {


[PATCH] D63376: [clang] Small improvments after Adding APValue to ConstantExpr

2019-06-21 Thread Tyker via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364011: [clang] Small improvments after Adding APValue to 
ConstantExpr (authored by Tyker, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63376?vs=205944&id=205948#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63376

Files:
  cfe/trunk/include/clang/AST/ASTContext.h
  cfe/trunk/include/clang/AST/Expr.h
  cfe/trunk/include/clang/AST/Stmt.h
  cfe/trunk/lib/AST/ASTContext.cpp
  cfe/trunk/lib/AST/Expr.cpp
  cfe/trunk/lib/AST/ExprConstant.cpp
  cfe/trunk/lib/Sema/SemaDeclCXX.cpp
  cfe/trunk/lib/Sema/SemaExpr.cpp

Index: cfe/trunk/include/clang/AST/Stmt.h
===
--- cfe/trunk/include/clang/AST/Stmt.h
+++ cfe/trunk/include/clang/AST/Stmt.h
@@ -332,6 +332,9 @@
 /// The kind of result that is trail-allocated.
 unsigned ResultKind : 2;
 
+/// Kind of Result as defined by APValue::Kind
+unsigned APValueKind : 4;
+
 /// When ResultKind == RSK_Int64. whether the trail-allocated integer is
 /// signed.
 unsigned IsUnsigned : 1;
@@ -340,6 +343,10 @@
 /// integer. 7 bits because it is the minimal number of bit to represent a
 /// value from 0 to 64 (the size of the trail-allocated number).
 unsigned BitWidth : 7;
+
+/// When ResultKind == RSK_APValue. Wether the ASTContext will cleanup the
+/// destructor on the trail-allocated APValue.
+unsigned HasCleanup : 1;
   };
 
   class PredefinedExprBitfields {
Index: cfe/trunk/include/clang/AST/Expr.h
===
--- cfe/trunk/include/clang/AST/Expr.h
+++ cfe/trunk/include/clang/AST/Expr.h
@@ -998,6 +998,9 @@
EmptyShell Empty);
 
   static ResultStorageKind getStorageKind(const APValue &Value);
+  static ResultStorageKind getStorageKind(const Type *T,
+  const ASTContext &Context);
+
   SourceLocation getBeginLoc() const LLVM_READONLY {
 return SubExpr->getBeginLoc();
   }
@@ -1009,25 +1012,20 @@
 return T->getStmtClass() == ConstantExprClass;
   }
 
-  void SetResult(APValue Value) { MoveIntoResult(Value); }
-  void MoveIntoResult(APValue &Value);
+  void SetResult(APValue Value, const ASTContext &Context) {
+MoveIntoResult(Value, Context);
+  }
+  void MoveIntoResult(APValue &Value, const ASTContext &Context);
 
   APValue::ValueKind getResultAPValueKind() const {
-switch (ConstantExprBits.ResultKind) {
-case ConstantExpr::RSK_APValue:
-  return APValueResult().getKind();
-case ConstantExpr::RSK_Int64:
-  return APValue::Int;
-case ConstantExpr::RSK_None:
-  return APValue::None;
-}
-llvm_unreachable("invalid ResultKind");
+return static_cast(ConstantExprBits.APValueKind);
   }
   ResultStorageKind getResultStorageKind() const {
 return static_cast(ConstantExprBits.ResultKind);
   }
   APValue getAPValueResult() const;
-
+  const APValue &getResultAsAPValue() const { return APValueResult(); }
+  llvm::APSInt getResultAsAPSInt() const;
   // Iterators
   child_range children() { return child_range(&SubExpr, &SubExpr+1); }
   const_child_range children() const {
Index: cfe/trunk/include/clang/AST/ASTContext.h
===
--- cfe/trunk/include/clang/AST/ASTContext.h
+++ cfe/trunk/include/clang/AST/ASTContext.h
@@ -2751,12 +2751,11 @@
   ///
   /// \param Data Pointer data that will be provided to the callback function
   /// when it is called.
-  void AddDeallocation(void (*Callback)(void*), void *Data);
+  void AddDeallocation(void (*Callback)(void *), void *Data) const;
 
   /// If T isn't trivially destructible, calls AddDeallocation to register it
   /// for destruction.
-  template 
-  void addDestruction(T *Ptr) {
+  template  void addDestruction(T *Ptr) const {
 if (!std::is_trivially_destructible::value) {
   auto DestroyPtr = [](void *V) { static_cast(V)->~T(); };
   AddDeallocation(DestroyPtr, Ptr);
@@ -2819,10 +2818,6 @@
   APValue *getMaterializedTemporaryValue(const MaterializeTemporaryExpr *E,
  bool MayCreate);
 
-  /// Adds an APValue that will be destructed during the destruction of the
-  /// ASTContext.
-  void AddAPValueCleanup(APValue *Ptr) const { APValueCleanups.push_back(Ptr); }
-
   /// Return a string representing the human readable name for the specified
   /// function declaration or file name. Used by SourceLocExpr and
   /// PredefinedExpr to cache evaluated results.
@@ -2989,7 +2984,7 @@
   // in order to track and run destructors while we're tearing things down.
   using DeallocationFunctionsAndArguments =
   llvm::SmallVector, 16>;
-  DeallocationFunctionsAndArguments Deallocations;
+

[PATCH] D61842: [clangd] [WIP] [Not ready for review] Semantic highlighting

2019-06-21 Thread Nikolai Kosjar via Phabricator via cfe-commits
nik added a comment.

Some general notes regarding the current state of this patch as I was testing 
it with a language client:

- It still applies for current trunk, except for a *Tests* file.
- Note that a VersionedTextDocumentIdentifier has to be used, e.g. a "version" 
must be included in the response. This helped to get it working for now (not a 
proper fix):



  --- clang-tools-extra/clangd/Protocol.cpp
  +++ clang-tools-extra/clangd/Protocol.cpp
  @@ -79,11 +79,11 @@ llvm::json::Value toJSON(const URIForFile &U) { return 
U.uri(); }
   llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const URIForFile &U) {
 return OS << U.uri();
   }
   
   llvm::json::Value toJSON(const TextDocumentIdentifier &R) {
  -  return llvm::json::Object{{"uri", R.uri}};
  +  return llvm::json::Object{{"uri", R.uri}, {"version", nullptr}};
   }
   
   bool fromJSON(const llvm::json::Value &Params, TextDocumentIdentifier &R) {
 llvm::json::ObjectMapper O(Params);
 return O && O.map("uri", R.uri);


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61842



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


[PATCH] D63559: [clang-tidy] Added functionality for getting semantic highlights for variable and function declarations

2019-06-21 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

Thanks, I think we can simplify the interface further, see my comments inline.

The boundary of this patch seems unclear, currently it contains C++ APIs, and 
some implementations for semantic highlighting LSP. I think we should merely 
focus on the C++ APIs in this patch.




Comment at: clang-tools-extra/clangd/SemanticHighlight.cpp:32
+  void addSymbol(Decl *D, SemanticScope Scope) {
+auto Loc = D->getLocation();
+SemanticToken S;

Looks like the code doesn't handle the case where D is expanded from a macro 
(Loc is a macro location).



Comment at: clang-tools-extra/clangd/SemanticHighlight.cpp:129
+std::vector> getSemanticScopes() {
+  return {{"variable"}, {"entity.name.function"}};
+}

This is Textmate-specific, I think we should lift it to a new File 
(TextMate.cpp). We can do it in a separate patch.

I'd use a map to explicitly express the relationship between `SemanticScope` 
and TextMate scope, the current implementation is not obvious.

```
{SemanticScope::Function, "entity.name.function"},
{SemanticScope::Variable, "variable.other"},
```



Comment at: clang-tools-extra/clangd/SemanticHighlight.cpp:133
+std::vector getASTHighlights(ASTContext &AST) {
+  SemanticSymbolASTCollector Collector(AST);
+  Collector.TraverseAST(AST);

We should only collect the highlights from the main AST, I think we should set 
traversal scope only to `localTopDecls` (use `ParsedAST` as parameter would 
help here)

`ASTCtx.setTraversalScope(MainAST.getLocalTopLevelDecls());` 



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:14
+//===--===//
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICSYMBOLASTCOLLECTOR_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICSYMBOLASTCOLLECTOR_H

nit: the name of header guard doesn't reflect the file name.



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:21
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Lex/Lexer.h"
+

please clean-up your #includes:
-  Headers.h is unused
- we use RecursiveASTVisitor, Lexer in the .cpp file, we should include these 
headers in the .cpp file rather the `.h` file.



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:26
+
+// ScopeIndex represents the mapping from the scopes list to a type of
+// expression.

The comment seems not very related to this structure.

We'd use this `enum` class to find a corresponding `TextMate` scope in the 
future, but this is implementation detail, the comment here should mention the 
high-level things about this structure.



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:28
+// expression.
+enum class SemanticScope : int {
+  VariableDeclaration = 0,

TextMate is using the term `scope` for different tokens, but the scope has 
different meaning in C++ world (usually the namespace "ns::" of a symbol). I'd 
avoid using this word in the C++ interface.

Just `SemanticHighlightingKind`?



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:29
+enum class SemanticScope : int {
+  VariableDeclaration = 0,
+  FunctionDeclaration = 1,

not exactly sure whether we should distinguish these cases at the moment 
(function declaration vs function calls, variable declaration vs variable 
references).

I think we could just use `Variable`, `Function` at the beginning, and add more 
kinds afterwards.





Comment at: clang-tools-extra/clangd/SemanticHighlight.h:39
+  SemanticScope Scope;
+  Position StartPosition;
+  unsigned int Len;

instead of using `start position + length`, I'd use `Range R;`



Comment at: clang-tools-extra/clangd/SemanticHighlight.h:61
+// ascending order by their coumn number.
+std::vector getASTHighlights(ASTContext &AST);
+std::vector> getSemanticScopes();

I'd drop the `AST` word, how about naming it "getSemanticHighlights"?

I think we can just return "vector", and we could we could 
group them by line when returning a LSP result. 

The function parameter should be `ParsedAST`.



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


RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread via cfe-commits
Hi Rainer,

Your change appears to have broken the one platform you didn't test, Windows. :)

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26514/steps/test/logs/stdio

FAIL: Clang :: Driver/cl-response-file.c (8601 of 50455)
 TEST 'Clang :: Driver/cl-response-file.c' FAILED 

Script:
--
: 'RUN: at line 7';   printf 
'/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
 /DFOO=2' > 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp
: 'RUN: at line 8';   
c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe
 --driver-mode=cl /c -### 
@C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp
 -- 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\cl-response-file.c
 2>&1 | 
c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\filecheck.exe
 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\cl-response-file.c
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 7"
$ "printf" 
"/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
 /DFOO=2"
$ ":" "RUN: at line 8"
$ 
"c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe"
 "--driver-mode=cl" "/c" "-###" 
"@C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp"
 "--" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\cl-response-file.c"
$ 
"c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\filecheck.exe"
 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\cl-response-file.c"
# command stderr:
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\cl-response-file.c:10:11:
 error: CHECK: expected string not found in input

// CHECK: "-I" "{{.*}}\\Inputs\\cl-response-file\\" "-D" "FOO=2"

  ^

:1:1: note: scanning from here

clang version 9.0.0 (trunk 364011)

^

:6:2360: note: possible intended match here

 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\bin\\clang.exe"
 "-cc1" "-triple" "x86_64-pc-windows-msvc19.16.27026" "-emit-obj" "-mrelax-all" 
"-mincremental-linker-compatible" "-disable-free" "-main-file-name" 
"cl-response-file.c" "-mrelocation-model" "pic" "-pic-level" "2" 
"-mthread-model" "posix" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" 
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" 
"-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" 
"--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" 
"-fms-volatile" "-fdiagnostics-format" "msvc" "-dwarf-column-info" 
"-momit-leaf-frame-pointer" "-coverage-notes-file" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\tools\\clang\\test\\Driver\\cl-response-file.gcno"
 "-resource-dir" 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\lib\\clang\\9.0.0"
 "-I" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.src"
 "-internal-isystem" 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\lib\\clang\\9.0.0\\include"
 "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.16.27023\\ATLMFC\\include" 
"-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.16.27023\\include" 
"-internal-isystem" "C:\\Program Files (x86)\\Windows 
Kits\\NETFXSDK\\4.6.1\\include\\um" "-internal-isystem" "C:\\Program Files 
(x86)\\Windows Kits\\10\\include\\10.0.17763.0\\ucrt" "-internal-isystem" 
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\shared" 
"-internal-isystem" "C:\\Program Files (x86)\\Windows 
Kits\\10\\include\\10.0.17763.0\\um" "-internal-isystem" "C:\\Program Files 
(x86)\\Windows Kits\\10\\include\\10.0.17763.0\\winrt" "-internal-isystem" 
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\cppwinrt" 
"-fdebug-compilation-dir" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\tools\\clang\\test\\Driver"
 "-ferror-limit" "19" "-fmessage-length" "0" "-fno-use-cxa-atexit" 
"-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.16.27026" 
"-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" 
"-faddrsig" "-o" "cl-response-file.o

[PATCH] D63621: [git-clang-format] recognize hxx as a C++ file

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a reviewer: ilya-biryukov.
ilya-biryukov added a comment.

LGTM.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63621



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


Re: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon empty database fields

2019-06-21 Thread Serge Guelton via cfe-commits
On Fri, Jun 21, 2019 at 08:16:42AM +, douglas.y...@sony.com wrote:
> Hi Serge,
> 
> The test you added here is failing on the PS4 Windows build bot, can you take 
> a look?

Sure, thanks for fwding it!

> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26513/steps/test/logs/stdio

The error message seems to be OS-dependant, I do have a ttrivial patch, do you 
have means to reproduce the issue?

-- serge

> FAIL: Clang Tools :: clang-tidy/empty-database.cpp (14917 of 50455)
>  TEST 'Clang Tools :: clang-tidy/empty-database.cpp' 
> FAILED 
> Script:
> --
> : 'RUN: at line 1';   not clang-tidy -p 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
>  2>&1 | FileCheck 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
> --
> Exit Code: 1
> 
> Command Output (stdout):
> --
> $ ":" "RUN: at line 1"
> $ "not" "clang-tidy" "-p" 
> "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database"
>  
> "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
> note: command had no output on stdout or stderr
> error: command failed with exit status: 1
> $ "FileCheck" 
> "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
> # command stderr:
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp:3:11:
>  error: CHECK: expected string not found in input
> 
> // CHECK: LLVM ERROR: Cannot chdir into ""!
> 
>   ^
> 
> :1:1: note: scanning from here
> 
> Skipping 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
>  Compile command not found.
> 
> ^
> 
> :1:150: note: possible intended match here
> 
> Skipping 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
>  Compile command not found.
> 
>   
>^
> 
> 
> error: command failed with exit status: 1
> 
> Douglas Yung
> 
> -Original Message-
> From: cfe-commits  On Behalf Of Serge 
> Guelton via cfe-commits
> Sent: Thursday, June 20, 2019 13:26
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon 
> empty database fields
> 
> Author: serge_sans_paille
> Date: Thu Jun 20 13:25:59 2019
> New Revision: 363975
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=363975&view=rev
> Log:
> [clang-tidy] Fail gracefully upon empty database fields
> 
> Fix bz#42281
> 
> Differential Revision: https://reviews.llvm.org/D63613
> 
> Added:
> clang-tools-extra/trunk/test/clang-tidy/empty-database/
> clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
> 
> clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json
> 
> Added: clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp?rev=363975&view=auto
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp (added)
> +++ clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp Thu Jun 20 
> 13:25:59 2019
> @@ -0,0 +1,3 @@
> +// RUN: not clang-tidy -p %S/empty-database %s 2>&1 | FileCheck %s
> +
> +// CHECK: LLVM ERROR: Cannot chdir into ""!
> 
> Added: 
> clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json?rev=363975&view=auto
> ==
> --- 
> clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
> (added)
> +++ 
> clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
> Thu Jun 20 13:25:59 2019
> @@ -0,0 +1,4 @@
> +[{
> +"directory":"",
> +"file":"/tmp/","arguments":[]
> +}]
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lis

r364014 - [git-clang-format] recognize hxx as a C++ file

2019-06-21 Thread Miklos Vajna via cfe-commits
Author: vmiklos
Date: Fri Jun 21 02:49:38 2019
New Revision: 364014

URL: http://llvm.org/viewvc/llvm-project?rev=364014&view=rev
Log:
[git-clang-format] recognize hxx as a C++ file

clangd, clang-tidy, etc does that already, no reason why
git-clang-format should skip hxx files.

Reviewed By: ilya-biryukov

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

Modified:
cfe/trunk/tools/clang-format/git-clang-format

Modified: cfe/trunk/tools/clang-format/git-clang-format
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/git-clang-format?rev=364014&r1=364013&r2=364014&view=diff
==
--- cfe/trunk/tools/clang-format/git-clang-format (original)
+++ cfe/trunk/tools/clang-format/git-clang-format Fri Jun 21 02:49:38 2019
@@ -77,7 +77,7 @@ def main():
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp', 'hxx',  # C++
   'cu',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers


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


[PATCH] D63621: [git-clang-format] recognize hxx as a C++ file

2019-06-21 Thread Miklos Vajna via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364014: [git-clang-format] recognize hxx as a C++ file 
(authored by vmiklos, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63621?vs=205884&id=205953#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63621

Files:
  cfe/trunk/tools/clang-format/git-clang-format


Index: cfe/trunk/tools/clang-format/git-clang-format
===
--- cfe/trunk/tools/clang-format/git-clang-format
+++ cfe/trunk/tools/clang-format/git-clang-format
@@ -77,7 +77,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp', 'hxx',  # C++
   'cu',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers


Index: cfe/trunk/tools/clang-format/git-clang-format
===
--- cfe/trunk/tools/clang-format/git-clang-format
+++ cfe/trunk/tools/clang-format/git-clang-format
@@ -77,7 +77,7 @@
   'c', 'h',  # C
   'm',  # ObjC
   'mm',  # ObjC++
-  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp',  # C++
+  'cc', 'cp', 'cpp', 'c++', 'cxx', 'hpp', 'hxx',  # C++
   'cu',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D63621: [git-clang-format] recognize hxx as a C++ file

2019-06-21 Thread Miklos Vajna via Phabricator via cfe-commits
vmiklos added a comment.

Thanks!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63621



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


[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

2019-06-21 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus updated this revision to Diff 205954.
Szelethus added a comment.

- Collect only `ExplodedNode`s. Lesson learned!
- Add a `TODO:` in `trackExpressionValue` about maybe tracking conditions to 
all bug locations, rather than only for tracked variables.


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

https://reviews.llvm.org/D62883

Files:
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/track-control-dependency-conditions.cpp

Index: clang/test/Analysis/track-control-dependency-conditions.cpp
===
--- /dev/null
+++ clang/test/Analysis/track-control-dependency-conditions.cpp
@@ -0,0 +1,287 @@
+// RUN: %clang_analyze_cc1 %s -verify -DTRACKING_CONDITIONS \
+// RUN:   -analyzer-config track-conditions=true \
+// RUN:   -analyzer-output=text \
+// RUN:   -analyzer-checker=core
+//
+// RUN: %clang_analyze_cc1 %s -verify \
+// RUN:   -analyzer-output=text \
+// RUN:   -analyzer-checker=core
+
+namespace example_1 {
+int flag;
+bool coin();
+
+void foo() {
+  flag = coin();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Value assigned to 'flag'}}
+#endif // TRACKING_CONDITIONS
+}
+
+void test() {
+  int *x = 0; // expected-note{{'x' initialized to a null pointer value}}
+  flag = 1;
+
+  foo(); // TODO: Add nodes here about flag's value being invalidated.
+  if (flag) // expected-note   {{Assuming 'flag' is 0}}
+// expected-note@-1{{Taking false branch}}
+x = new int;
+
+  foo();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Calling 'foo'}}
+  // expected-note@-3{{Returning from 'foo'}}
+#endif // TRACKING_CONDITIONS
+
+  if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
+// expected-note@-1{{Taking true branch}}
+*x = 5; // expected-warning{{Dereference of null pointer}}
+// expected-note@-1{{Dereference of null pointer}}
+}
+} // end of namespace example_1
+
+namespace example_2 {
+int flag;
+bool coin();
+
+void foo() {
+  flag = coin();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Value assigned to 'flag'}}
+#endif // TRACKING_CONDITIONS
+}
+
+void test() {
+  int *x = 0;
+  flag = 1;
+
+  foo();
+  if (flag) // expected-note   {{Assuming 'flag' is 0}}
+// expected-note@-1{{Taking false branch}}
+x = new int;
+
+  x = 0; // expected-note{{Null pointer value stored to 'x'}}
+
+  foo();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Calling 'foo'}}
+  // expected-note@-3{{Returning from 'foo'}}
+#endif // TRACKING_CONDITIONS
+
+  if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
+// expected-note@-1{{Taking true branch}}
+*x = 5; // expected-warning{{Dereference of null pointer}}
+// expected-note@-1{{Dereference of null pointer}}
+}
+} // end of namespace example_2
+
+namespace global_variable_invalidation {
+int flag;
+bool coin();
+
+void foo() {
+  // coin() could write bar, do it's invalidated.
+  flag = coin();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Value assigned to 'flag'}}
+  // expected-note@-3{{Value assigned to 'bar'}}
+#endif // TRACKING_CONDITIONS
+}
+
+int bar;
+
+void test() {
+  int *x = 0; // expected-note{{'x' initialized to a null pointer value}}
+  flag = 1;
+
+  foo();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Calling 'foo'}}
+  // expected-note@-3{{Returning from 'foo'}}
+#endif // TRACKING_CONDITIONS
+
+  if (bar) // expected-note   {{Assuming 'bar' is not equal to 0}}
+   // expected-note@-1{{Taking true branch}}
+if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
+  // expected-note@-1{{Taking true branch}}
+  *x = 5; // expected-warning{{Dereference of null pointer}}
+  // expected-note@-1{{Dereference of null pointer}}
+}
+} // end of namespace global_variable_invalidation
+
+namespace variable_declaration_in_condition {
+bool coin();
+
+bool foo() {
+  return coin();
+#ifdef TRACKING_CONDITIONS
+  // expected-note@-2{{Returning value}}
+#endif // TRACKING_CONDITIONS
+}
+
+int bar;
+
+void test() {
+  int *x = 0; // expected-note{{'x' initialized to a null pointer value}}
+
+  if (int flag = foo())
+#ifdef TRACKING_CONDITIONS
+// expected-note@-2{{Calling 'foo'}}
+// expected-note@-3{{Returning from 'foo'}}
+// expected-note@-4{{'flag' initialized here}}
+#endif // TRACKING_CONDITIONS
+// expected-note@-6{{Assuming 'flag' is not equal to 0}}
+// expected-note@-7{{Taking true branch}}
+*x = 5; // expected-warning{{Dereference of null pointer}}
+// expected-note@-1{{Dereference of null pointer}}
+}
+} // end of namespace variable_declaration_in_condition
+
+namespace conversion_to_bool {
+bool coin();
+
+struct ConvertsToBool {
+  operator bool() 

[PATCH] D63498: [RISC-V] Add -msave-restore and -mno-save-restore to clang driver

2019-06-21 Thread Sam Elliott via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364018: [RISC-V] Add -msave-restore and -mno-save-restore to 
clang driver (authored by lenary, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63498?vs=205846&id=205955#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63498

Files:
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
  cfe/trunk/test/Driver/riscv-features.c


Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -358,6 +358,16 @@
   else
 Features.push_back("-relax");
 
+  // -mno-save-restore is default, unless -msave-restore is specified.
+  if (Args.hasFlag(options::OPT_msave_restore, options::OPT_mno_save_restore, 
false)) {
+Features.push_back("+save-restore");
+// ... but we don't yet support +save-restore, so issue a warning.
+D.Diag(diag::warn_drv_clang_unsupported)
+  << Args.getLastArg(options::OPT_msave_restore)->getAsString(Args);
+  } else {
+Features.push_back("-save-restore");
+  }
+
   // Now add any that the user explicitly requested on the command line,
   // which may override the defaults.
   handleTargetFeaturesGroup(Args, Features, 
options::OPT_m_riscv_Features_Group);
Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -2130,6 +2130,10 @@
   HelpText<"Enable linker relaxation">;
 def mno_relax : Flag<["-"], "mno-relax">, Group,
   HelpText<"Disable linker relaxation">;
+def msave_restore : Flag<["-"], "msave-restore">, 
Group,
+  HelpText<"Enable using library calls for save and restore">;
+def mno_save_restore : Flag<["-"], "mno-save-restore">, 
Group,
+  HelpText<"Disable using library calls for save and restore">;
 
 def munaligned_access : Flag<["-"], "munaligned-access">, 
Group,
   HelpText<"Allow memory accesses to be unaligned (AArch32/AArch64 only)">;
Index: cfe/trunk/test/Driver/riscv-features.c
===
--- cfe/trunk/test/Driver/riscv-features.c
+++ cfe/trunk/test/Driver/riscv-features.c
@@ -3,11 +3,23 @@
 
 // CHECK: fno-signed-char
 
+// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
+
 // RUN: %clang -target riscv32-unknown-elf -### %s -mrelax 2>&1 | FileCheck %s 
-check-prefix=RELAX
 // RUN: %clang -target riscv32-unknown-elf -### %s -mno-relax 2>&1 | FileCheck 
%s -check-prefix=NO-RELAX
-// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
 
 // RELAX: "-target-feature" "+relax"
 // NO-RELAX: "-target-feature" "-relax"
 // DEFAULT: "-target-feature" "+relax"
 // DEFAULT-NOT: "-target-feature" "-relax"
+
+// RUN: %clang -target riscv32-unknown-elf -### %s -msave-restore 2>&1 | 
FileCheck %s -check-prefix=SAVE-RESTORE
+// RUN: %clang -target riscv32-unknown-elf -### %s -mno-save-restore 2>&1 | 
FileCheck %s -check-prefix=NO-SAVE-RESTORE
+
+// SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
+// DEFAULT-NOT: warning: the clang compiler does not support
+
+// SAVE-RESTORE: "-target-feature" "+save-restore"
+// NO-SAVE-RESTORE: "-target-feature" "-save-restore"
+// DEFAULT: "-target-feature" "-save-restore"
+// DEFAULT-NOT: "-target-feature" "+save-restore"
\ No newline at end of file


Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -358,6 +358,16 @@
   else
 Features.push_back("-relax");
 
+  // -mno-save-restore is default, unless -msave-restore is specified.
+  if (Args.hasFlag(options::OPT_msave_restore, options::OPT_mno_save_restore, false)) {
+Features.push_back("+save-restore");
+// ... but we don't yet support +save-restore, so issue a warning.
+D.Diag(diag::warn_drv_clang_unsupported)
+  << Args.getLastArg(options::OPT_msave_restore)->getAsString(Args);
+  } else {
+Features.push_back("-save-restore");
+  }
+
   // Now add any that the user explicitly requested on the command line,
   // which may override the defaults.
   handleTargetFeaturesGroup(Args, Features, options::OPT_m_riscv_Features_Group);
Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -2130,6 +2130,10 @@
   HelpText<"Enable linker relaxation">;
 def mno_relax : 

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

2019-06-21 Thread Tyker via Phabricator via cfe-commits
Tyker created this revision.
Tyker added a reviewer: rsmith.
Herald added a reviewer: martong.
Herald added a reviewer: shafik.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
Tyker edited the summary of this revision.
Herald added a subscriber: rnkovacs.

Changes:

- initializer expressions of constexpr variable are now wraped in a 
ConstantExpr. this is mainly used for testing purposes. the old caching system 
has not yet been removed.
- Add Serialization and Importing of APValues for Struct, Array and Vectors.
- Cleanup leftover from last patch.
- Add Tests.


Repository:
  rC Clang

https://reviews.llvm.org/D63640

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTImporter.h
  clang/include/clang/AST/Expr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/PCH/APValue.cpp

Index: clang/test/PCH/APValue.cpp
===
--- /dev/null
+++ clang/test/PCH/APValue.cpp
@@ -0,0 +1,91 @@
+
+// RUN: %clang_cc1 -std=gnu++17 -emit-pch %s -o %t.pch
+// RUN: %clang_cc1 -std=gnu++17 -x c++ -include-pch %t.pch -ast-dump-all | FileCheck %s
+
+#ifndef EMIT
+#define EMIT
+
+namespace Integer {
+
+constexpr int Unique_Int = int(6789);
+//CHECK:  VarDecl {{.*}} Unique_Int
+//CHECK-NEXT: ConstantExpr {{.*}} 'int' 6789
+
+constexpr __uint128_t Unique_Int128 = ((__uint128_t)0x75f17d6b3588f843 << 64) | 0xb13dea7c9c324e51;
+//CHECK:  VarDecl {{.*}} Unique_Int128 
+//CHECK-NEXT: ConstantExpr {{.*}} 'unsigned __int128' 156773562844924187900898496343692168785
+
+}
+
+namespace FloatingPoint {
+
+constexpr double Unique_Double = double(567890.67890);
+//CHECK:  VarDecl {{.*}} Unique_Double
+//CHECK-NEXT: ConstantExpr {{.*}} 'double' 5.678907e+05
+
+}
+
+// FIXME: Add test for FixePoint, ComplexInt, ComplexFloat.
+// as they are C features they need to be treated differently.
+
+namespace Struct {
+
+struct B {
+  int i;
+  double d;
+};
+
+constexpr B Basic_Struct = B{1, 0.7};
+//CHECK:  VarDecl {{.*}} Basic_Struct
+//CHECK-NEXT: ConstantExpr {{.*}} 'const Struct::B' {1, 7.00e-01}
+
+struct C {
+  int i = 9;
+};
+
+struct A : B {
+  int i;
+  double d;
+  C c;
+};
+
+constexpr A Advanced_Struct = A{Basic_Struct, 1, 79.789, {}};
+//CHECK:  VarDecl {{.*}} Advanced_Struct
+//CHECK-NEXT: ConstantExpr {{.*}} 'const Struct::A' {{[{][{]}}1, 7.00e-01}, 1, 7.978900e+01, {9}}
+
+}
+
+namespace Vector {
+
+using v4si = int __attribute__((__vector_size__(16)));
+
+constexpr v4si Vector_Int = (v4si){8, 2, 3};
+//CHECK:  VarDecl {{.*}} Vector_Int
+//CHECK-NEXT: ConstantExpr {{.*}} 'Vector::v4si':'__attribute__((__vector_size__(4 * sizeof(int int' {8, 2, 3, 0}
+
+}
+
+namespace Array {
+
+constexpr int Array_Int[] = {1, 2, 3, 4, 5, 6};
+//CHECK:  VarDecl {{.*}} Array_Int
+//CHECK-NEXT: ConstantExpr {{.*}} 'const int [6]' {1, 2, 3, 4, 5, 6}
+
+struct A {
+  int i = 789;
+  double d = 67890.09876;
+};
+
+constexpr A Array2_Struct[][3] = {{{}, {-45678, 9.8}, {9}}, {{}}};
+//CHECK:  VarDecl {{.*}} Array2_Struct
+//CHECK-NEXT: ConstantExpr {{.*}} 'Array::A const [2][3]' {{[{][{]}}{789, 6.789010e+04}, {-45678, 9.80e+00}, {9, 6.789010e+04}}, {{[{][{]}}789, 6.789010e+04}, {789, 6.789010e+04}, {789, 6.789010e+04}}}
+
+using v4si = int __attribute__((__vector_size__(16)));
+
+constexpr v4si Array_Vector[] = {{1, 2, 3, 4}, {4, 5, 6, 7}};
+//CHECK:  VarDecl {{.*}} Array_Vector
+//CHECK-NEXT: ConstantExpr {{.*}} 'const Array::v4si [2]' {{[{][{]}}1, 2, 3, 4}, {4, 5, 6, 7}}
+
+}
+
+#endif
\ No newline at end of file
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5441,10 +5441,26 @@
 AddAPFloat(Value.getComplexFloatImag());
 return;
   }
-  case APValue::LValue:
   case APValue::Vector:
+push_back(Value.getVectorLength());
+for (unsigned Idx = 0; Idx < Value.getVectorLength(); Idx++)
+  AddAPValue(Value.getVectorElt(Idx));
+return;
   case APValue::Array:
+push_back(Value.getArrayInitializedElts());
+push_back(Value.getArraySize());
+for (unsigned Idx = 0; Idx < Value.getArrayInitializedElts(); Idx++)
+  AddAPValue(Value.getArrayInitializedElt(Idx));
+return;
   case APValue::Struct:
+push_back(Value.getStructNumBases());
+push_back(Value.getStructNumFields());
+for (unsigned Idx = 0; Idx < Value.getStructNumBases(); Idx++)
+  AddAPValue(Value.getStructBase(Idx));
+for (unsigned Idx = 0; Idx < Value.getStructNumFields(); Idx++)
+  AddAPValue(Value.getStructField(Idx));
+return;
+  case APValue::LValue:
   case APValue::Union:
   case APValue::MemberPointer:
   case APVa

r364021 - [cmake] Add llvm-dwarfdump to clang test dependencies

2019-06-21 Thread Sven van Haastregt via cfe-commits
Author: svenvh
Date: Fri Jun 21 03:26:20 2019
New Revision: 364021

URL: http://llvm.org/viewvc/llvm-project?rev=364021&view=rev
Log:
[cmake] Add llvm-dwarfdump to clang test dependencies

Commit r363496 ("[Clang] Harmonize Split DWARF options with llc",
2019-06-15) introduced the use of llvm-dwarfdump in the clang tests,
so ensure the clang tests are dependent on llvm-dwarfdump.

Modified:
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=364021&r1=364020&r2=364021&view=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Fri Jun 21 03:26:20 2019
@@ -106,6 +106,7 @@ if( NOT CLANG_BUILT_STANDALONE )
 llvm-cat
 llvm-cxxfilt
 llvm-dis
+llvm-dwarfdump
 llvm-lto2
 llvm-modextract
 llvm-nm


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


r364020 - [OpenCL] Remove duplicate read_image declarations

2019-06-21 Thread Sven van Haastregt via cfe-commits
Author: svenvh
Date: Fri Jun 21 03:26:10 2019
New Revision: 364020

URL: http://llvm.org/viewvc/llvm-project?rev=364020&view=rev
Log:
[OpenCL] Remove duplicate read_image declarations

Patch by Pierre Gondois.

Modified:
cfe/trunk/lib/Headers/opencl-c.h

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=364020&r1=364019&r2=364020&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Fri Jun 21 03:26:10 2019
@@ -14390,30 +14390,6 @@ float4 __purefn __ovld read_imagef(read_
 int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, 
float4 coord, float4 gradientX, float4 gradientY);
 uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t 
sampler, float4 coord, float4 gradientX, float4 gradientY);
 
-float4 __purefn __ovld read_imagef(read_only image1d_t image, sampler_t 
sampler, float coord, float lod);
-int4 __purefn __ovld read_imagei(read_only image1d_t image, sampler_t sampler, 
float coord, float lod);
-uint4 __purefn __ovld read_imageui(read_only image1d_t image, sampler_t 
sampler, float coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_only image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-int4 __purefn __ovld read_imagei(read_only image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_only image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_only image2d_t image, sampler_t 
sampler, float2 coord, float lod);
-int4 __purefn __ovld read_imagei(read_only image2d_t image, sampler_t sampler, 
float2 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_only image2d_t image, sampler_t 
sampler, float2 coord, float lod);
-
-float __purefn __ovld read_imagef(read_only image2d_depth_t image, sampler_t 
sampler, float2 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_only image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-int4 __purefn __ovld read_imagei(read_only image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_only image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-
-float __purefn __ovld read_imagef(read_only image2d_array_depth_t image, 
sampler_t sampler, float4 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_only image3d_t image, sampler_t 
sampler, float4 coord, float lod);
-int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, 
float4 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t 
sampler, float4 coord, float lod);
-
 #endif //cl_khr_mipmap_image
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
 
@@ -14573,29 +14549,6 @@ float4 __purefn __ovld read_imagef(read_
 int4 __purefn __ovld read_imagei(read_write image3d_t image, sampler_t 
sampler, float4 coord, float4 gradientX, float4 gradientY);
 uint4 __purefn __ovld read_imageui(read_write image3d_t image, sampler_t 
sampler, float4 coord, float4 gradientX, float4 gradientY);
 
-float4 __purefn __ovld read_imagef(read_write image1d_t image, sampler_t 
sampler, float coord, float lod);
-int4 __purefn __ovld read_imagei(read_write image1d_t image, sampler_t 
sampler, float coord, float lod);
-uint4 __purefn __ovld read_imageui(read_write image1d_t image, sampler_t 
sampler, float coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_write image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-int4 __purefn __ovld read_imagei(read_write image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_write image1d_array_t image_array, 
sampler_t sampler, float2 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_write image2d_t image, sampler_t 
sampler, float2 coord, float lod);
-int4 __purefn __ovld read_imagei(read_write image2d_t image, sampler_t 
sampler, float2 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_write image2d_t image, sampler_t 
sampler, float2 coord, float lod);
-
-float __purefn __ovld read_imagef(read_write image2d_depth_t image, sampler_t 
sampler, float2 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_write image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-int4 __purefn __ovld read_imagei(read_write image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-uint4 __purefn __ovld read_imageui(read_write image2d_array_t image_array, 
sampler_t sampler, float4 coord, float lod);
-
-float __purefn __ovld read_imagef(read_write image2d_array_depth_t image, 
sampler_t sampler, float4 coord, float lod);
-
-float4 __purefn __ovld read_imagef(read_write image3d_t image, sample

[PATCH] D59673: [Clang] Harmonize Split DWARF options with llc

2019-06-21 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh added a comment.

As a followup to r363496, I've added llvm-dwarfdump as a clang test dependency 
in r364021.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59673



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


r364023 - [Sema] Improved diagnostic for qualifiers in reference binding

2019-06-21 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Fri Jun 21 03:50:02 2019
New Revision: 364023

URL: http://llvm.org/viewvc/llvm-project?rev=364023&view=rev
Log:
[Sema] Improved diagnostic for qualifiers in reference binding

Improved wording and also simplified by using printing
method from qualifiers.

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


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp
cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp
cfe/trunk/test/CXX/expr/expr.post/expr.static.cast/p3-p4-0x.cpp
cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
cfe/trunk/test/Misc/diag-template-diffing.cpp
cfe/trunk/test/SemaCXX/builtins-arm.cpp
cfe/trunk/test/SemaCXX/err_reference_bind_drops_quals.cpp
cfe/trunk/test/SemaCXX/references.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=364023&r1=364022&r2=364023&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jun 21 03:50:02 
2019
@@ -1851,10 +1851,8 @@ def err_lvalue_reference_bind_to_unrelat
   "%diff{to type $ cannot bind to a value of unrelated type $|"
   "cannot bind to a value of unrelated type}1,2">;
 def err_reference_bind_drops_quals : Error<
-  "binding value %diff{of type $ to reference to type $|to reference}0,1 "
-  "drops %select{<>|'const'|'restrict'|'const' and 'restrict'|"
-  "'volatile'|'const' and 'volatile'|'restrict' and 'volatile'|"
-  "'const', 'restrict', and 'volatile'}2 qualifier%plural{1:|2:|4:|:s}2">;
+  "binding reference %diff{of type $ to value of type $|to value}0,1 "
+  "drops %2 qualifier%plural{1:|2:|4:|:s}3">;
 def err_reference_bind_failed : Error<
   "reference %diff{to %select{type|incomplete type}1 $ could not bind to an "
   "%select{rvalue|lvalue}2 of type $|could not bind to %select{rvalue|lvalue}2 
of "

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=364023&r1=364022&r2=364023&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Jun 21 03:50:02 2019
@@ -8522,8 +8522,9 @@ bool InitializationSequence::Diagnose(Se
 SourceType.getQualifiers() - NonRefType.getQualifiers();
 
 S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
-  << SourceType
   << NonRefType
+  << SourceType
+  << Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
   << DroppedQualifiers.getCVRQualifiers()
   << Args[0]->getSourceRange();
 break;

Modified: cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp?rev=364023&r1=364022&r2=364023&view=diff
==
--- cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp (original)
+++ cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp Fri Jun 21 
03:50:02 2019
@@ -122,8 +122,8 @@ namespace std_example_2 {
 
   const double& rcd2 = 2;
   double&& rrd = 2;
-  const volatile int cvi = 1; 
-  const int& r2 = cvi; // expected-error{{binding value of type 'const 
volatile int' to reference to type 'const int' drops 'volatile' qualifier}}
+  const volatile int cvi = 1;
+  const int& r2 = cvi; // expected-error{{binding reference of type 'const 
int' to value of type 'const volatile int' drops 'volatile' qualifier}}
 
   double d;
   double&& rrd2 = d; // expected-error{{rvalue reference to type 'double' 
cannot bind to lvalue of type 'double'}}

Modified: cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp?rev=364023&r1=364022&r2=364023&view=diff
==
--- cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp (original)
+++ cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp Fri Jun 21 
03:50:02 2019
@@ -69,10 +69,10 @@ void bind_lvalue_quals(volatile Base b,
volatile const int ivc) {
   volatile Base &bvr1 = b;
   volatile Base &bvr2 = d;
-  volatile Base &bvr3 = bvc; // expected-error{{binding value of type 'const 
volatile Base' to reference to type 'volatile Base' drops 'const' qualifier}}
-  volatile Base &bvr4 = dvc; // expected-error{{binding value of type 'const 
volatile Derived' to reference to type 'volatile Base' drops 'const' qualifier}}
-  
-  volatile int &ir = ivc; // expected-error{{binding value of typ

[PATCH] D62914: [Sema] Fix diagnostic for addr spaces in reference binding

2019-06-21 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364023: [Sema] Improved diagnostic for qualifiers in 
reference binding (authored by stulova, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62914?vs=203172&id=205961#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62914

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaInit.cpp
  cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-0x.cpp
  cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-var.cpp
  cfe/trunk/test/CXX/expr/expr.post/expr.static.cast/p3-p4-0x.cpp
  cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
  cfe/trunk/test/Misc/diag-template-diffing.cpp
  cfe/trunk/test/SemaCXX/builtins-arm.cpp
  cfe/trunk/test/SemaCXX/err_reference_bind_drops_quals.cpp
  cfe/trunk/test/SemaCXX/references.cpp

Index: cfe/trunk/lib/Sema/SemaInit.cpp
===
--- cfe/trunk/lib/Sema/SemaInit.cpp
+++ cfe/trunk/lib/Sema/SemaInit.cpp
@@ -8522,8 +8522,9 @@
 SourceType.getQualifiers() - NonRefType.getQualifiers();
 
 S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
-  << SourceType
   << NonRefType
+  << SourceType
+  << Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
   << DroppedQualifiers.getCVRQualifiers()
   << Args[0]->getSourceRange();
 break;
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1851,10 +1851,8 @@
   "%diff{to type $ cannot bind to a value of unrelated type $|"
   "cannot bind to a value of unrelated type}1,2">;
 def err_reference_bind_drops_quals : Error<
-  "binding value %diff{of type $ to reference to type $|to reference}0,1 "
-  "drops %select{<>|'const'|'restrict'|'const' and 'restrict'|"
-  "'volatile'|'const' and 'volatile'|'restrict' and 'volatile'|"
-  "'const', 'restrict', and 'volatile'}2 qualifier%plural{1:|2:|4:|:s}2">;
+  "binding reference %diff{of type $ to value of type $|to value}0,1 "
+  "drops %2 qualifier%plural{1:|2:|4:|:s}3">;
 def err_reference_bind_failed : Error<
   "reference %diff{to %select{type|incomplete type}1 $ could not bind to an "
   "%select{rvalue|lvalue}2 of type $|could not bind to %select{rvalue|lvalue}2 of "
Index: cfe/trunk/test/SemaCXX/err_reference_bind_drops_quals.cpp
===
--- cfe/trunk/test/SemaCXX/err_reference_bind_drops_quals.cpp
+++ cfe/trunk/test/SemaCXX/err_reference_bind_drops_quals.cpp
@@ -6,31 +6,31 @@
volatile ptr vp, const volatile ptr cvp, restrict volatile ptr rvp,
const restrict volatile ptr crvp) {
   ptr& p1 = p;
-  ptr& p2 = cp; // expected-error {{drops 'const' qualifier}}
-  ptr& p3 = rp; // expected-error {{drops 'restrict' qualifier}}
-  ptr& p4 = crp; // expected-error {{drops 'const' and 'restrict' qualifiers}}
-  ptr& p5 = vp; // expected-error {{drops 'volatile' qualifier}}
-  ptr& p6 = cvp; // expected-error {{drops 'const' and 'volatile' qualifiers}}
-  ptr& p7 = rvp; // expected-error {{drops 'restrict' and 'volatile' qualifiers}}
-  ptr& p8 = crvp; // expected-error {{drops 'const', 'restrict', and 'volatile' qualifiers}}
+  ptr& p2 = cp;   // expected-error {{drops 'const' qualifier}}
+  ptr& p3 = rp;   // expected-error {{drops '__restrict' qualifier}}
+  ptr& p4 = crp;  // expected-error {{drops 'const __restrict' qualifiers}}
+  ptr& p5 = vp;   // expected-error {{drops 'volatile' qualifier}}
+  ptr& p6 = cvp;  // expected-error {{drops 'const volatile' qualifiers}}
+  ptr& p7 = rvp;  // expected-error {{drops 'volatile __restrict' qualifiers}}
+  ptr& p8 = crvp; // expected-error {{drops 'const volatile __restrict' qualifiers}}
 
   const ptr& cp1 = p;
   const ptr& cp2 = cp;
-  const ptr& cp3 = rp; // expected-error {{drops 'restrict' qualifier}}
-  const ptr& cp4 = crp; // expected-error {{drops 'restrict' qualifier}}
-  const ptr& cp5 = vp; // expected-error {{drops 'volatile' qualifier}}
-  const ptr& cp6 = cvp; // expected-error {{drops 'volatile' qualifier}}
-  const ptr& cp7 = rvp; // expected-error {{drops 'restrict' and 'volatile' qualifiers}}
-  const ptr& cp8 = crvp; // expected-error {{drops 'restrict' and 'volatile' qualifiers}}
+  const ptr& cp3 = rp;   // expected-error {{drops '__restrict' qualifier}}
+  const ptr& cp4 = crp;  // expected-error {{drops '__restrict' qualifier}}
+  const ptr& cp5 = vp;   // expected-error {{drops 'volatile' qualifier}}
+  const ptr& cp6 = cvp;  // expected-error {{drops 'volatile' qualifier}}
+  const ptr& cp7 = rvp;  // expected-error {{drops 'volatile __restrict' qu

[PATCH] D63426: [clangd] Narrow rename to local symbols.

2019-06-21 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 205963.
hokein added a comment.

Improve the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63426

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
  clang/lib/Tooling/Refactoring/Rename/RenamingAction.cpp

Index: clang/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
===
--- clang/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
+++ clang/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
@@ -74,6 +74,8 @@
std::move(NewName));
 }
 
+const NamedDecl *RenameOccurrences::getRenameDecl() const { return ND; }
+
 Expected
 RenameOccurrences::createSourceReplacements(RefactoringRuleContext &Context) {
   Expected Occurrences = findSymbolOccurrences(ND, Context);
Index: clang/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
===
--- clang/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
+++ clang/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
@@ -54,6 +54,8 @@
 
   static const RefactoringDescriptor &describe();
 
+  const NamedDecl *getRenameDecl() const;
+
 private:
   RenameOccurrences(const NamedDecl *ND, std::string NewName)
   : ND(ND), NewName(std::move(NewName)) {}
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -18,6 +18,10 @@
 namespace clangd {
 namespace {
 
+MATCHER_P2(RenameRange, Code, Range, "") {
+  return replacementToEdit(Code, arg).range == Range;
+}
+
 TEST(RenameTest, SingleFile) {
   struct Test {
 const char* Before;
@@ -87,6 +91,67 @@
   }
 }
 
+TEST(RenameTest, Renameable) {
+  // Test cases where the symbol is declared in header.
+  const char *Headers[] = {
+  R"cpp(// allow -- function-local
+void f(int [[Lo^cal]]) {
+  [[Local]] = 2;
+}
+  )cpp",
+
+  R"cpp(// allow -- symbol is indexable and has no refs in index.
+void [[On^lyInThisFile]]();
+  )cpp",
+
+  R"cpp(// disallow -- symbol is indexable and has other refs in index.
+void f() {
+  Out^side s;
+}
+  )cpp",
+
+  R"cpp(// disallow -- symbol is not indexable.
+namespace {
+class Unin^dexable {};
+}
+  )cpp",
+  };
+  const char *CommonHeader = "class Outside {};";
+  TestTU OtherFile = TestTU::withCode("Outside s;");
+  OtherFile.HeaderCode = CommonHeader;
+  OtherFile.Filename = "other.cc";
+  // The index has a "Outside" reference.
+  auto OtherFileIndex = OtherFile.index();
+
+  for (const char *Header : Headers) {
+Annotations T(Header);
+// We open the .h file as the main file.
+TestTU TU = TestTU::withCode(T.code());
+TU.Filename = "test.h";
+TU.HeaderCode = CommonHeader;
+TU.ExtraArgs.push_back("-xc++");
+auto AST = TU.build();
+
+auto Results = renameWithinFile(AST, testPath(TU.Filename), T.point(),
+"dummyNewName", OtherFileIndex.get());
+bool WantRename = true;
+if (T.ranges().empty())
+  WantRename = false;
+if (!WantRename) {
+  EXPECT_FALSE(Results) << "expected renameWithinFile returned an error: "
+<< T.code();
+  llvm::consumeError(Results.takeError());
+} else {
+  EXPECT_TRUE(bool(Results)) << "renameWithinFile returned an error: "
+ << llvm::toString(Results.takeError());
+  std::vector> Expected;
+  for (const auto &R : T.ranges())
+Expected.push_back(RenameRange(TU.Code, R));
+  EXPECT_THAT(*Results, UnorderedElementsAreArray(Expected));
+}
+  }
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/Rename.h
===
--- clang-tools-extra/clangd/refactor/Rename.h
+++ clang-tools-extra/clangd/refactor/Rename.h
@@ -18,10 +18,10 @@
 
 /// Renames all occurrences of the symbol at \p Pos to \p NewName.
 /// Occurrences outside the current file are not modified.
-llvm::Expected renameWithinFile(ParsedAST &AST,
-   llvm::StringRef File,
-   Position Pos,
-   llvm::StringRef NewName);
+/// Only support renaming symbols not being used outside the file.
+llvm::Expected
+renameWithinFile(ParsedAST &AST, llvm::StringRef File, Position Pos,
+ 

[PATCH] D63642: [analyzer] Add a debug analyzer config to place an event for each tracked condition

2019-06-21 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus created this revision.
Szelethus added reviewers: NoQ, baloghadamsoftware, xazax.hun, Charusso, 
rnkovacs, dcoughlin.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, a.sidorin, szepet, whisperity.

Exactly what it says on the tin!

I expect this to be especially valuable on production code where control 
dependencies aren't obvious.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63642

Files:
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/track-control-dependency-conditions.cpp

Index: clang/test/Analysis/track-control-dependency-conditions.cpp
===
--- clang/test/Analysis/track-control-dependency-conditions.cpp
+++ clang/test/Analysis/track-control-dependency-conditions.cpp
@@ -2,7 +2,23 @@
 // RUN:   -analyzer-config track-conditions=true \
 // RUN:   -analyzer-output=text \
 // RUN:   -analyzer-checker=core
+
+// RUN: not %clang_analyze_cc1 -verify %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-config track-conditions-debug=true \
+// RUN:   2>&1 | FileCheck %s -check-prefix=CHECK-INVALID-DEBUG
+
+// CHECK-INVALID-DEBUG: (frontend): invalid input for analyzer-config option
+// CHECK-INVALID-DEBUG-SAME:'track-conditions-debug', that expects
+// CHECK-INVALID-DEBUG-SAME:'track-conditions' to also be enabled
 //
+// RUN: %clang_analyze_cc1 %s -verify \
+// RUN:   -DTRACKING_CONDITIONS -DTRACKING_CONDITIONS_DEBUG \
+// RUN:   -analyzer-config track-conditions=true \
+// RUN:   -analyzer-config track-conditions-debug=true \
+// RUN:   -analyzer-output=text \
+// RUN:   -analyzer-checker=core
+
 // RUN: %clang_analyze_cc1 %s -verify \
 // RUN:   -analyzer-output=text \
 // RUN:   -analyzer-checker=core
@@ -35,6 +51,9 @@
 
   if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
 // expected-note@-1{{Taking true branch}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+// expected-note@-3{{Tracking condition 'flag'}}
+#endif // TRACKING_CONDITIONS_DEBUG
 *x = 5; // expected-warning{{Dereference of null pointer}}
 // expected-note@-1{{Dereference of null pointer}}
 }
@@ -70,6 +89,9 @@
 
   if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
 // expected-note@-1{{Taking true branch}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+// expected-note@-3{{Tracking condition 'flag'}}
+#endif // TRACKING_CONDITIONS_DEBUG
 *x = 5; // expected-warning{{Dereference of null pointer}}
 // expected-note@-1{{Dereference of null pointer}}
 }
@@ -102,8 +124,14 @@
 
   if (bar) // expected-note   {{Assuming 'bar' is not equal to 0}}
// expected-note@-1{{Taking true branch}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+   // expected-note@-3{{Tracking condition 'bar'}}
+#endif // TRACKING_CONDITIONS_DEBUG
 if (flag) // expected-note   {{Assuming 'flag' is not equal to 0}}
   // expected-note@-1{{Taking true branch}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+  // expected-note@-3{{Tracking condition 'flag'}}
+#endif // TRACKING_CONDITIONS_DEBUG
   *x = 5; // expected-warning{{Dereference of null pointer}}
   // expected-note@-1{{Dereference of null pointer}}
 }
@@ -129,9 +157,13 @@
 // expected-note@-2{{Calling 'foo'}}
 // expected-note@-3{{Returning from 'foo'}}
 // expected-note@-4{{'flag' initialized here}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+// expected-note@-6{{Tracking condition 'flag'}}
+#endif // TRACKING_CONDITIONS_DEBUG
 #endif // TRACKING_CONDITIONS
-// expected-note@-6{{Assuming 'flag' is not equal to 0}}
-// expected-note@-7{{Taking true branch}}
+// expected-note@-9{{Assuming 'flag' is not equal to 0}}
+// expected-note@-10{{Taking true branch}}
+
 *x = 5; // expected-warning{{Dereference of null pointer}}
 // expected-note@-1{{Dereference of null pointer}}
 }
@@ -154,9 +186,12 @@
 #ifdef TRACKING_CONDITIONS
 // expected-note@-2 {{Calling 'ConvertsToBool::operator bool'}}
 // expected-note@-3{{Returning from 'ConvertsToBool::operator bool'}}
+#ifdef TRACKING_CONDITIONS_DEBUG
+// expected-note@-5{{Tracking condition 'ConvertsToBool()'}}
+#endif // TRACKING_CONDITIONS_DEBUG
 #endif // TRACKING_CONDITIONS
-// expected-note@-5{{Assuming the condition is true}}
-// expected-note@-6{{Taking true branch}}
+// expected-note@-8{{Assuming the condition is true}}
+// expected-note@-9{{Taking true branch}}
 *x = 5; // expected-warning{{Dereference of null pointer}}
 // expected-note@-1{{Dereference of null pointer}}
 }
@@ -174,6 +209,9 @@
   int *x = 0; // expected-note{{'x' initialized to a null pointer value}}
   if (flag) // expected-note{{As

r364032 - [Sema] Fix diagnostic for addr spaces in reference binding

2019-06-21 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Fri Jun 21 04:36:15 2019
New Revision: 364032

URL: http://llvm.org/viewvc/llvm-project?rev=364032&view=rev
Log:
[Sema] Fix diagnostic for addr spaces in reference binding

Extend reference binding behavior to account for address spaces.

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


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/SemaOpenCLCXX/address-space-references.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=364032&r1=364031&r2=364032&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jun 21 04:36:15 
2019
@@ -1852,7 +1852,7 @@ def err_lvalue_reference_bind_to_unrelat
   "cannot bind to a value of unrelated type}1,2">;
 def err_reference_bind_drops_quals : Error<
   "binding reference %diff{of type $ to value of type $|to value}0,1 "
-  "drops %2 qualifier%plural{1:|2:|4:|:s}3">;
+  "%select{drops %3 qualifier%plural{1:|2:|4:|:s}4|changes address space}2">;
 def err_reference_bind_failed : Error<
   "reference %diff{to %select{type|incomplete type}1 $ could not bind to an "
   "%select{rvalue|lvalue}2 of type $|could not bind to %select{rvalue|lvalue}2 
of "

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=364032&r1=364031&r2=364032&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Jun 21 04:36:15 2019
@@ -4631,7 +4631,10 @@ static void TryReferenceInitializationCo
   // - Otherwise, the reference shall be an lvalue reference to a
   //   non-volatile const type (i.e., cv1 shall be const), or the reference
   //   shall be an rvalue reference.
-  if (isLValueRef && !(T1Quals.hasConst() && !T1Quals.hasVolatile())) {
+  //   For address spaces, we interpret this to mean that an addr space
+  //   of a reference "cv1 T1" is a superset of addr space of "cv2 T2".
+  if (isLValueRef && !(T1Quals.hasConst() && !T1Quals.hasVolatile() &&
+   T1Quals.isAddressSpaceSupersetOf(T2Quals))) {
 if (S.Context.getCanonicalType(T2) == S.Context.OverloadTy)
   Sequence.SetFailed(InitializationSequence::FK_AddressOfOverloadFailed);
 else if (ConvOvlResult && !Sequence.getFailedCandidateSet().empty())
@@ -4640,7 +4643,10 @@ static void TryReferenceInitializationCo
   ConvOvlResult);
 else if (!InitCategory.isLValue())
   Sequence.SetFailed(
-  
InitializationSequence::FK_NonConstLValueReferenceBindingToTemporary);
+  T1Quals.isAddressSpaceSupersetOf(T2Quals)
+  ? InitializationSequence::
+FK_NonConstLValueReferenceBindingToTemporary
+  : InitializationSequence::FK_ReferenceInitDropsQualifiers);
 else {
   InitializationSequence::FailureKind FK;
   switch (RefRelationship) {
@@ -8521,12 +8527,16 @@ bool InitializationSequence::Diagnose(Se
 Qualifiers DroppedQualifiers =
 SourceType.getQualifiers() - NonRefType.getQualifiers();
 
-S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
-  << NonRefType
-  << SourceType
-  << Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
-  << DroppedQualifiers.getCVRQualifiers()
-  << Args[0]->getSourceRange();
+if (!NonRefType.getQualifiers().isAddressSpaceSupersetOf(
+SourceType.getQualifiers()))
+  S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
+  << NonRefType << SourceType << 1 /*addr space*/
+  << Args[0]->getSourceRange();
+else
+  S.Diag(Kind.getLocation(), diag::err_reference_bind_drops_quals)
+  << NonRefType << SourceType << 0 /*cv quals*/
+  << Qualifiers::fromCVRMask(DroppedQualifiers.getCVRQualifiers())
+  << DroppedQualifiers.getCVRQualifiers() << Args[0]->getSourceRange();
 break;
   }
 

Modified: cfe/trunk/test/SemaOpenCLCXX/address-space-references.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCLCXX/address-space-references.cl?rev=364032&r1=364031&r2=364032&view=diff
==
--- cfe/trunk/test/SemaOpenCLCXX/address-space-references.cl (original)
+++ cfe/trunk/test/SemaOpenCLCXX/address-space-references.cl Fri Jun 21 
04:36:15 2019
@@ -3,3 +3,13 @@
 __global const int& f(__global float &ref) {
   return ref; // expected-error{{reference of type 'const __global int &' 
cannot bind to a temporary object because of address space mismatch}}
 }
+
+int bar(const __global unsigned int &i); // expect

r364033 - Fix test/AST/ast-dump-records-json.cpp after ConstantExpr change in D63376

2019-06-21 Thread Fangrui Song via cfe-commits
Author: maskray
Date: Fri Jun 21 04:39:41 2019
New Revision: 364033

URL: http://llvm.org/viewvc/llvm-project?rev=364033&view=rev
Log:
Fix test/AST/ast-dump-records-json.cpp after ConstantExpr change in D63376

Modified:
cfe/trunk/test/AST/ast-dump-records-json.cpp

Modified: cfe/trunk/test/AST/ast-dump-records-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-records-json.cpp?rev=364033&r1=364032&r2=364033&view=diff
==
--- cfe/trunk/test/AST/ast-dump-records-json.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-records-json.cpp Fri Jun 21 04:39:41 2019
@@ -344,6 +344,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "12",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 
@@ -414,6 +415,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "0",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 
@@ -485,6 +487,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "10",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 
@@ -1569,6 +1572,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "12",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 
@@ -1639,6 +1643,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "0",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 
@@ -1710,6 +1715,7 @@ struct Derived6 : virtual public Bases..
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }, 
 // CHECK-NEXT:  "valueCategory": "rvalue", 
+// CHECK-NEXT:  "value": "10",
 // CHECK-NEXT:  "inner": [
 // CHECK-NEXT:   {
 // CHECK-NEXT:"id": "0x{{.*}}", 


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


[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 205974.
ilya-biryukov added a comment.

- A few more renames and docs
- Cleanups and comments
- Reformat the code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61637

Files:
  clang/include/clang/Tooling/Syntax/BuildTree.h
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/CMakeLists.txt
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Tree.cpp
  clang/unittests/Tooling/Syntax/CMakeLists.txt
  clang/unittests/Tooling/Syntax/TreeTest.cpp
  llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
@@ -8,6 +8,10 @@
 "//llvm/lib/Support",
   ]
   sources = [
+"Arena.cpp",
+"BuildFromAST.cpp",
+"Cascade.cpp",
+"Nodes.cpp",
 "Tokens.cpp",
   ]
 }
Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- /dev/null
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -0,0 +1,160 @@
+//===- TreeTest.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 "clang/Tooling/Syntax/Tree.h"
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/Decl.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/FrontendAction.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "clang/Tooling/Syntax/BuildTree.h"
+#include "clang/Tooling/Syntax/Nodes.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+
+namespace {
+class SyntaxTreeTest : public ::testing::Test {
+protected:
+  // Build a syntax tree for the code.
+  syntax::TranslationUnitDeclaration *buildTree(llvm::StringRef Code) {
+// FIXME: this code is almost the identical to the one in TokensTest. Share
+//it.
+class BuildSyntaxTree : public ASTConsumer {
+public:
+  BuildSyntaxTree(syntax::TranslationUnitDeclaration *&Root,
+  std::unique_ptr &Arena,
+  std::unique_ptr Tokens)
+  : Root(Root), Arena(Arena), Tokens(std::move(Tokens)) {
+assert(this->Tokens);
+  }
+
+  void HandleTranslationUnit(ASTContext &Ctx) override {
+Arena = llvm::make_unique(Ctx.getSourceManager(),
+ Ctx.getLangOpts(),
+ std::move(*Tokens).consume());
+Tokens = nullptr; // make sure we fail if this gets called twice.
+Root = syntax::buildSyntaxTree(*Arena, *Ctx.getTranslationUnitDecl());
+  }
+
+private:
+  syntax::TranslationUnitDeclaration *&Root;
+  std::unique_ptr &Arena;
+  std::unique_ptr Tokens;
+};
+
+class BuildSyntaxTreeAction : public ASTFrontendAction {
+public:
+  BuildSyntaxTreeAction(syntax::TranslationUnitDeclaration *&Root,
+std::unique_ptr &Arena)
+  : Root(Root), Arena(Arena) {}
+
+  std::unique_ptr
+  CreateASTConsumer(CompilerInstance &CI, StringRef InFile) override {
+// We start recording the tokens, ast consumer will take on the result.
+auto Tokens =
+llvm::make_unique(CI.getPreprocessor());
+return llvm::make_unique(Root, Arena,
+  std::move(Tokens));
+  }
+
+private:
+  syntax::TranslationUnitDeclaration *&Root;
+  std::unique_ptr &Arena;
+};
+
+constexpr const char *FileName = "./input.cpp";
+FS->addFile(FileName, time_t(), llvm::MemoryBuffer::getMemBufferCopy(""));
+// Prepare to run a compiler.
+std::vector Args = {"tok-test", "-std=c++03", "-fsyntax-only",
+  FileName};
+auto CI = createInvocationFromCommandLine(Args, Diags, FS);
+assert(CI);
+CI->getFrontendOpts().DisableFree = false;
+CI->getPreprocessorOpts().addRemappedFile(
+FileName, llvm::MemoryBuffer::getMemBufferCopy(Code).release());
+CompilerInstance Compiler;
+Compiler.setInvocation(std::move(CI));
+if (!Diags->getClient())
+  Diags->setClient(new IgnoringDiagConsumer);
+Compiler.setDiagnostics(Diags.get());
+Compiler.setFileManager(FileMgr.get());
+Compile

r364018 - [RISC-V] Add -msave-restore and -mno-save-restore to clang driver

2019-06-21 Thread Sam Elliott via cfe-commits
Author: lenary
Date: Fri Jun 21 03:03:31 2019
New Revision: 364018

URL: http://llvm.org/viewvc/llvm-project?rev=364018&view=rev
Log:
[RISC-V] Add -msave-restore and -mno-save-restore to clang driver

Summary:
The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore`
to control whether libcalls are used for saving and restoring the stack within
prologues and epilogues.

Clang currently errors if someone passes -msave-restore or -mno-save-restore.
This means that people need to change build configurations to use clang. This
patch adds these flags, so that clang invocations can now match gcc.

As the RISC-V backend does not currently have a `save-restore` target feature,
we emit a warning if someone requests `-msave-restore`. LLVM does not error if
we pass the (unimplemented) target features `+save-restore` or `-save-restore`.

Reviewers: asb, luismarques

Reviewed By: asb

Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, 
shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, 
the_o, rkruppe, PkmX, jocewei, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
cfe/trunk/test/Driver/riscv-features.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Fri Jun 21 03:03:31 2019
@@ -2130,6 +2130,10 @@ def mrelax : Flag<["-"], "mrelax">, Grou
   HelpText<"Enable linker relaxation">;
 def mno_relax : Flag<["-"], "mno-relax">, Group,
   HelpText<"Disable linker relaxation">;
+def msave_restore : Flag<["-"], "msave-restore">, 
Group,
+  HelpText<"Enable using library calls for save and restore">;
+def mno_save_restore : Flag<["-"], "mno-save-restore">, 
Group,
+  HelpText<"Disable using library calls for save and restore">;
 
 def munaligned_access : Flag<["-"], "munaligned-access">, 
Group,
   HelpText<"Allow memory accesses to be unaligned (AArch32/AArch64 only)">;

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp Fri Jun 21 03:03:31 2019
@@ -358,6 +358,16 @@ void riscv::getRISCVTargetFeatures(const
   else
 Features.push_back("-relax");
 
+  // -mno-save-restore is default, unless -msave-restore is specified.
+  if (Args.hasFlag(options::OPT_msave_restore, options::OPT_mno_save_restore, 
false)) {
+Features.push_back("+save-restore");
+// ... but we don't yet support +save-restore, so issue a warning.
+D.Diag(diag::warn_drv_clang_unsupported)
+  << Args.getLastArg(options::OPT_msave_restore)->getAsString(Args);
+  } else {
+Features.push_back("-save-restore");
+  }
+
   // Now add any that the user explicitly requested on the command line,
   // which may override the defaults.
   handleTargetFeaturesGroup(Args, Features, 
options::OPT_m_riscv_Features_Group);

Modified: cfe/trunk/test/Driver/riscv-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv-features.c?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/test/Driver/riscv-features.c (original)
+++ cfe/trunk/test/Driver/riscv-features.c Fri Jun 21 03:03:31 2019
@@ -3,11 +3,23 @@
 
 // CHECK: fno-signed-char
 
+// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
+
 // RUN: %clang -target riscv32-unknown-elf -### %s -mrelax 2>&1 | FileCheck %s 
-check-prefix=RELAX
 // RUN: %clang -target riscv32-unknown-elf -### %s -mno-relax 2>&1 | FileCheck 
%s -check-prefix=NO-RELAX
-// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
 
 // RELAX: "-target-feature" "+relax"
 // NO-RELAX: "-target-feature" "-relax"
 // DEFAULT: "-target-feature" "+relax"
 // DEFAULT-NOT: "-target-feature" "-relax"
+
+// RUN: %clang -target riscv32-unknown-elf -### %s -msave-restore 2>&1 | 
FileCheck %s -check-prefix=SAVE-RESTORE
+// RUN: %clang -target riscv32-unknown-elf -### %s -mno-save-restore 2>&1 | 
FileCheck %s -check-prefix=NO-SAVE-RESTORE
+
+// SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
+// DEFAULT-NOT: warning: the clang compiler does not support
+
+// SAVE-RESTORE: "-target-feature" "+save-restore"
+// NO-SAVE-RESTORE: "-target-feature" "-save-restore"
+// DEFAULT: "-target-feature" "-save-restore"
+//

[PATCH] D63134: [clang] improving diagnotics for invalid constexpr defaulted special membres

2019-06-21 Thread Tyker via Phabricator via cfe-commits
Tyker added a comment.

ping @rsmith


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

https://reviews.llvm.org/D63134



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


[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov marked 13 inline comments as done.
ilya-biryukov added a comment.

This is ready for another round now.




Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:37
+  /// and \p Last are added as children of the new node.
+  void learnNode(SourceLocation Fist, SourceLocation Last,
+ syntax::TreeNode *New);

sammccall wrote:
> sammccall wrote:
> > maybe formNode, formToken, formRoot()?
> if syntax nodes strictly nest and we form left-to-right and bottom up, then 
> why are there ever pending nodes that aren't in the range? Is it because we 
> don't aggregate them as early as possible?
> 
> (edit: after offline discussion, there are precise invariants here that could 
> be documented and asserted)
Sorry, missed this comment and went with `expectToken()` and `expectNode()`, 
root is now built on `consume()`. Can change to `form*`, not a big deal.

I still need to write good docs about the invariants here, so leaving this open.




Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:48
+  /// Consume the root node.
+  syntax::TranslationUnit *root() && {
+assert(Root);

ilya-biryukov wrote:
> sammccall wrote:
> > any particular reason learnRoot() and root() are different functions?
> > 
> > If learnRoot() returned TranslationUnit*, then we avoid the need for the 
> > caller to know about the dependency, it would track the state itself.
> `learnRoot` is called inside ast visitor when processing 
> `TranslationUnitDecl` and `root()` is used to consume the result.
> 
> I guess we could just delay `learnRoot` until `consume()` is called, 
> shouldn't be a big deal. I'll do this in the next iteration.
`consume()` now builds the root node.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:92
+  bool TraverseCompoundStmt(CompoundStmt *S) {
+Builder.learnTokenNode(S->getLBracLoc(), tok::l_brace);
+Builder.learnTokenNode(S->getRBracLoc(), tok::r_brace);

sammccall wrote:
> So explicitly claiming the primitive tokens, but implicitly claiming the 
> subtrees, seems like a weird mix.
> Having both explicit might be nicer:
>  - It seems somewhat likely we want to record/tag their semantics (maybe in 
> the child itself, or even the low bits of its pointer?), rather than having 
> accessors scan around looking for something likely.
>  - currently when expected subtrees fail to parse, their tokens get 
> (implicitly) wrapped up in Recovery nodes. They're good targets for heuristic 
> parsing, but this probably means we should record what an unexplained range 
> of tokens is supposed to be for.
> 
> Thinking of something like:
> ```
> builder.expectToken(l_brace, S->getLBracLoc());
> builder.expectTree(Statement, S->getBody());
> builder.expectToken(r_brace, S->getRBracLoc());
> ```
> where the builder would react to non-null AST nodes by mapping the associated 
> syntax node, and null AST nodes by trying to heuristically parse the tokens 
> in between LBracLoc and RBracLoc.
> 
> But lots of unanswered questions here: body is a list of statements, how does 
> that work? What if LBracLoc or RBracLoc is missing? etc.
That's exactly the design we have one, with a limitation that `expect*` have to 
be called in left-to-right and bottom-up manner. Also, you can only build a 
tree that ends at the tokens that were consumed.

This is actually a reasonable interface to build a tree from an actual parser, 
but might feel weird for a ast-to-syntax transformation. I need to figure out a 
way to write good docs about it, but there's a separate comment for that. 
Marking this as done (although the questions you mentioned at the end are still 
there)



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:135
+
+void syntax::TreeBuilder::learnNodeImpl(const syntax::Token *Begin,
+const syntax::Token *End,

sammccall wrote:
> this function needs some high-level implementation comments
Done. Also renamed it to `consumeNode`. 

The docs are very short, though, might need a revamp for clarity.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:164
+  };
+  for (auto It = FirstChild; It != NodesInProgress.end(); ++It) {
+// Add non-coverred ranges as recovery nodes.

sammccall wrote:
> why can It not point to a node that spans/is past End?
> 
> (edit after offline discussion: it's an important invariant that we're always 
> consuming a suffix of the pending nodes)
This is now spelled out in the documentation for `foldChildren`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61637



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


[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov marked 4 inline comments as done.
ilya-biryukov added a comment.

Although there are still rough edges, I believe the storage model is agreed 
upon and we can hopefully address the rest in the follow-ups.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61637



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


[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-06-21 Thread Anton Afanasyev via Phabricator via cfe-commits
anton-afanasyev updated this revision to Diff 205978.
anton-afanasyev added a comment.

Hi @lebedev.ri, I've turned back to the solution with one `TimeTraceScope` for 
"Frontend" inside `BackendConsumer::HandleTranslationUnit()`, since it looks 
more robust. This admits several (two for now) "Frontend" sections, but I see 
no problem with this. Other solutions have to rely on `BackendConsumer` and 
`ASTConsumer` calling correct relations, which are not guaranteed (though it is 
looking correct for now).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325

Files:
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/Driver/check-time-trace-sections.cpp
  clang/test/Driver/check-time-trace-sections.py
  llvm/lib/Support/TimeProfiler.cpp


Index: llvm/lib/Support/TimeProfiler.cpp
===
--- llvm/lib/Support/TimeProfiler.cpp
+++ llvm/lib/Support/TimeProfiler.cpp
@@ -65,7 +65,7 @@
 E.Duration = steady_clock::now() - E.Start;
 
 // Only include sections longer than TimeTraceGranularity msec.
-if (duration_cast(E.Duration).count() > TimeTraceGranularity)
+if (duration_cast(E.Duration).count() >= 
TimeTraceGranularity)
   Entries.emplace_back(E);
 
 // Track total time taken by each "name", but only the topmost levels of
Index: clang/test/Driver/check-time-trace-sections.py
===
--- /dev/null
+++ clang/test/Driver/check-time-trace-sections.py
@@ -0,0 +1,25 @@
+#!/usr/bin/env python
+
+import json, sys
+
+def is_inside(range1, range2):
+a = range1["ts"]; b = a + range1["dur"]
+c = range2["ts"]; d = c + range2["dur"]
+return (a >= c and a <= d) and (b >= c and b <= d)
+
+def is_before(range1, range2):
+b = range1["ts"] + range1["dur"]; c = range2["ts"]
+return b <= c
+
+events = json.loads(sys.stdin.read())["traceEvents"]
+codegens = filter(lambda x: x["name"] == "CodeGen Function", events)
+frontends = filter(lambda x: x["name"] == "Frontend", events)
+backends = filter(lambda x: x["name"] == "Backend", events)
+
+if not all([any([is_inside(codegen, frontend) for frontend in frontends])
+for codegen in codegens]):
+sys.exit("Not all CodeGen sections are inside any Frontend section!")
+
+if not all([all([is_before(frontend, backend) for frontend in frontends])
+for backend in backends]):
+sys.exit("Not all Frontend section are before all Backend sections!")
Index: clang/test/Driver/check-time-trace-sections.cpp
===
--- /dev/null
+++ clang/test/Driver/check-time-trace-sections.cpp
@@ -0,0 +1,7 @@
+// REQUIRES: shell
+// RUN: %clangxx -S -ftime-trace -mllvm --time-trace-granularity=0 -o 
%T/check-time-trace-sections %s
+// RUN: cat %T/check-time-trace-sections.json | %python 
%S/check-time-trace-sections.py
+
+template 
+void foo(T) {}
+void bar() { foo(0); }
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -37,6 +37,7 @@
 #include "llvm/Pass.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/SourceMgr.h"
+#include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
 #include "llvm/Support/ToolOutputFile.h"
 #include "llvm/Support/YAMLTraits.h"
@@ -228,6 +229,7 @@
 
 void HandleTranslationUnit(ASTContext &C) override {
   {
+llvm::TimeTraceScope TimeScope("Frontend", StringRef(""));
 PrettyStackTraceString CrashInfo("Per-file LLVM IR generation");
 if (FrontendTimesIsEnabled) {
   LLVMIRGenerationRefCount += 1;


Index: llvm/lib/Support/TimeProfiler.cpp
===
--- llvm/lib/Support/TimeProfiler.cpp
+++ llvm/lib/Support/TimeProfiler.cpp
@@ -65,7 +65,7 @@
 E.Duration = steady_clock::now() - E.Start;
 
 // Only include sections longer than TimeTraceGranularity msec.
-if (duration_cast(E.Duration).count() > TimeTraceGranularity)
+if (duration_cast(E.Duration).count() >= TimeTraceGranularity)
   Entries.emplace_back(E);
 
 // Track total time taken by each "name", but only the topmost levels of
Index: clang/test/Driver/check-time-trace-sections.py
===
--- /dev/null
+++ clang/test/Driver/check-time-trace-sections.py
@@ -0,0 +1,25 @@
+#!/usr/bin/env python
+
+import json, sys
+
+def is_inside(range1, range2):
+a = range1["ts"]; b = a + range1["dur"]
+c = range2["ts"]; d = c + range2["dur"]
+return (a >= c and a <= d) and (b >= c and b <= d)
+
+def is_before(range1, range2):
+b = range1["ts"] + range1["dur"]; c = range2["ts"]
+return b <= c
+
+events = json.loads(sys.stdin.read())["traceE

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-06-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri resigned from this revision.
lebedev.ri added a comment.

I'm sorry, i should have noticed that earlier,  the handling of `"Frontend"` 
section
still looks way too intrusive to me, it breaks abstractions.

The only simple solution i see is to

1. Insert a timer for `PrettyStackTraceString CrashInfo("Per-file LLVM IR 
generation");` section
2. Don't stop `"Frontend"` timer within `HandleTranslationUnit` function
3. Naturally, change `"Frontend"` timer name to something else (`"Clang 
invocation"`?)

This is the trivial solution that wouldn't be intrusive, but would not get you 
the `"frontend timer"`
in the sense that it doesn't include the middle-end pipe, backend stuff, etc, 
only the

The alternative raises from the question - why does `CodeGen/CodeGenAction.cpp` 
do all that stuff?
I.e. maybe somehow chop that class into 2 or 3 smaller classes - actual ir 
codegen,
middle-end optimization pipeline + opt-remarks handling, etc.
I don't know if that is possible, or viable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325



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


[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-06-21 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Hm, i started writing previous comment before you posted your last comment, so 
i didn't see the last update.
This looks less intrusive, yes, but two observations:

1. You now have two `"Frontend"` sections - first one being for lexing time
2. That lexing section is not within the `"Frontend"` section, even though it 
is for sure part of frontend of the compiler.

Like i said, i'm not sure what the right solution here is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325



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


[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-06-21 Thread Anton Afanasyev via Phabricator via cfe-commits
anton-afanasyev added a comment.

In D63325#1553458 , @lebedev.ri wrote:

> Hm, i started writing previous comment before you posted your last comment, 
> so i didn't see the last update.
>  This looks less intrusive, yes, but two observations:
>
> 1. You now have two `"Frontend"` sections - first one being for lexing time
> 2. That lexing section is not within the `"Frontend"` section, even though it 
> is for sure part of frontend of the compiler. Like i said, i'm not sure what 
> the right solution here is.


Why lexing section is not within `"Frontend"` section. Your p.1 claims is is 
within. For now, first `"Frontend"` section includes lexing as well as frontend 
codegen (called from `Consumer->HandleTopLevelDecl()`. Second `"Frontend"` 
section includes only frontend codegen through `HandleTranslationUnit()` 
calling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325



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


[clang-tools-extra] r364044 - [clangd] Add include-mapping for C symbols.

2019-06-21 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Fri Jun 21 06:32:18 2019
New Revision: 364044

URL: http://llvm.org/viewvc/llvm-project?rev=364044&view=rev
Log:
[clangd] Add include-mapping for C symbols.

Summary:
This resolves the issue of introducing c++-style includes for C files.

- refactor the gen_std.py, make it reusable for parsing C symbols.
- add a language mode to the mapping method to use different mapping for
  C and C++ files.

Reviewers: kadircet

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

Tags: #clang

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

Added:
clang-tools-extra/trunk/clangd/CSymbolMap.inc
clang-tools-extra/trunk/clangd/include-mapping/cppreference_parser.py
Modified:
clang-tools-extra/trunk/clangd/ClangdUnit.cpp
clang-tools-extra/trunk/clangd/StdSymbolMap.inc
clang-tools-extra/trunk/clangd/include-mapping/gen_std.py
clang-tools-extra/trunk/clangd/include-mapping/test.py
clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp
clang-tools-extra/trunk/clangd/index/CanonicalIncludes.h
clang-tools-extra/trunk/clangd/index/IndexAction.cpp
clang-tools-extra/trunk/clangd/unittests/CanonicalIncludesTests.cpp
clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp

Added: clang-tools-extra/trunk/clangd/CSymbolMap.inc
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CSymbolMap.inc?rev=364044&view=auto
==
--- clang-tools-extra/trunk/clangd/CSymbolMap.inc (added)
+++ clang-tools-extra/trunk/clangd/CSymbolMap.inc Fri Jun 21 06:32:18 2019
@@ -0,0 +1,944 @@
+//===-- gen_std.py generated file ---*- C++ 
-*-===//
+//
+// Used to build a lookup table (qualified names => include headers) for C
+// Standard Library symbols.
+//
+// Automatically generated file, DO NOT EDIT!
+//
+// Generated from cppreference offline HTML book (modified on 2018-10-28).
+//===--===//
+
+SYMBOL(ATOMIC_BOOL_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR16_T_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR32_T_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR_LOCK_FREE, None, )
+SYMBOL(ATOMIC_FLAG_INIT, None, )
+SYMBOL(ATOMIC_INT_LOCK_FREE, None, )
+SYMBOL(ATOMIC_LLONG_LOCK_FREE, None, )
+SYMBOL(ATOMIC_LONG_LOGK_FREE, None, )
+SYMBOL(ATOMIC_POINTER_LOCK_FREE, None, )
+SYMBOL(ATOMIC_SHORT_LOCK_FREE, None, )
+SYMBOL(ATOMIC_VAR_INIT, None, )
+SYMBOL(ATOMIC_WCHAR_T_LOCK_FREE, None, )
+SYMBOL(BUFSIZ, None, )
+SYMBOL(CHAR_BIT, None, )
+SYMBOL(CHAR_MAX, None, )
+SYMBOL(CHAR_MIN, None, )
+SYMBOL(CLOCKS_PER_SEC, None, )
+SYMBOL(CMPLX, None, )
+SYMBOL(CMPLXF, None, )
+SYMBOL(CMPLXL, None, )
+SYMBOL(DBL_DECIMAL_DIG, None, )
+SYMBOL(DBL_DIG, None, )
+SYMBOL(DBL_EPSILON, None, )
+SYMBOL(DBL_HAS_SUBNORM, None, )
+SYMBOL(DBL_MANT_DIG, None, )
+SYMBOL(DBL_MAX, None, )
+SYMBOL(DBL_MAX_10_EXP, None, )
+SYMBOL(DBL_MAX_EXP, None, )
+SYMBOL(DBL_MIN, None, )
+SYMBOL(DBL_MIN_10_EXP, None, )
+SYMBOL(DBL_MIN_EXP, None, )
+SYMBOL(DBL_TRUE_MIN, None, )
+SYMBOL(DECIMAL_DIG, None, )
+SYMBOL(EDOM, None, )
+SYMBOL(EILSEQ, None, )
+SYMBOL(EOF, None, )
+SYMBOL(ERANGE, None, )
+SYMBOL(EXIT_FAILURE, None, )
+SYMBOL(EXIT_SUCCESS, None, )
+SYMBOL(FE_ALL_EXCEPT, None, )
+SYMBOL(FE_DFL_ENV, None, )
+SYMBOL(FE_DIVBYZERO, None, )
+SYMBOL(FE_DOWNWARD, None, )
+SYMBOL(FE_INEXACT, None, )
+SYMBOL(FE_INVALID, None, )
+SYMBOL(FE_OVERFLOW, None, )
+SYMBOL(FE_TONEAREST, None, )
+SYMBOL(FE_TOWARDZERO, None, )
+SYMBOL(FE_UNDERFLOW, None, )
+SYMBOL(FE_UPWARD, None, )
+SYMBOL(FILE, None, )
+SYMBOL(FILENAME_MAX, None, )
+SYMBOL(FLT_DECIMAL_DIG, None, )
+SYMBOL(FLT_DIG, None, )
+SYMBOL(FLT_EPSILON, None, )
+SYMBOL(FLT_EVAL_METHOD, None, )
+SYMBOL(FLT_HAS_SUBNORM, None, )
+SYMBOL(FLT_MANT_DIG, None, )
+SYMBOL(FLT_MAX, None, )
+SYMBOL(FLT_MAX_10_EXP, None, )
+SYMBOL(FLT_MAX_EXP, None, )
+SYMBOL(FLT_MIN, None, )
+SYMBOL(FLT_MIN_10_EXP, None, )
+SYMBOL(FLT_MIN_EXP, None, )
+SYMBOL(FLT_RADIX, None, )
+SYMBOL(FLT_ROUNDS, None, )
+SYMBOL(FLT_TRUE_MIN, None, )
+SYMBOL(FOPEN_MAX, None, )
+SYMBOL(FP_INFINITE, None, )
+SYMBOL(FP_NAN, None, )
+SYMBOL(FP_NORNAL, None, )
+SYMBOL(FP_SUBNORMAL, None, )
+SYMBOL(FP_ZERO, None, )
+SYMBOL(HUGE_VAL, None, )
+SYMBOL(HUGE_VALF, None, )
+SYMBOL(HUGE_VALL, None, )
+SYMBOL(I, None, )
+SYMBOL(INFINITY, None, )
+SYMBOL(INT16_MAX, None, )
+SYMBOL(INT16_MIN, None, )
+SYMBOL(INT32_MAX, None, )
+SYMBOL(INT32_MIN, None, )
+SYMBOL(INT64_MAX, None, )
+SYMBOL(INT64_MIN, None, )
+SYMBOL(INT8_MAX, None, )
+SYMBOL(INT8_MIN, None, )
+SYMBOL(INTMAX_MAX, None, )
+SYMBOL(INTMAX_MIN, None, )
+SYMBOL(INTPTR_MAX, None, )
+SYMBOL(INTPTR_MIN, None, )
+SYMBOL(INT_FAST16_MAX, None, )
+SYMBOL(INT_FAST16_MIN, None, )
+SYMBOL(INT_FAST32_MAX, None, )
+SYMBOL(INT_FAST32_MIN, None, )
+SYMBOL(INT_FAST64_MAX, None, )
+SYMBOL(INT_FAST64_MIN, None, )
+SYMBOL(INT_FAST8_MAX, None, )
+SYMBOL(INT_FAST8_MIN, None, )
+SYMBOL(INT_LEAST16_MAX, None, )
+SYM

[PATCH] D63264: [clang][Driver] Deduce target triplet from clang executable name

2019-06-21 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63264



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


[PATCH] D59253: [AIX][libcxx] AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined

2019-06-21 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

FYI, I had similar patches for Linux/Debian packaging.
Thanks!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59253



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


[PATCH] D63194: [clangd] Link in target infos and pass target and mode while invoking driver

2019-06-21 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet marked an inline comment as done.
kadircet added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63194



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


[PATCH] D62804: [clangd] Enable extraction of system includes from custom toolchains

2019-06-21 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62804



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


[PATCH] D63270: [clangd] Add include-mapping for C symbols.

2019-06-21 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364044: [clangd] Add include-mapping for C symbols. 
(authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63270?vs=204731&id=205988#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63270

Files:
  clang-tools-extra/trunk/clangd/CSymbolMap.inc
  clang-tools-extra/trunk/clangd/ClangdUnit.cpp
  clang-tools-extra/trunk/clangd/StdSymbolMap.inc
  clang-tools-extra/trunk/clangd/include-mapping/cppreference_parser.py
  clang-tools-extra/trunk/clangd/include-mapping/gen_std.py
  clang-tools-extra/trunk/clangd/include-mapping/test.py
  clang-tools-extra/trunk/clangd/index/CanonicalIncludes.cpp
  clang-tools-extra/trunk/clangd/index/CanonicalIncludes.h
  clang-tools-extra/trunk/clangd/index/IndexAction.cpp
  clang-tools-extra/trunk/clangd/unittests/CanonicalIncludesTests.cpp
  clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp

Index: clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp
@@ -945,7 +945,9 @@
 TEST_F(SymbolCollectorTest, CanonicalSTLHeader) {
   CollectorOpts.CollectIncludePath = true;
   CanonicalIncludes Includes;
-  addSystemHeadersMapping(&Includes);
+  auto Language = LangOptions();
+  Language.CPlusPlus = true;
+  addSystemHeadersMapping(&Includes, Language);
   CollectorOpts.Includes = &Includes;
   runSymbolCollector("namespace std { class string {}; }", /*Main=*/"");
   EXPECT_THAT(Symbols,
Index: clang-tools-extra/trunk/clangd/unittests/CanonicalIncludesTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/CanonicalIncludesTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/CanonicalIncludesTests.cpp
@@ -13,12 +13,24 @@
 namespace clangd {
 namespace {
 
+TEST(CanonicalIncludesTest, CStandardLibrary) {
+  CanonicalIncludes CI;
+  auto Language = LangOptions();
+  Language.C11 = true;
+  addSystemHeadersMapping(&CI, Language);
+  // Usual standard library symbols are mapped correctly.
+  EXPECT_EQ("", CI.mapHeader("path/stdio.h", "printf"));
+}
+
 TEST(CanonicalIncludesTest, CXXStandardLibrary) {
   CanonicalIncludes CI;
-  addSystemHeadersMapping(&CI);
+  auto Language = LangOptions();
+  Language.CPlusPlus = true;
+  addSystemHeadersMapping(&CI, Language);
 
   // Usual standard library symbols are mapped correctly.
   EXPECT_EQ("", CI.mapHeader("path/vector.h", "std::vector"));
+  EXPECT_EQ("", CI.mapHeader("path/stdio.h", "std::printf"));
   // std::move is ambiguous, currently mapped only based on path
   EXPECT_EQ("", CI.mapHeader("libstdc++/bits/move.h", "std::move"));
   EXPECT_EQ("path/utility.h", CI.mapHeader("path/utility.h", "std::move"));
Index: clang-tools-extra/trunk/clangd/CSymbolMap.inc
===
--- clang-tools-extra/trunk/clangd/CSymbolMap.inc
+++ clang-tools-extra/trunk/clangd/CSymbolMap.inc
@@ -0,0 +1,944 @@
+//===-- gen_std.py generated file ---*- C++ -*-===//
+//
+// Used to build a lookup table (qualified names => include headers) for C
+// Standard Library symbols.
+//
+// Automatically generated file, DO NOT EDIT!
+//
+// Generated from cppreference offline HTML book (modified on 2018-10-28).
+//===--===//
+
+SYMBOL(ATOMIC_BOOL_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR16_T_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR32_T_LOCK_FREE, None, )
+SYMBOL(ATOMIC_CHAR_LOCK_FREE, None, )
+SYMBOL(ATOMIC_FLAG_INIT, None, )
+SYMBOL(ATOMIC_INT_LOCK_FREE, None, )
+SYMBOL(ATOMIC_LLONG_LOCK_FREE, None, )
+SYMBOL(ATOMIC_LONG_LOGK_FREE, None, )
+SYMBOL(ATOMIC_POINTER_LOCK_FREE, None, )
+SYMBOL(ATOMIC_SHORT_LOCK_FREE, None, )
+SYMBOL(ATOMIC_VAR_INIT, None, )
+SYMBOL(ATOMIC_WCHAR_T_LOCK_FREE, None, )
+SYMBOL(BUFSIZ, None, )
+SYMBOL(CHAR_BIT, None, )
+SYMBOL(CHAR_MAX, None, )
+SYMBOL(CHAR_MIN, None, )
+SYMBOL(CLOCKS_PER_SEC, None, )
+SYMBOL(CMPLX, None, )
+SYMBOL(CMPLXF, None, )
+SYMBOL(CMPLXL, None, )
+SYMBOL(DBL_DECIMAL_DIG, None, )
+SYMBOL(DBL_DIG, None, )
+SYMBOL(DBL_EPSILON, None, )
+SYMBOL(DBL_HAS_SUBNORM, None, )
+SYMBOL(DBL_MANT_DIG, None, )
+SYMBOL(DBL_MAX, None, )
+SYMBOL(DBL_MAX_10_EXP, None, )
+SYMBOL(DBL_MAX_EXP, None, )
+SYMBOL(DBL_MIN, None, )
+SYMBOL(DBL_MIN_10_EXP, None, )
+SYMBOL(DBL_MIN_EXP, None, )
+SYMBOL(DBL_TRUE_MIN, None, )
+SYMBOL(DECIMAL_DIG, None, )
+SYMBOL(EDOM, None, )
+SYMBOL(EILSEQ, None, )
+SYMBOL(EOF, None, )
+SYMBOL(ERANGE, None, )
+SYMBOL(EXIT_FAILURE, None, )
+SYMBOL(EXIT_SUCCESS, None, )
+SYMBOL(FE_ALL_EXCEPT, None, )
+SYMBOL(FE_DFL_ENV, None

[PATCH] D63648: [Preprocessor] Honor absolute paths in diagnostics

2019-06-21 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea created this revision.
aganea added reviewers: hans, thakis, rsmith.
aganea added a project: clang.

Previously, `-fdiagnostics-absolute-paths` did not have an effect in some 
cases, for example: when using relative include paths, or relative CPP paths, 
or `--show-includes`, or `-E` or displaying notes. We have a peculiar use-case 
on our end with Fastbuild, where all this was exposed: CPP files are being are 
preprocessed on one PC, then compiled on another PC (which doesn't have the 
source-code); then the compiler's stdout is displayed on the first PC.


Repository:
  rC Clang

https://reviews.llvm.org/D63648

Files:
  include/clang/Frontend/TextDiagnostic.h
  lib/Frontend/HeaderIncludeGen.cpp
  lib/Frontend/PrintPreprocessedOutput.cpp
  lib/Frontend/TextDiagnostic.cpp
  test/Frontend/absolute-paths.c
  test/Modules/build-fail-notes.m
  test/Preprocessor/pp-modules.c

Index: test/Preprocessor/pp-modules.c
===
--- test/Preprocessor/pp-modules.c
+++ test/Preprocessor/pp-modules.c
@@ -13,3 +13,30 @@
 #include "pp-modules.h" // CHECK: # 1 "{{.*}}pp-modules.h" 1
 // CHECK: #pragma clang module import Module /* clang -E: implicit import for #include  */{{$}}
 // CHECK: # 14 "{{.*}}pp-modules.c" 2
+
+// Also test path canonicalization 
+// RUN: cd %S
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -x objective-c pp-modules.c -F %S/../Modules/Inputs -E -o - | FileCheck -check-prefix=CHECK-RELATIVE %s
+
+// CHECK-RELATIVE: # 1 "pp-modules.c"
+// CHECK-RELATIVE-NEXT: # 1 "" 1
+// CHECK-RELATIVE-NEXT: # 1 "" 3
+// CHECK-RELATIVE-NEXT: # {{[0-9]+}} "" 3
+// CHECK-RELATIVE-NEXT: # 1 "" 1
+// CHECK-RELATIVE-NEXT: # 1 "" 2
+// CHECK-RELATIVE-NEXT: # 1 "pp-modules.c" 2
+// CHECK-RELATIVE: # 1 "./pp-modules.h" 1
+// CHECK-RELATIVE: # 14 "pp-modules.c" 2
+
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -x objective-c pp-modules.c -F %S/../Modules/Inputs -E -o - -fdiagnostics-absolute-paths | FileCheck -check-prefix=CHECK-ABSOLUTE %s
+
+// CHECK-ABSOLUTE: # 1 "{{.+(/|)test(/|)Preprocessor(/|)}}pp-modules.c"
+// CHECK-ABSOLUTE-NEXT: # 1 "" 1
+// CHECK-ABSOLUTE-NEXT: # 1 "" 3
+// CHECK-ABSOLUTE-NEXT: # {{[0-9]+}} "" 3
+// CHECK-ABSOLUTE-NEXT: # 1 "" 1
+// CHECK-ABSOLUTE-NEXT: # 1 "" 2
+// CHECK-ABSOLUTE-NEXT: # 1 "{{.+(/|)test(/|)Preprocessor(/|)}}pp-modules.c" 2
+
+// CHECK-ABSOLUTE: # 1 "{{.+(/|)test(/|)Preprocessor(/|)}}pp-modules.h" 1
+// CHECK-ABSOLUTE: # 14 "{{.+(/|)test(/|)Preprocessor(/|)}}pp-modules.c" 2
Index: test/Modules/build-fail-notes.m
===
--- test/Modules/build-fail-notes.m
+++ test/Modules/build-fail-notes.m
@@ -29,3 +29,16 @@
 // CHECK-SDIAG: DependsOnModule.h:1:10: fatal: could not build module 'Module'
 // CHECK-SDIAG: build-fail-notes.m:4:9: note: while building module 'DependsOnModule' imported from
 
+// Also test path canonicalization 
+// RUN: cd %S
+// RUN: not %clang_cc1 -Wincomplete-umbrella -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -F Inputs -DgetModuleVersion="epic fail" -serialize-diagnostic-file %t/tmp.diag build-fail-notes.m 2>&1 -fdiagnostics-show-note-include-stack | FileCheck -check-prefix=CHECK-RELATIVE %s
+// CHECK-RELATIVE: While building module 'DependsOnModule' imported from build-fail-notes.m:4:
+// CHECK-RELATIVE-NEXT: While building module 'Module' imported from Inputs{{/|\\}}DependsOnModule.framework{{/|\\}}Headers{{/|\\}}DependsOnModule.h:1:
+// CHECK-RELATIVE-NEXT: In file included from :1:
+// CHECK-RELATIVE-NEXT: Inputs{{/|\\}}Module.framework{{/|\\}}Headers{{/|\\}}Module.h:9:13: error: expected ';' after top level declarator
+
+// RUN: not %clang_cc1 -Wincomplete-umbrella -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -F Inputs -DgetModuleVersion="epic fail" -serialize-diagnostic-file %t/tmp.diag build-fail-notes.m 2>&1 -fdiagnostics-show-note-include-stack -fdiagnostics-absolute-paths | FileCheck -check-prefix=CHECK-ABSOLUTE %s
+// CHECK-ABSOLUTE: While building module 'DependsOnModule' imported from {{.+(/|\\)test(/|\\)Modules(/|\\)}}build-fail-notes.m:4:
+// CHECK-ABSOLUTE-NEXT: While building module 'Module' imported from {{.+(/|\\)test(/|\\)Modules(/|\\)Inputs(/|\\)DependsOnModule.framework(/|\\)Headers(/|\\)}}DependsOnModule.h:1:
+// CHECK-ABSOLUTE-NEXT: In file included from {{.+(/|\\)test(/|\\)Modules(/|\\)}}:1:
+// CHECK-ABSOLUTE-NEXT: {{.+(/|\\)test(/|\\)Modules(/|\\)Inputs(/|\\)Module.framework(/|\\)Headers(/|\\)}}Module.h:9:13: error: expected ';' after top level declarator
Index: test/Frontend/absolute-paths.c
===
--- test/Frontend/absolute-paths.c
+++ test/Frontend/absolute-paths.c
@@ -15,3 +15,19 @@
 int g() {}
 // NORMAL: non-existant.c:123:10: warning: control reaches end of non-void function
 // ABSOLUTE: non-existant.c:123:10: wa

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-06-21 Thread Anton Afanasyev via Phabricator via cfe-commits
anton-afanasyev added a comment.

Also, first `"Frontend"` section contains `"ParseTemplate"` and 
`"PerformPendingInstantiations"` sections.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325



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


[PATCH] D63649: AMDGPU: Fix target builtins for gfx10

2019-06-21 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added a reviewer: rampitec.
Herald added subscribers: t-tye, tpr, dstuttard, yaxunl, nhaehnle, wdng, 
jvesely, kzhuravl.

This wasn't setting some of the features from older generations.


https://reviews.llvm.org/D63649

Files:
  lib/Basic/Targets/AMDGPU.cpp
  test/CodeGenOpenCL/amdgpu-features.cl
  test/CodeGenOpenCL/builtins-amdgcn-ci.cl
  test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err-clamp.cl
  test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
  test/CodeGenOpenCL/builtins-amdgcn-dl-insts.cl
  test/CodeGenOpenCL/builtins-amdgcn-gfx9.cl
  test/CodeGenOpenCL/builtins-amdgcn-vi.cl

Index: test/CodeGenOpenCL/builtins-amdgcn-vi.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-vi.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-vi.cl
@@ -1,5 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu tonga -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx900 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1010 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1012 -S -emit-llvm -o - %s | FileCheck %s
 
 #pragma OPENCL EXTENSION cl_khr_fp16 : enable
 
Index: test/CodeGenOpenCL/builtins-amdgcn-gfx9.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-gfx9.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-gfx9.cl
@@ -1,5 +1,6 @@
 // REQUIRES: amdgpu-registered-target
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx900 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1010 -S -emit-llvm -o - %s | FileCheck %s
 
 #pragma OPENCL EXTENSION cl_khr_fp16 : enable
 
Index: test/CodeGenOpenCL/builtins-amdgcn-dl-insts.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-dl-insts.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-dl-insts.cl
@@ -1,6 +1,8 @@
 // REQUIRES: amdgpu-registered-target
 
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx906 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1011 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1012 -S -emit-llvm -o - %s | FileCheck %s
 
 typedef unsigned int uint;
 typedef half __attribute__((ext_vector_type(2))) half2;
Index: test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err.cl
@@ -1,6 +1,7 @@
 // REQUIRES: amdgpu-registered-target
 
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx900 -verify -S -emit-llvm -o - %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1010 -verify -S -emit-llvm -o - %s
 
 typedef unsigned int uint;
 typedef half __attribute__((ext_vector_type(2))) half2;
Index: test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err-clamp.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err-clamp.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-dl-insts-err-clamp.cl
@@ -1,6 +1,7 @@
 // REQUIRES: amdgpu-registered-target
 
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx906 -verify -S -emit-llvm -o - %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1010 -verify -S -emit-llvm -o - %s
 
 typedef unsigned int uint;
 typedef half __attribute__((ext_vector_type(2))) half2;
Index: test/CodeGenOpenCL/builtins-amdgcn-ci.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn-ci.cl
+++ test/CodeGenOpenCL/builtins-amdgcn-ci.cl
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu hawaii -S -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu fiji -S -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx906 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu gfx1010 -S -emit-llvm -o - %s | FileCheck %s
 
 typedef unsigned int uint;
 
Index: test/CodeGenOpenCL/amdgpu-features.cl
===
--- test/CodeGenOpenCL/amdgpu-features.cl
+++ test/CodeGenOpenCL/amdgpu-features.cl
@@ -15,9 +15,9 @@
 
 // GFX904: "target-features"="+16-bit-insts,+ci-insts,+dpp,+fp32-denormals,+fp64-fp16-denormals,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX906: "target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dpp,+fp32-denormals,+fp64-fp16-denormals,+gfx8-insts,+gfx9-insts,+s-memrealtime"
-// GFX1010: "targ

[PATCH] D63579: [clang-scan-deps] print the dependencies to stdout and remove the need to use -MD options in the CDB

2019-06-21 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea accepted this revision.
aganea added a comment.
This revision is now accepted and ready to land.

LGTM! Thank you!


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

https://reviews.llvm.org/D63579



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


[PATCH] D63626: [clang][NewPM] Remove exception handling before loading pgo sample profile data

2019-06-21 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

Adding Wei who works on SamplePGO on our end currently.




Comment at: llvm/lib/Passes/PassBuilder.cpp:665-668
+// We must also remove exception handling before attaching sample profile
+// data.
+MPM.addPass(
+createModuleToPostOrderCGSCCPassAdaptor(PostOrderFunctionAttrsPass()));

chandlerc wrote:
> Does the this need to go before the EarlyFPM as well as before the sample 
> profile loader?
> 
> Also, this is ... a pretty expensive thing to do... Do we really need this? 
> We've been using ThinLTO and sample PGO with the new PM for a long time and 
> haven't seen any real issue. I think we can probably just leave this 
> difference between the two pass managers and remove the test for this pass 
> running rather than adding it.
> 
> CC-ing some others just to double check, but I'm not aware of any issues 
> we've seen with PGO that were because of this discrepancy.
We don't tend to use exception handling so might not be hitting the issue 
described in the headline.

If this is fixing an issue with SamplePGO and EH cleanup interactions, can you 
add a test that tests for that (i.e. is there a code optimization issue 
currently?).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63626



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


[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

2019-06-21 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked an inline comment as done.
Anastasia added inline comments.



Comment at: lib/Sema/TreeTransform.h:5363
+if (ResultType.getAddressSpace() != LangAS::Default &&
+(ResultType.getAddressSpace() != LangAS::opencl_private)) {
   SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),

rjmccall wrote:
> Anastasia wrote:
> > I am trying to be a bit more helpful here although I am not sure if we 
> > should instead require explicit template parameter and fail the template 
> > deduction instead.
> > 
> > Basically, do we want the following code to always require specifying 
> > template argument explicitly:
> > 
> > 
> > ```
> > template 
> > T xxx(T *in) {
> >   T *i = in;
> >   return *i;
> > }
> > 
> > __kernel void test() {
> >   int foo[10];
> >   xxx(&foo[0]); // if we deduce type from foo, it ends up being 
> > qualified by __private that we currently diagnose. However private is 
> > default (implicit) address space for return type so technically there is no 
> > danger in just allowing xxx(&foo[0])
> > }
> > ```
> Implicitly ignoring all address-space qualifiers on the return type seems 
> like the right thing to do; I don't think it needs to be limited to 
> `__private`.  That's probably also the right thing to do for locals, but I'm 
> less certain about it.
Just to clarify by "Implicitly ignoring" you mean ignoring if the templ 
parameters were deduced?

Although I am a bit concerned about allowing other than `__private` address 
spaces in return types as we reject them in return types of functions 
generally. Would it not be somehow inconsistent?


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

https://reviews.llvm.org/D62584



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


[PATCH] D63626: [clang][NewPM] Remove exception handling before loading pgo sample profile data

2019-06-21 Thread David Li via Phabricator via cfe-commits
davidxl added a comment.

Is there a bug reference somewhere?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63626



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


r364055 - Add an automated note to files produced by gen_ast_dump_json_test.py.

2019-06-21 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Fri Jun 21 07:37:39 2019
New Revision: 364055

URL: http://llvm.org/viewvc/llvm-project?rev=364055&view=rev
Log:
Add an automated note to files produced by gen_ast_dump_json_test.py.

This also details what filters, if any, were used to generate the test output. 
Updates all the current JSON testing files to include the automated note.

Modified:
cfe/trunk/test/AST/ast-dump-comment-json.cpp
cfe/trunk/test/AST/ast-dump-decl-json.c
cfe/trunk/test/AST/ast-dump-decl-json.m
cfe/trunk/test/AST/ast-dump-enum-json.cpp
cfe/trunk/test/AST/ast-dump-expr-json.c
cfe/trunk/test/AST/ast-dump-expr-json.cpp
cfe/trunk/test/AST/ast-dump-expr-json.m
cfe/trunk/test/AST/ast-dump-funcs-json.cpp
cfe/trunk/test/AST/ast-dump-if-json.cpp
cfe/trunk/test/AST/ast-dump-macro-json.c
cfe/trunk/test/AST/ast-dump-namespace-json.cpp
cfe/trunk/test/AST/ast-dump-record-definition-data-json.cpp
cfe/trunk/test/AST/ast-dump-records-json.cpp
cfe/trunk/test/AST/ast-dump-stmt-json.c
cfe/trunk/test/AST/ast-dump-stmt-json.cpp
cfe/trunk/test/AST/ast-dump-stmt-json.m
cfe/trunk/test/AST/ast-dump-template-decls-json.cpp
cfe/trunk/test/AST/ast-dump-temporaries-json.cpp
cfe/trunk/test/AST/gen_ast_dump_json_test.py
cfe/trunk/test/AST/multistep-explicit-cast-json.c
cfe/trunk/test/AST/multistep-explicit-cast-json.cpp

Modified: cfe/trunk/test/AST/ast-dump-comment-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-comment-json.cpp?rev=364055&r1=364054&r2=364055&view=diff
==
--- cfe/trunk/test/AST/ast-dump-comment-json.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-comment-json.cpp Fri Jun 21 07:37:39 2019
@@ -35,6 +35,9 @@ int Test_VerbatimBlockComment;
 template
 void Test_TemplatedFunctionVariadic(int arg, ...);
 
+// NOTE: CHECK lines have been autogenerated by gen_ast_dump_json_test.py
+// using --filters=FullComment
+
 
 // CHECK:  "kind": "FullComment",
 // CHECK-NEXT:  "loc": {

Modified: cfe/trunk/test/AST/ast-dump-decl-json.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-decl-json.c?rev=364055&r1=364054&r2=364055&view=diff
==
--- cfe/trunk/test/AST/ast-dump-decl-json.c (original)
+++ cfe/trunk/test/AST/ast-dump-decl-json.c Fri Jun 21 07:37:39 2019
@@ -86,6 +86,7 @@ int TestVarDeclInit = 0;
 
 void testParmVarDecl(int TestParmVarDecl);
 
+// NOTE: CHECK lines have been autogenerated by gen_ast_dump_json_test.py
 
 
 // CHECK:  "kind": "VarDecl",
@@ -1668,4 +1669,3 @@ void testParmVarDecl(int TestParmVarDecl
 // CHECK-NEXT:   "qualType": "int"
 // CHECK-NEXT:  }
 // CHECK-NEXT: }
-

Modified: cfe/trunk/test/AST/ast-dump-decl-json.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-decl-json.m?rev=364055&r1=364054&r2=364055&view=diff
==
--- cfe/trunk/test/AST/ast-dump-decl-json.m (original)
+++ cfe/trunk/test/AST/ast-dump-decl-json.m Fri Jun 21 07:37:39 2019
@@ -83,6 +83,8 @@ void f() {
   __typeof__(B.foo) Test;
 }
 
+// NOTE: CHECK lines have been autogenerated by gen_ast_dump_json_test.py
+
 
 // CHECK:  "kind": "ObjCInterfaceDecl", 
 // CHECK-NEXT:  "loc": {

Modified: cfe/trunk/test/AST/ast-dump-enum-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-enum-json.cpp?rev=364055&r1=364054&r2=364055&view=diff
==
--- cfe/trunk/test/AST/ast-dump-enum-json.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-enum-json.cpp Fri Jun 21 07:37:39 2019
@@ -5,480 +5,488 @@ enum {
   Two
 };
 
-// CHECK: "kind": "EnumDecl",
-// CHECK-NEXT: "loc": {
-// CHECK-NEXT: "col": 1,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 3
-// CHECK-NEXT: },
-// CHECK-NEXT: "range": {
-// CHECK-NEXT: "begin": {
-// CHECK-NEXT: "col": 1,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 3
-// CHECK-NEXT: },
-// CHECK-NEXT: "end": {
-// CHECK-NEXT: "col": 1,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 6
-// CHECK-NEXT: }
-// CHECK-NEXT: },
-// CHECK-NEXT: "inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT: "id": "0x{{.*}}",
-// CHECK-NEXT: "kind": "EnumConstantDecl",
-// CHECK-NEXT: "loc": {
-// CHECK-NEXT: "col": 3,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 4
-// CHECK-NEXT: },
-// CHECK-NEXT: "range": {
-// CHECK-NEXT: "begin": {
-// CHECK-NEXT: "col": 3,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 4
-// CHECK-NEXT: },
-// CHECK-NEXT: "end": {
-// CHECK-NEXT: "col": 3,
-// CHECK-NEXT: "file": "{{.*}}",
-// CHECK-NEXT: "line": 4
-// CHECK-NEXT: }
-// CHECK-NEXT: },
-// CHECK-NEXT: "name": "One",
-// CHECK-NEXT: "type": {
-// CHECK-NEXT: "qualType": "(anonymous enum at {{.*}}:3:1)"
-// CHECK-NEXT: }
-// CHECK-NEXT: },
-// CHECK-NEX

[PATCH] D63264: [clang][Driver] Deduce target triplet from clang executable name

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

After looking at this, adjusting arguments on the clangd side seems to be a 
better approach.
Let's abandon this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63264



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


[PATCH] D63194: [clangd] Link in target infos and pass target and mode while invoking driver

2019-06-21 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Sorry about the confusion, I can now see why the original version of the patch 
was actually simpler.
I was put off by the fact that we override by adding command-line arguments 
instead of passing things around in the code, but it appears that's actually 
simpler than adding yet another mechanism to override target tripple in the 
driver.

The only suggestion from me would be maybe try moving this to a layer that 
would also make also benefit other compilation-db-based things like 
`clang-tidy`, etc?
Any ideas on how to do this? Would this potentially break anything?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63194



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


[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

2019-06-21 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked an inline comment as done.
Anastasia added inline comments.



Comment at: lib/CodeGen/CGDeclCXX.cpp:132
+  Argument = CGM.getTargetCodeGenInfo().performAddrSpaceCast(
+  CGM, Addr.getPointer(), SrcAS, LangAS::opencl_global, DestTy);
 

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > Should this code be conditional to OpenCL?  And why does `_cxa_atexit` 
> > > take a `__global` pointer instead of, say, a `__generic` one?
> > The only objects that are destructible globally in OpenCL are `__global` 
> > and `__constant`. However `__constant` isn't convertible to `__generic`. 
> > Therefore, I am adding `__global` directly to avoid extra conversion. I am 
> > not yet sure how to handle `__constant`though and how much destructing 
> > objects in read-only memory segments would make sense anyway. I think I 
> > will address this separately.
> The pointer argument to `__cxa_atexit` is just an arbitrary bit of context 
> and doesn't have to actually be the address of a global.  It's *convenient* 
> to use the address of a global sometimes; e.g. you can use the global as the 
> pointer and its destructor as the function, and then `__cxa_atexit` will just 
> call the destructor for you without any additional code.  But as far as the 
> runtime is concerned, the pointer could be `malloc`'ed or something; we've 
> never had a need to do that in the ABI, but it's good future-proofing to 
> allow it.
> 
> So there are three ways to get a global destructor to destroy a variable in 
> `__constant`:
> - You can pass the pointer bitcast'ed as long as `sizeof(__constant void*) <= 
> sizeof(__cxa_atexit_context_pointer)`.
> - You can ignore the argument and just materialize the address separately 
> within the destructor function.
> - You can allocate memory for a context and then store the pointer in that.
> 
> Obviously you should go with the one of the first two, but you should make 
> sure your ABI doesn't preclude doing the latter in case it's useful for some 
> future language feature.  In other words, it doesn't really matter whether 
> this argument is notionally in `__global` as long as that's wide enough to 
> pass a more-or-less arbitrary pointer through.
Ok, I see. I guess option 1 would be fine since we can't setup pointer width 
per address space in clang currently. However, spec doesn't provide any 
clarifications in this regard.

So I guess using either `__global` or `__generic` for the pointer parameter 
would be fine... Or perhaps even leave it without any address space (i.e. 
_`_private`) and just addrspacecast from either `__global` or `__constant`. Do 
you have any preferences?

As for `malloc` I am not sure that will work for OpenCL since we don't allow 
mem allocation on the device. Unless you mean the memory is allocated on a 
host... then I am not sure how it should work.


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

https://reviews.llvm.org/D62413



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


r364061 - [OPENMP]Fix PR42159: do not capture threadprivate variables.

2019-06-21 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Fri Jun 21 08:08:30 2019
New Revision: 364061

URL: http://llvm.org/viewvc/llvm-project?rev=364061&view=rev
Log:
[OPENMP]Fix PR42159: do not capture threadprivate variables.

The threadprivate variables should not be captured in the outlined
regions, otherwise it leads to the compiler crash.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=364061&r1=364060&r2=364061&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Jun 21 08:08:30 2019
@@ -1866,11 +1866,14 @@ VarDecl *Sema::isOpenMPCapturedDecl(Valu
 DSAStack->getTopDSA(D, DSAStack->isClauseParsingMode());
 if (DVarPrivate.CKind != OMPC_unknown && 
isOpenMPPrivate(DVarPrivate.CKind))
   return VD ? VD : cast(DVarPrivate.PrivateCopy->getDecl());
+// Threadprivate variables must not be captured.
+if (isOpenMPThreadPrivate(DVarPrivate.CKind))
+  return nullptr;
+// The variable is not private or it is the variable in the directive with
+// default(none) clause and not used in any clause.
 DVarPrivate = DSAStack->hasDSA(D, isOpenMPPrivate,
[](OpenMPDirectiveKind) { return true; },
DSAStack->isClauseParsingMode());
-// The variable is not private or it is the variable in the directive with
-// default(none) clause and not used in any clause.
 if (DVarPrivate.CKind != OMPC_unknown ||
 (VD && DSAStack->getDefaultDSA() == DSA_none))
   return VD ? VD : cast(DVarPrivate.PrivateCopy->getDecl());

Modified: cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp?rev=364061&r1=364060&r2=364061&view=diff
==
--- cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp Fri Jun 21 08:08:30 2019
@@ -239,8 +239,8 @@ int main() {
 vec[0] = t_var;
 s_arr[0] = var;
   }
-#pragma omp parallel copyin(t_var)
-  {}
+#pragma omp parallel copyin(t_var) default(none)
+  ++t_var;
   return tmain();
 #endif
 }
@@ -363,6 +363,7 @@ int main() {
 // TLS-CHECK: [[DONE]]
 
 // CHECK: call {{.*}}void @__kmpc_barrier(%{{.+}}* [[IMPLICIT_BARRIER_LOC]], 
i32 [[GTID]])
+// CHECK: add nsw i32 %{{.+}}, 1
 // CHECK: ret void
 
 // TLS-CHECK: [[GTID_ADDR:%.+]] = load i32*, i32** [[GTID_ADDR_ADDR]],


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


Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread Rainer Orth via cfe-commits
Hi Douglas,

> Your change appears to have broken the one platform you didn't test, Windows. 
> :)

sorry about that.  Unfortunately, I know next to nothing about Windows
and don't have access to any system to test.

That said...

> Script:
> --
> : 'RUN: at line 7'; printf
> '/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
> /DFOO=2' >
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp

... I should have looked at the autoconf manual first which has a whole
section on the can of worms that is echo and how to properly use printf
instead.

> Looking into this locally, the path contains "\t", so the response file that 
> is generated looks like this:
>
> C:\src\git\merge\llvm\tools\clang\test\Driver>type cl-response-file.c.tmp.rsp
> /IC:\src\git\merge\llvm ools

The path not only contains \t, but \c as well, so the path is truncated
after " ools".

> Can you take a look to see if there is something that works for all platforms 
> including Windows?

Judging from both the autoconf manual and my local testing, the
following should work properly:

// RUN: printf '%s\n' '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp

i.e. use printf '%s\n' to do the printing.  I should have done this in
the first place since otherwise the response file wasn't
newline-terminated.  Obviously that didn't matter on Solaris and Linux.

Once you've confirmed this works on Windows, I'll submit a proper
follow-up patch.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D63616: Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang

2019-06-21 Thread Yannis Juglaret via Phabricator via cfe-commits
tuktuk updated this revision to Diff 206006.
tuktuk added a comment.
Herald added subscribers: Sanitizers, kubamracek, srhines.

I followed Roman Lebedev's advice and adapted the 
`sanitizer_coverage_no_prune.cc` test to create a 
`sanitizer_coverage_whitelist_blacklist.cc` test under `make check_sanitizer`. 
I can only try the test on a Linux machine, and it passes on that machine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63616

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cc
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -34,6 +34,7 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
+#include "llvm/Support/SpecialCaseList.h"
 #include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
@@ -179,8 +180,16 @@
 class SanitizerCoverageModule : public ModulePass {
 public:
   SanitizerCoverageModule(
-  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions())
+  const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+  const std::vector& WhitelistFiles = std::vector(),
+  const std::vector& BlacklistFiles = std::vector())
   : ModulePass(ID), Options(OverrideFromCL(Options)) {
+if (WhitelistFiles.size() > 0) {
+  Whitelist = SpecialCaseList::createOrDie(WhitelistFiles);
+}
+if (BlacklistFiles.size() > 0) {
+  Blacklist = SpecialCaseList::createOrDie(BlacklistFiles);
+}
 initializeSanitizerCoverageModulePass(*PassRegistry::getPassRegistry());
   }
   bool runOnModule(Module &M) override;
@@ -250,6 +259,9 @@
   SmallVector GlobalsToAppendToCompilerUsed;
 
   SanitizerCoverageOptions Options;
+
+  std::unique_ptr Whitelist;
+  std::unique_ptr Blacklist;
 };
 
 } // namespace
@@ -313,6 +325,12 @@
 bool SanitizerCoverageModule::runOnModule(Module &M) {
   if (Options.CoverageType == SanitizerCoverageOptions::SCK_None)
 return false;
+  if (Whitelist &&
+  !Whitelist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
+  if (Blacklist &&
+  Blacklist->inSection("coverage", "src", M.getSourceFileName()))
+return false;
   C = &(M.getContext());
   DL = &M.getDataLayout();
   CurModule = &M;
@@ -541,6 +559,10 @@
   if (F.hasPersonalityFn() &&
   isAsynchronousEHPersonality(classifyEHPersonality(F.getPersonalityFn(
 return false;
+  if (Whitelist && !Whitelist->inSection("coverage", "fun", F.getName()))
+return false;
+  if (Blacklist && Blacklist->inSection("coverage", "fun", F.getName()))
+return false;
   if (Options.CoverageType >= SanitizerCoverageOptions::SCK_Edge)
 SplitAllCriticalEdges(F, CriticalEdgeSplittingOptions().setIgnoreUnreachableDests());
   SmallVector IndirCalls;
@@ -898,6 +920,8 @@
 "ModulePass",
 false, false)
 ModulePass *llvm::createSanitizerCoverageModulePass(
-const SanitizerCoverageOptions &Options) {
-  return new SanitizerCoverageModule(Options);
+const SanitizerCoverageOptions &Options,
+const std::vector& WhitelistFiles,
+const std::vector& BlacklistFiles) {
+  return new SanitizerCoverageModule(Options, WhitelistFiles, BlacklistFiles);
 }
Index: llvm/include/llvm/Transforms/Instrumentation.h
===
--- llvm/include/llvm/Transforms/Instrumentation.h
+++ llvm/include/llvm/Transforms/Instrumentation.h
@@ -183,7 +183,9 @@
 
 // Insert SanitizerCoverage instrumentation.
 ModulePass *createSanitizerCoverageModulePass(
-const SanitizerCoverageOptions &Options = SanitizerCoverageOptions());
+const SanitizerCoverageOptions &Options = SanitizerCoverageOptions(),
+const std::vector& WhitelistFiles = std::vector(),
+const std::vector& BlacklistFiles = std::vector());
 
 /// Calculate what to divide by to scale counts.
 ///
Index: compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cc
===
--- /dev/null
+++ compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_whitelist_blacklist.cc
@@ -0,0 +1,73 @@
+// Test

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

2019-06-21 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 206009.
dgoldman added a comment.

- Fix ambiguity handling and add more tests


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,95 @@
+// 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();
+}
+
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7613,12 +7613,12 @@
   /// 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() {
+  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 right
@@ -7680,6 +7680,115 @@
 return ExprFilter(Res.get());
   }
 
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult CheckForRecursiveTypos(ExprResult Res, bool &outIsAmbiguous) {
+if (Res.isInvalid()) {
+  return Res;
+}
+// Check to see if any new TypoExprs were created. If so, we need to recurse
+// to check their validity.
+Expr *FixedExpr = Res.get();
+
+auto SavedTypoExprs = TypoExprs;
+auto SavedAmbiguousTypoExprs = AmbiguousTypoExprs;
+llvm::SmallSetVector
+RecursiveTypoExprs, RecursiveAmbiguousTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+AmbiguousTypoExprs = RecursiveAmbiguousTypoExprs;
+
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+if (!TypoExprs.empty()) {
+  // Recurse to handle newly created TypoExprs. If we're not able to
+  // handle them, disc

[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Any comments? If no, please approve..


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

https://reviews.llvm.org/D63423



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


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

2019-06-21 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 206011.
dgoldman added a comment.

- Add another test and fix up comment


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
@@ -7613,12 +7613,12 @@
   /// 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() {
+  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 right
@@ -7680,6 +7680,115 @@
 return ExprFilter(Res.get());
   }
 
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult CheckForRecursiveTypos(ExprResult Res, bool &outIsAmbiguous) {
+if (Res.isInvalid()) {
+  return Res;
+}
+/

r364066 - [clang][NewPM] Add -fno-experimental-new-pass-manager to tests

2019-06-21 Thread Leonard Chan via cfe-commits
Author: leonardchan
Date: Fri Jun 21 09:03:06 2019
New Revision: 364066

URL: http://llvm.org/viewvc/llvm-project?rev=364066&view=rev
Log:
[clang][NewPM] Add -fno-experimental-new-pass-manager to tests

As per the discussion on D58375, we disable test that have optimizations under
the new PM. This patch adds -fno-experimental-new-pass-manager to RUNS that:

- Already run with optimizations (-O1 or higher) that were missed in D58375.
- Explicitly test new PM behavior along side some new PM RUNS, but are missing
  this flag if new PM is enabled by default.
- Specify -O without the number. Based on getOptimizationLevel(), it seems the
  default is 2, and the IR appears to be the same when changed to -O2, so
  update the test to explicitly say -O2 and provide 
-fno-experimental-new-pass-manager`.

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

Modified:
cfe/trunk/test/CodeGen/aggregate-assign-call.c
cfe/trunk/test/CodeGen/arm_acle.c
cfe/trunk/test/CodeGen/cspgo-instrumentation.c
cfe/trunk/test/CodeGen/cspgo-instrumentation_lto.c
cfe/trunk/test/CodeGen/cspgo-instrumentation_thinlto.c
cfe/trunk/test/CodeGen/pgo-instrumentation.c
cfe/trunk/test/CodeGen/thinlto-debug-pm.c
cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
cfe/trunk/test/CodeGenCXX/conditional-temporaries.cpp
cfe/trunk/test/CodeGenCXX/member-function-pointer-calls.cpp
cfe/trunk/test/CodeGenObjC/os_log.m
cfe/trunk/test/CodeGenObjCXX/os_log.mm
cfe/trunk/test/Misc/pr32207.c

Modified: cfe/trunk/test/CodeGen/aggregate-assign-call.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aggregate-assign-call.c?rev=364066&r1=364065&r2=364066&view=diff
==
--- cfe/trunk/test/CodeGen/aggregate-assign-call.c (original)
+++ cfe/trunk/test/CodeGen/aggregate-assign-call.c Fri Jun 21 09:03:06 2019
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 -S -emit-llvm -o - %s 
| FileCheck %s --check-prefix=O1
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 
-fno-experimental-new-pass-manager -S -emit-llvm -o - %s | FileCheck %s 
--check-prefixes=O1,O1-LEGACY
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 
-fexperimental-new-pass-manager -S -emit-llvm -o - %s | FileCheck %s 
--check-prefixes=O1,O1-NEWPM
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O0 -S -emit-llvm -o - %s 
| FileCheck %s --check-prefix=O0
 //
 // Ensure that we place appropriate lifetime markers around indirectly returned
@@ -50,34 +51,32 @@ struct S baz(int i, volatile int *j) {
   struct S r;
   // O1: %[[TMP1_ALLOCA:[^ ]+]] = alloca %struct.S
   // O1: %[[TMP2_ALLOCA:[^ ]+]] = alloca %struct.S
-  // O1: br label %[[DO_BODY:.+]]
 
   do {
-// O1: [[DO_BODY]]:
 // O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: br i1 {{[^,]+}}, label %[[IF_THEN:[^,]+]], label %[[IF_END:[^,]+]]
+// O1-LEGACY: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* nonnull 
%[[P]])
 //
-// O1: [[IF_THEN]]:
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: br label %[[DO_END:.*]]
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: %[[TMP3:.*]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
+// O1-NEWPM: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* nonnull 
%[[P]])
 //
-// O1: [[IF_END]]:
-// O1: call void @foo_int(%struct.S* sret %[[TMP1_ALLOCA]],
+// O1-LEGACY: call void @foo_int(%struct.S* sret %[[TMP1_ALLOCA]],
+// O1-NEWPM: call void @foo_int(%struct.S* nonnull sret %[[TMP1_ALLOCA]],
 // O1: call void @llvm.memcpy
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: call void @foo_int(%struct.S* sret %[[TMP2_ALLOCA]],
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* nonnull 
%[[P]])
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* nonnull 
%[[TMP3]])
+// O1-LEGACY: call void @foo_int(%struct.S* sret %[[TMP2_ALLOCA]],
+// O1-NEWPM: call void @foo_int(%struct.S* nonnull sret %[[TMP2_ALLOCA]],
 // O1: call void @llvm.m

[PATCH] D63156: [clang][NewPM] Add -fno-experimental-new-pass-manager to tests

2019-06-21 Thread Leonard Chan via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364066: [clang][NewPM] Add 
-fno-experimental-new-pass-manager to tests (authored by leonardchan, committed 
by ).

Changed prior to commit:
  https://reviews.llvm.org/D63156?vs=205906&id=206013#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63156

Files:
  cfe/trunk/test/CodeGen/aggregate-assign-call.c
  cfe/trunk/test/CodeGen/arm_acle.c
  cfe/trunk/test/CodeGen/cspgo-instrumentation.c
  cfe/trunk/test/CodeGen/cspgo-instrumentation_lto.c
  cfe/trunk/test/CodeGen/cspgo-instrumentation_thinlto.c
  cfe/trunk/test/CodeGen/pgo-instrumentation.c
  cfe/trunk/test/CodeGen/thinlto-debug-pm.c
  cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
  cfe/trunk/test/CodeGenCXX/conditional-temporaries.cpp
  cfe/trunk/test/CodeGenCXX/member-function-pointer-calls.cpp
  cfe/trunk/test/CodeGenObjC/os_log.m
  cfe/trunk/test/CodeGenObjCXX/os_log.mm
  cfe/trunk/test/Misc/pr32207.c

Index: cfe/trunk/test/CodeGen/aggregate-assign-call.c
===
--- cfe/trunk/test/CodeGen/aggregate-assign-call.c
+++ cfe/trunk/test/CodeGen/aggregate-assign-call.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 -S -emit-llvm -o - %s | FileCheck %s --check-prefix=O1
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 -fno-experimental-new-pass-manager -S -emit-llvm -o - %s | FileCheck %s --check-prefixes=O1,O1-LEGACY
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O1 -fexperimental-new-pass-manager -S -emit-llvm -o - %s | FileCheck %s --check-prefixes=O1,O1-NEWPM
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O0 -S -emit-llvm -o - %s | FileCheck %s --check-prefix=O0
 //
 // Ensure that we place appropriate lifetime markers around indirectly returned
@@ -50,34 +51,32 @@
   struct S r;
   // O1: %[[TMP1_ALLOCA:[^ ]+]] = alloca %struct.S
   // O1: %[[TMP2_ALLOCA:[^ ]+]] = alloca %struct.S
-  // O1: br label %[[DO_BODY:.+]]
 
   do {
-// O1: [[DO_BODY]]:
 // O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: br i1 {{[^,]+}}, label %[[IF_THEN:[^,]+]], label %[[IF_END:[^,]+]]
+// O1-LEGACY: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* nonnull %[[P]])
 //
-// O1: [[IF_THEN]]:
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: br label %[[DO_END:.*]]
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: %[[TMP3:.*]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
+// O1-NEWPM: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* nonnull %[[P]])
 //
-// O1: [[IF_END]]:
-// O1: call void @foo_int(%struct.S* sret %[[TMP1_ALLOCA]],
+// O1-LEGACY: call void @foo_int(%struct.S* sret %[[TMP1_ALLOCA]],
+// O1-NEWPM: call void @foo_int(%struct.S* nonnull sret %[[TMP1_ALLOCA]],
 // O1: call void @llvm.memcpy
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: call void @foo_int(%struct.S* sret %[[TMP2_ALLOCA]],
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP1_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* nonnull %[[P]])
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.start.p0i8({{[^,]*}}, i8* nonnull %[[TMP3]])
+// O1-LEGACY: call void @foo_int(%struct.S* sret %[[TMP2_ALLOCA]],
+// O1-NEWPM: call void @foo_int(%struct.S* nonnull sret %[[TMP2_ALLOCA]],
 // O1: call void @llvm.memcpy
-// O1: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
-// O1: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
-// O1: br label %[[DO_COND:.*]]
-//
-// O1: [[DO_COND]]:
-// O1: br label %[[DO_BODY]]
+// O1-LEGACY: %[[P:[^ ]+]] = bitcast %struct.S* %[[TMP2_ALLOCA]] to i8*
+// O1-LEGACY: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* %[[P]])
+// O1-NEWPM: call void @llvm.lifetime.end.p0i8({{[^,]*}}, i8* nonnull %[[TMP3]])
 r = foo_int(({
   if (*j)
 break;
@@ -87,7 +86,5 @@
 r = foo_int(i++);
} while (1);
 
-  // O1: [[DO_END]]:
-  // O1-NEXT: ret void
   return r;
 }
Index: cfe/trunk/test/CodeGen/arm_acle.c
==

r364067 - Print more type node information when dumping the AST to JSON.

2019-06-21 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Fri Jun 21 09:06:09 2019
New Revision: 364067

URL: http://llvm.org/viewvc/llvm-project?rev=364067&view=rev
Log:
Print more type node information when dumping the AST to JSON.

Added:
cfe/trunk/test/AST/ast-dump-types-json.cpp
Modified:
cfe/trunk/include/clang/AST/JSONNodeDumper.h
cfe/trunk/lib/AST/JSONNodeDumper.cpp

Modified: cfe/trunk/include/clang/AST/JSONNodeDumper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/JSONNodeDumper.h?rev=364067&r1=364066&r2=364067&view=diff
==
--- cfe/trunk/include/clang/AST/JSONNodeDumper.h (original)
+++ cfe/trunk/include/clang/AST/JSONNodeDumper.h Fri Jun 21 09:06:09 2019
@@ -211,6 +211,9 @@ public:
   void VisitInjectedClassNameType(const InjectedClassNameType *ICNT);
   void VisitObjCInterfaceType(const ObjCInterfaceType *OIT);
   void VisitPackExpansionType(const PackExpansionType *PET);
+  void VisitElaboratedType(const ElaboratedType *ET);
+  void VisitMacroQualifiedType(const MacroQualifiedType *MQT);
+  void VisitMemberPointerType(const MemberPointerType *MPT);
 
   void VisitNamedDecl(const NamedDecl *ND);
   void VisitTypedefDecl(const TypedefDecl *TD);

Modified: cfe/trunk/lib/AST/JSONNodeDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/JSONNodeDumper.cpp?rev=364067&r1=364066&r2=364067&view=diff
==
--- cfe/trunk/lib/AST/JSONNodeDumper.cpp (original)
+++ cfe/trunk/lib/AST/JSONNodeDumper.cpp Fri Jun 21 09:06:09 2019
@@ -611,6 +611,26 @@ void JSONNodeDumper::VisitPackExpansionT
 JOS.attribute("numExpansions", *N);
 }
 
+void JSONNodeDumper::VisitElaboratedType(const ElaboratedType *ET) {
+  if (const NestedNameSpecifier *NNS = ET->getQualifier()) {
+std::string Str;
+llvm::raw_string_ostream OS(Str);
+NNS->print(OS, PrintPolicy, /*ResolveTemplateArgs*/ true);
+JOS.attribute("qualifier", OS.str());
+  }
+  if (const TagDecl *TD = ET->getOwnedTagDecl())
+JOS.attribute("ownedTagDecl", createBareDeclRef(TD));
+}
+
+void JSONNodeDumper::VisitMacroQualifiedType(const MacroQualifiedType *MQT) {
+  JOS.attribute("macroName", MQT->getMacroIdentifier()->getName());
+}
+
+void JSONNodeDumper::VisitMemberPointerType(const MemberPointerType *MPT) {
+  attributeOnlyIfTrue("isData", MPT->isMemberDataPointer());
+  attributeOnlyIfTrue("isFunction", MPT->isMemberFunctionPointer());
+}
+
 void JSONNodeDumper::VisitNamedDecl(const NamedDecl *ND) {
   if (ND && ND->getDeclName())
 JOS.attribute("name", ND->getNameAsString());

Added: cfe/trunk/test/AST/ast-dump-types-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-types-json.cpp?rev=364067&view=auto
==
--- cfe/trunk/test/AST/ast-dump-types-json.cpp (added)
+++ cfe/trunk/test/AST/ast-dump-types-json.cpp Fri Jun 21 09:06:09 2019
@@ -0,0 +1,358 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -ast-dump=json 
-ast-dump-filter Test %s | FileCheck %s
+
+namespace NS {
+struct S {};
+}
+
+struct T {
+  int I;
+  void F();
+};
+
+typedef struct T TestElaboratedType1;
+typedef NS::S TestElaboratedType2;
+
+#define CDECL __attribute__((cdecl))
+typedef void (CDECL *TestMacroQualifiedType)();
+
+typedef void (T::* TestMemberFunctionPointerType)();
+typedef int T::*TestMemberDataPointerType;
+
+// NOTE: CHECK lines have been autogenerated by gen_ast_dump_json_test.py
+
+
+// CHECK:  "kind": "TypedefDecl",
+// CHECK-NEXT:  "loc": {
+// CHECK-NEXT:   "col": 18,
+// CHECK-NEXT:   "file": "{{.*}}",
+// CHECK-NEXT:   "line": 12
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "range": {
+// CHECK-NEXT:   "begin": {
+// CHECK-NEXT:"col": 1,
+// CHECK-NEXT:"file": "{{.*}}",
+// CHECK-NEXT:"line": 12
+// CHECK-NEXT:   },
+// CHECK-NEXT:   "end": {
+// CHECK-NEXT:"col": 18,
+// CHECK-NEXT:"file": "{{.*}}",
+// CHECK-NEXT:"line": 12
+// CHECK-NEXT:   }
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "name": "TestElaboratedType1",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "desugaredQualType": "T",
+// CHECK-NEXT:   "qualType": "struct T"
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "inner": [
+// CHECK-NEXT:   {
+// CHECK-NEXT:"id": "0x{{.*}}",
+// CHECK-NEXT:"kind": "ElaboratedType",
+// CHECK-NEXT:"type": {
+// CHECK-NEXT: "qualType": "struct T"
+// CHECK-NEXT:},
+// CHECK-NEXT:"inner": [
+// CHECK-NEXT: {
+// CHECK-NEXT:  "id": "0x{{.*}}",
+// CHECK-NEXT:  "kind": "RecordType",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "qualType": "T"
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "decl": {
+// CHECK-NEXT:   "id": "0x{{.*}}",
+// CHECK-NEXT:   "kind": "CXXRecordDecl",
+// CHECK-NEXT:   "name": "T"
+// CHECK-NEXT:  }
+// CHECK-NEXT: }
+// CHECK-NEXT:]
+// CHECK-NEXT:   }
+// CHECK-NEXT:  ]
+// CHECK-NEXT: 

r364071 - [OpenCL][PR41963] Add generic addr space to old atomics in C++ mode

2019-06-21 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Fri Jun 21 09:19:16 2019
New Revision: 364071

URL: http://llvm.org/viewvc/llvm-project?rev=364071&view=rev
Log:
[OpenCL][PR41963] Add generic addr space to old atomics in C++ mode

Add overloads with generic address space pointer to old atomics.
This is currently only added for C++ compilation mode.

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


Modified:
cfe/trunk/lib/Headers/opencl-c.h
cfe/trunk/test/Headers/opencl-c-header.cl

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=364071&r1=364070&r2=364071&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Fri Jun 21 09:19:16 2019
@@ -13055,6 +13055,10 @@ int __ovld atomic_add(volatile __global
 unsigned int __ovld atomic_add(volatile __global unsigned int *p, unsigned int 
val);
 int __ovld atomic_add(volatile __local int *p, int val);
 unsigned int __ovld atomic_add(volatile __local unsigned int *p, unsigned int 
val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_add(volatile int *p, int val);
+unsigned int __ovld atomic_add(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_add(volatile __global int *p, int val);
@@ -13081,6 +13085,10 @@ int __ovld atomic_sub(volatile __global
 unsigned int __ovld atomic_sub(volatile __global unsigned int *p, unsigned int 
val);
 int __ovld atomic_sub(volatile __local int *p, int val);
 unsigned int __ovld atomic_sub(volatile __local unsigned int *p, unsigned int 
val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_sub(volatile int *p, int val);
+unsigned int __ovld atomic_sub(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_sub(volatile __global int *p, int val);
@@ -13109,6 +13117,11 @@ int __ovld atomic_xchg(volatile __local
 unsigned int __ovld atomic_xchg(volatile __local unsigned int *p, unsigned int 
val);
 float __ovld atomic_xchg(volatile __global float *p, float val);
 float __ovld atomic_xchg(volatile __local float *p, float val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_xchg(volatile int *p, int val);
+unsigned int __ovld atomic_xchg(volatile unsigned int *p, unsigned int val);
+float __ovld atomic_xchg(volatile float *p, float val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_xchg(volatile __global int *p, int val);
@@ -13136,6 +13149,10 @@ int __ovld atomic_inc(volatile __global
 unsigned int __ovld atomic_inc(volatile __global unsigned int *p);
 int __ovld atomic_inc(volatile __local int *p);
 unsigned int __ovld atomic_inc(volatile __local unsigned int *p);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_inc(volatile int *p);
+unsigned int __ovld atomic_inc(volatile unsigned int *p);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_inc(volatile __global int *p);
@@ -13163,6 +13180,10 @@ int __ovld atomic_dec(volatile __global
 unsigned int __ovld atomic_dec(volatile __global unsigned int *p);
 int __ovld atomic_dec(volatile __local int *p);
 unsigned int __ovld atomic_dec(volatile __local unsigned int *p);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_dec(volatile int *p);
+unsigned int __ovld atomic_dec(volatile unsigned int *p);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_dec(volatile __global int *p);
@@ -13191,6 +13212,10 @@ int __ovld atomic_cmpxchg(volatile __glo
 unsigned int __ovld atomic_cmpxchg(volatile __global unsigned int *p, unsigned 
int cmp, unsigned int val);
 int __ovld atomic_cmpxchg(volatile __local int *p, int cmp, int val);
 unsigned int __ovld atomic_cmpxchg(volatile __local unsigned int *p, unsigned 
int cmp, unsigned int val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_cmpxchg(volatile int *p, int cmp, int val);
+unsigned int __ovld atomic_cmpxchg(volatile unsigned int *p, unsigned int cmp, 
unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_cmpxchg(volatile __global int *p, int cmp, int val);
@@ -13219,6 +13244,10 @@ int __ovld atomic_min(volatile __global
 unsigned int __ovld atomic_min(volatile __global unsigned int *p, unsigned int 
val);
 int __ovld atomic_min(volatile __local int *p, int val);
 unsigned int __ovld atomic_min(volatile __local unsigned int *p, unsigned int 
val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_min(volatile int *p, int val);
+unsigned int __ovld atomic_min(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_extended_atomics)
 int __ovld atom_min(volatile __global int *p, int val);
@@ -13247,6 +13276,10 @@ int __ovld atomic_max(volatile __global
 unsigned int __ovld atomic_max(volatile __global unsigned int *p, unsigned int 
val);
 int __ovld atomic_max(volatile __local int *p, int val

[PATCH] D62373: [ASTImporter] Store import errors for Decls

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 206017.
martong added a comment.

- Remove formatv b/c it can't handle braces in code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62373

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/test/ASTMerge/class-template-partial-spec/test.cpp
  clang/unittests/AST/ASTImporterFixtures.cpp
  clang/unittests/AST/ASTImporterFixtures.h
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -11,6 +11,7 @@
 //===--===//
 
 #include "llvm/ADT/StringMap.h"
+#include "llvm/Support/FormatVariadic.h"
 
 #include "clang/AST/DeclContextInternals.h"
 
@@ -23,6 +24,7 @@
 using internal::Matcher;
 using internal::BindableMatcher;
 using llvm::StringMap;
+using llvm::formatv;
 
 // Base class for those tests which use the family of `testImport` functions.
 class TestImportBase : public CompilerOptionSpecificTest,
@@ -4574,6 +4576,127 @@
   EXPECT_EQ(Imported->getPreviousDecl(), Friend);
 }
 
+struct ASTImporterWithFakeErrors : ASTImporter {
+  using ASTImporter::ASTImporter;
+  bool returnWithErrorInTest() override { return true; }
+};
+
+struct ErrorHandlingTest : ASTImporterOptionSpecificTestBase {
+  ErrorHandlingTest() {
+Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
+ ASTContext &FromContext, FileManager &FromFileManager,
+ bool MinimalImport, ASTImporterLookupTable *LookupTable) {
+  return new ASTImporterWithFakeErrors(ToContext, ToFileManager,
+   FromContext, FromFileManager,
+   MinimalImport, LookupTable);
+};
+  }
+  // In this test we purposely report an error (UnsupportedConstruct) when
+  // importing the below stmt.
+  #define ERRONEOUSSTMT R"( asm(""); )"
+};
+
+// Check a case when no new AST node is created in the AST before encountering
+// the error.
+TEST_P(ErrorHandlingTest, ErrorHappensBeforeCreatingANewNode) {
+  TranslationUnitDecl *ToTU = getToTuDecl(
+  R"(
+  template 
+  class X {};
+  template <>
+  class X { int a; };
+  )",
+  Lang_CXX);
+  TranslationUnitDecl *FromTU = getTuDecl(
+  R"(
+  template 
+  class X {};
+  template <>
+  class X { double b; };
+  )",
+  Lang_CXX);
+  auto *FromSpec = FirstDeclMatcher().match(
+  FromTU, classTemplateSpecializationDecl(hasName("X")));
+  ClassTemplateSpecializationDecl *ImportedSpec = Import(FromSpec, Lang_CXX);
+  EXPECT_FALSE(ImportedSpec);
+
+  // The original Decl is kept, no new decl is created.
+  EXPECT_EQ(DeclCounter().match(
+ToTU, classTemplateSpecializationDecl(hasName("X"))),
+1u);
+
+  // But an error is set to the counterpart in the "from" context.
+  ASTImporter *Importer = findFromTU(FromSpec)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromSpec);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
+}
+
+// Check a case when a new AST node is created but not linked to the AST before
+// encountering the error.
+TEST_P(ErrorHandlingTest,
+   ErrorHappensAfterCreatingTheNodeButBeforeLinkingThatToTheAST) {
+  TranslationUnitDecl *FromTU = getTuDecl(
+  "void foo() { " ERRONEOUSSTMT " }",
+  Lang_CXX);
+  auto *FromFoo = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("foo")));
+
+  FunctionDecl *ImportedFoo = Import(FromFoo, Lang_CXX);
+  EXPECT_FALSE(ImportedFoo);
+
+  TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+  // Created, but not linked.
+  EXPECT_EQ(
+  DeclCounter().match(ToTU, functionDecl(hasName("foo"))),
+  0u);
+
+  ASTImporter *Importer = findFromTU(FromFoo)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFoo);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+}
+
+// Check a case when a new AST node is created and linked to the AST before
+// encountering the error. The error is set for the counterpart of the nodes in
+// the "from" context.
+TEST_P(ErrorHandlingTest, ErrorHappensAfterNodeIsCreatedAndLinked) {
+  TranslationUnitDecl *FromTU = getTuDecl(
+  R"(
+  void f();
+  void f() { )" ERRONEOUSSTMT R"( }
+  )",
+Lang_CXX);
+  auto *FromProto = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("f")));
+  auto *FromDef =
+  LastDeclMatcher().match(FromTU, functionDecl(hasName("f")));
+  FunctionDecl *ImportedProto = Import(FromProto, Lang_CXX);
+  EXPECT_FALSE(ImportedProto); // Could not import.
+  // However, we created two nodes in the AST. 1) the fwd de

[PATCH] D63603: [ASTImporter] Propagate error from ImportDeclContext

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 206018.
martong added a comment.

- Remove formatv b/c it can't handle braces in code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63603

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -4694,6 +4694,53 @@
   EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
 }
 
+// An error should be set for a class if we cannot import one member.
+TEST_P(ErrorHandlingTest, ErrorIsPropagatedFromMemberToClass) {
+  TranslationUnitDecl *FromTU = getTuDecl(
+  R"(
+  class X {
+void f() { )" ERRONEOUSSTMT R"( } // This member has the error
+  // during import.
+void ok();// The error should not prevent importing this.
+  };  // An error will be set for X too.
+  )",
+  Lang_CXX);
+  auto *FromX = FirstDeclMatcher().match(
+  FromTU, cxxRecordDecl(hasName("X")));
+  CXXRecordDecl *ImportedX = Import(FromX, Lang_CXX);
+
+  // An error is set for X.
+  EXPECT_FALSE(ImportedX);
+  ASTImporter *Importer = findFromTU(FromX)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+
+  // An error is set for f().
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, cxxMethodDecl(hasName("f")));
+  OptErr = Importer->getImportDeclErrorIfAny(FromF);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  // And any subsequent import should fail.
+  CXXMethodDecl *ImportedF = Import(FromF, Lang_CXX);
+  EXPECT_FALSE(ImportedF);
+
+  // There is no error set for ok().
+  auto *FromOK = FirstDeclMatcher().match(
+  FromTU, cxxMethodDecl(hasName("ok")));
+  OptErr = Importer->getImportDeclErrorIfAny(FromOK);
+  EXPECT_FALSE(OptErr);
+  // And we should be able to import.
+  CXXMethodDecl *ImportedOK = Import(FromOK, Lang_CXX);
+  EXPECT_TRUE(ImportedOK);
+
+  // Unwary clients may access X even if the error is set, so, at least make
+  // sure the class is set to be complete.
+  CXXRecordDecl *ToX = cast(ImportedOK->getDeclContext());
+  EXPECT_TRUE(ToX->isCompleteDefinition());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ErrorHandlingTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -1631,16 +1631,32 @@
 auto ToDCOrErr = Importer.ImportContext(FromDC);
 return ToDCOrErr.takeError();
   }
+
+  // We use strict error handling in case of records and enums, but not
+  // with e.g. namespaces.
+  //
+  // FIXME Clients of the ASTImporter should be able to choose an
+  // appropriate error handling strategy for their needs.  For instance,
+  // they may not want to mark an entire namespace as erroneous merely
+  // because there is an ODR error with two typedefs.  As another example,
+  // the client may allow EnumConstantDecls with same names but with
+  // different values in two distinct translation units.
+  bool AccumulateChildErrors = isa(FromDC);
+
+  Error ChildErrors = Error::success();
   llvm::SmallVector ImportedDecls;
   for (auto *From : FromDC->decls()) {
 ExpectedDecl ImportedOrErr = import(From);
-if (!ImportedOrErr)
-  // Ignore the error, continue with next Decl.
-  // FIXME: Handle this case somehow better.
-  consumeError(ImportedOrErr.takeError());
+if (!ImportedOrErr) {
+  if (AccumulateChildErrors)
+ChildErrors =
+joinErrors(std::move(ChildErrors), ImportedOrErr.takeError());
+  else
+consumeError(ImportedOrErr.takeError());
+}
   }
 
-  return Error::success();
+  return ChildErrors;
 }
 
 Error ASTNodeImporter::ImportDeclContext(
@@ -1697,7 +1713,15 @@
 return Error::success();
   }
 
-  To->startDefinition();
+  // Complete the definition even if error is returned.
+  // The RecordDecl may be already part of the AST so it is better to
+  // have it in complete state even if something is wrong with it.
+  struct DefinitionCompleter {
+RecordDecl *To;
+DefinitionCompleter(RecordDecl *To) : To(To) { To->startDefinition(); }
+~DefinitionCompleter() { To->completeDefinition(); }
+  };
+  DefinitionCompleter CompleterRAII(To);
 
   if (Error Err = setTypedefNameForAnonDecl(From, To, Importer))
 return Err;
@@ -1822,7 +1846,6 @@
 if (Error Err = ImportDeclContext(From, /*ForceImport=*/true))
   return Err;
 
-  To->completeDefinition();
   return Error::success();
 }
 
___

[PATCH] D62335: [OpenCL][PR41963] Add overloads of old atomics with generic pointer type in C++ mode

2019-06-21 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364071: [OpenCL][PR41963] Add generic addr space to old 
atomics in C++ mode (authored by stulova, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62335?vs=201165&id=206019#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62335

Files:
  cfe/trunk/lib/Headers/opencl-c.h
  cfe/trunk/test/Headers/opencl-c-header.cl

Index: cfe/trunk/test/Headers/opencl-c-header.cl
===
--- cfe/trunk/test/Headers/opencl-c-header.cl
+++ cfe/trunk/test/Headers/opencl-c-header.cl
@@ -73,6 +73,14 @@
 }
 #endif //__OPENCL_C_VERSION__
 
+#if defined(__OPENCL_CPP_VERSION__)
+// Test old atomic overloaded with generic addr space.
+void test_atomics(__generic volatile unsigned int* a) {
+  atomic_add(a, 1);
+}
+#endif
+
+
 // Verify that non-builtin cl_intel_planar_yuv extension is defined from
 // OpenCL 1.2 onwards.
 #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -13055,6 +13055,10 @@
 unsigned int __ovld atomic_add(volatile __global unsigned int *p, unsigned int val);
 int __ovld atomic_add(volatile __local int *p, int val);
 unsigned int __ovld atomic_add(volatile __local unsigned int *p, unsigned int val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_add(volatile int *p, int val);
+unsigned int __ovld atomic_add(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_add(volatile __global int *p, int val);
@@ -13081,6 +13085,10 @@
 unsigned int __ovld atomic_sub(volatile __global unsigned int *p, unsigned int val);
 int __ovld atomic_sub(volatile __local int *p, int val);
 unsigned int __ovld atomic_sub(volatile __local unsigned int *p, unsigned int val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_sub(volatile int *p, int val);
+unsigned int __ovld atomic_sub(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_sub(volatile __global int *p, int val);
@@ -13109,6 +13117,11 @@
 unsigned int __ovld atomic_xchg(volatile __local unsigned int *p, unsigned int val);
 float __ovld atomic_xchg(volatile __global float *p, float val);
 float __ovld atomic_xchg(volatile __local float *p, float val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_xchg(volatile int *p, int val);
+unsigned int __ovld atomic_xchg(volatile unsigned int *p, unsigned int val);
+float __ovld atomic_xchg(volatile float *p, float val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_xchg(volatile __global int *p, int val);
@@ -13136,6 +13149,10 @@
 unsigned int __ovld atomic_inc(volatile __global unsigned int *p);
 int __ovld atomic_inc(volatile __local int *p);
 unsigned int __ovld atomic_inc(volatile __local unsigned int *p);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_inc(volatile int *p);
+unsigned int __ovld atomic_inc(volatile unsigned int *p);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_inc(volatile __global int *p);
@@ -13163,6 +13180,10 @@
 unsigned int __ovld atomic_dec(volatile __global unsigned int *p);
 int __ovld atomic_dec(volatile __local int *p);
 unsigned int __ovld atomic_dec(volatile __local unsigned int *p);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_dec(volatile int *p);
+unsigned int __ovld atomic_dec(volatile unsigned int *p);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_dec(volatile __global int *p);
@@ -13191,6 +13212,10 @@
 unsigned int __ovld atomic_cmpxchg(volatile __global unsigned int *p, unsigned int cmp, unsigned int val);
 int __ovld atomic_cmpxchg(volatile __local int *p, int cmp, int val);
 unsigned int __ovld atomic_cmpxchg(volatile __local unsigned int *p, unsigned int cmp, unsigned int val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_cmpxchg(volatile int *p, int cmp, int val);
+unsigned int __ovld atomic_cmpxchg(volatile unsigned int *p, unsigned int cmp, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_cmpxchg(volatile __global int *p, int cmp, int val);
@@ -13219,6 +13244,10 @@
 unsigned int __ovld atomic_min(volatile __global unsigned int *p, unsigned int val);
 int __ovld atomic_min(volatile __local int *p, int val);
 unsigned int __ovld atomic_min(volatile __local unsigned int *p, unsigned int val);
+#ifdef __OPENCL_CPP_VERSION__
+int __ovld atomic_min(volatile int *p, int val);
+unsigned int __ovld atomic_min(volatile unsigned int *p, unsigned int val);
+#endif
 
 #if defined(cl_khr_global_int32_extended_atom

[PATCH] D63649: AMDGPU: Fix target builtins for gfx10

2019-06-21 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec accepted this revision.
rampitec added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D63649



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


[PATCH] D62373: [ASTImporter] Store import errors for Decls

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 206020.
martong added a comment.

- Remove unused include and using


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62373

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/test/ASTMerge/class-template-partial-spec/test.cpp
  clang/unittests/AST/ASTImporterFixtures.cpp
  clang/unittests/AST/ASTImporterFixtures.h
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -4574,6 +4574,127 @@
   EXPECT_EQ(Imported->getPreviousDecl(), Friend);
 }
 
+struct ASTImporterWithFakeErrors : ASTImporter {
+  using ASTImporter::ASTImporter;
+  bool returnWithErrorInTest() override { return true; }
+};
+
+struct ErrorHandlingTest : ASTImporterOptionSpecificTestBase {
+  ErrorHandlingTest() {
+Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
+ ASTContext &FromContext, FileManager &FromFileManager,
+ bool MinimalImport, ASTImporterLookupTable *LookupTable) {
+  return new ASTImporterWithFakeErrors(ToContext, ToFileManager,
+   FromContext, FromFileManager,
+   MinimalImport, LookupTable);
+};
+  }
+  // In this test we purposely report an error (UnsupportedConstruct) when
+  // importing the below stmt.
+  #define ERRONEOUSSTMT R"( asm(""); )"
+};
+
+// Check a case when no new AST node is created in the AST before encountering
+// the error.
+TEST_P(ErrorHandlingTest, ErrorHappensBeforeCreatingANewNode) {
+  TranslationUnitDecl *ToTU = getToTuDecl(
+  R"(
+  template 
+  class X {};
+  template <>
+  class X { int a; };
+  )",
+  Lang_CXX);
+  TranslationUnitDecl *FromTU = getTuDecl(
+  R"(
+  template 
+  class X {};
+  template <>
+  class X { double b; };
+  )",
+  Lang_CXX);
+  auto *FromSpec = FirstDeclMatcher().match(
+  FromTU, classTemplateSpecializationDecl(hasName("X")));
+  ClassTemplateSpecializationDecl *ImportedSpec = Import(FromSpec, Lang_CXX);
+  EXPECT_FALSE(ImportedSpec);
+
+  // The original Decl is kept, no new decl is created.
+  EXPECT_EQ(DeclCounter().match(
+ToTU, classTemplateSpecializationDecl(hasName("X"))),
+1u);
+
+  // But an error is set to the counterpart in the "from" context.
+  ASTImporter *Importer = findFromTU(FromSpec)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromSpec);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
+}
+
+// Check a case when a new AST node is created but not linked to the AST before
+// encountering the error.
+TEST_P(ErrorHandlingTest,
+   ErrorHappensAfterCreatingTheNodeButBeforeLinkingThatToTheAST) {
+  TranslationUnitDecl *FromTU = getTuDecl(
+  "void foo() { " ERRONEOUSSTMT " }",
+  Lang_CXX);
+  auto *FromFoo = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("foo")));
+
+  FunctionDecl *ImportedFoo = Import(FromFoo, Lang_CXX);
+  EXPECT_FALSE(ImportedFoo);
+
+  TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+  // Created, but not linked.
+  EXPECT_EQ(
+  DeclCounter().match(ToTU, functionDecl(hasName("foo"))),
+  0u);
+
+  ASTImporter *Importer = findFromTU(FromFoo)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFoo);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+}
+
+// Check a case when a new AST node is created and linked to the AST before
+// encountering the error. The error is set for the counterpart of the nodes in
+// the "from" context.
+TEST_P(ErrorHandlingTest, ErrorHappensAfterNodeIsCreatedAndLinked) {
+  TranslationUnitDecl *FromTU = getTuDecl(
+  R"(
+  void f();
+  void f() { )" ERRONEOUSSTMT R"( }
+  )",
+Lang_CXX);
+  auto *FromProto = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("f")));
+  auto *FromDef =
+  LastDeclMatcher().match(FromTU, functionDecl(hasName("f")));
+  FunctionDecl *ImportedProto = Import(FromProto, Lang_CXX);
+  EXPECT_FALSE(ImportedProto); // Could not import.
+  // However, we created two nodes in the AST. 1) the fwd decl 2) the
+  // definition. The definition is not added to its DC, but the fwd decl is
+  // there.
+  TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+  EXPECT_EQ(DeclCounter().match(ToTU, functionDecl(hasName("f"))),
+1u);
+  // Match the fwd decl.
+  auto *ToProto =
+  FirstDeclMatcher().match(ToTU, functionDecl(hasName("f")));
+  EXPECT_TRUE(ToProto);
+  // An error is set to the counterpart in the "from" context both for the fwd
+  // decl and the defini

[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread JF Bastien via Phabricator via cfe-commits
jfb added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:508
 def Varargs : DiagGroup<"varargs">;
+def XorUsedAsPow : DiagGroup<"xor-used-as-pow">;
 

Does this match the naming that GCC ended up with?



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:3309
+def warn_xor_used_as_pow_shift_count_overflow : Warning<
+  "result of '%0' is %1; did you mean '%2', but shift count >= width of type">,
+  InGroup;

This is still a bad diagnostic, I'd rather see it fixed.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

Doesn't this match any expression that contains `xor`? Put another way, I don't 
see `"xor"` used anywhere else under clang, what's usually done?



Comment at: lib/Sema/SemaExpr.cpp:10951
+  // Do not diagnose binary literals.
+  if (ExprStr.find("0b") != llvm::StringRef::npos)
+return;

This ignores `0B`.



Comment at: lib/Sema/SemaExpr.cpp:10954
+  // Do not diagnose hexadecimal literals.
+  if (ExprStr.find("0x") != llvm::StringRef::npos)
+return;

This ignores `0X`.



Comment at: lib/Sema/SemaExpr.cpp:10961
+return;
+
+  if (LeftSideValue == 2 && RightSideIntValue >= 0) {

The above seems to mishandle user-defined literals. Unless the UDL contains 
`0x` or `0b` in them. I'd like to see this tested.


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

https://reviews.llvm.org/D63423



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


[PATCH] D62375: [ASTImporter] Mark erroneous nodes in from ctx

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 206022.
martong added a comment.

- Add test ErrorPropagatesThroughImportCycles
- Change existing test to new behaviour


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62375

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -358,6 +358,106 @@
   EXPECT_EQ(0U, count);
 }
 
+struct ImportPath : ASTImporterOptionSpecificTestBase {
+  Decl *FromTU;
+  FunctionDecl *D0, *D1, *D2;
+  ImportPath() {
+FromTU = getTuDecl("void f(); void f(); void f();", Lang_CXX);
+auto Pattern = functionDecl(hasName("f"));
+D0 = FirstDeclMatcher().match(FromTU, Pattern);
+D2 = LastDeclMatcher().match(FromTU, Pattern);
+D1 = D2->getPreviousDecl();
+  }
+};
+
+TEST_P(ImportPath, Push) {
+  ASTImporter::ImportPathTy path;
+  path.push(D0);
+  EXPECT_FALSE(path.hasCycleAtBack());
+}
+
+TEST_P(ImportPath, SmallCycle) {
+  ASTImporter::ImportPathTy path;
+  path.push(D0);
+  path.push(D0);
+  EXPECT_TRUE(path.hasCycleAtBack());
+  path.pop();
+  EXPECT_FALSE(path.hasCycleAtBack());
+  path.push(D0);
+  EXPECT_TRUE(path.hasCycleAtBack());
+}
+
+TEST_P(ImportPath, GetSmallCycle) {
+  ASTImporter::ImportPathTy path;
+  path.push(D0);
+  path.push(D0);
+  EXPECT_TRUE(path.hasCycleAtBack());
+  std::array Res;
+  int i = 0;
+  for (Decl *Di : path.getCycleAtBack()) {
+Res[i++] = Di;
+  }
+  ASSERT_EQ(i, 2);
+  EXPECT_EQ(Res[0], D0);
+  EXPECT_EQ(Res[1], D0);
+}
+
+TEST_P(ImportPath, GetCycle) {
+  ASTImporter::ImportPathTy path;
+  path.push(D0);
+  path.push(D1);
+  path.push(D2);
+  path.push(D0);
+  EXPECT_TRUE(path.hasCycleAtBack());
+  std::array Res;
+  int i = 0;
+  for (Decl *Di : path.getCycleAtBack()) {
+Res[i++] = Di;
+  }
+  ASSERT_EQ(i, 4);
+  EXPECT_EQ(Res[0], D0);
+  EXPECT_EQ(Res[1], D2);
+  EXPECT_EQ(Res[2], D1);
+  EXPECT_EQ(Res[3], D0);
+}
+
+TEST_P(ImportPath, CycleAfterCycle) {
+  ASTImporter::ImportPathTy path;
+  path.push(D0);
+  path.push(D1);
+  path.push(D0);
+  path.push(D1);
+  path.push(D2);
+  path.push(D0);
+  EXPECT_TRUE(path.hasCycleAtBack());
+  std::array Res;
+  int i = 0;
+  for (Decl *Di : path.getCycleAtBack()) {
+Res[i++] = Di;
+  }
+  ASSERT_EQ(i, 4);
+  EXPECT_EQ(Res[0], D0);
+  EXPECT_EQ(Res[1], D2);
+  EXPECT_EQ(Res[2], D1);
+  EXPECT_EQ(Res[3], D0);
+
+  path.pop();
+  path.pop();
+  path.pop();
+  EXPECT_TRUE(path.hasCycleAtBack());
+  i = 0;
+  for (Decl *Di : path.getCycleAtBack()) {
+Res[i++] = Di;
+  }
+  ASSERT_EQ(i, 3);
+  EXPECT_EQ(Res[0], D0);
+  EXPECT_EQ(Res[1], D1);
+  EXPECT_EQ(Res[2], D0);
+
+  path.pop();
+  EXPECT_FALSE(path.hasCycleAtBack());
+}
+
 TEST_P(ImportExpr, ImportStringLiteral) {
   MatchVerifier Verifier;
   testImport(
@@ -4501,12 +4601,6 @@
   EXPECT_EQ(*Res.begin(), A);
 }
 
-INSTANTIATE_TEST_CASE_P(ParameterizedTests, DeclContextTest,
-::testing::Values(ArgVector()), );
-
-INSTANTIATE_TEST_CASE_P(
-ParameterizedTests, CanonicalRedeclChain,
-::testing::Values(ArgVector()),);
 
 // FIXME This test is disabled currently, upcoming patches will make it
 // possible to enable.
@@ -4724,27 +4818,116 @@
   CXXMethodDecl *ImportedF = Import(FromF, Lang_CXX);
   EXPECT_FALSE(ImportedF);
 
-  // There is no error set for ok().
+  // There is an error set for the other member too.
   auto *FromOK = FirstDeclMatcher().match(
   FromTU, cxxMethodDecl(hasName("ok")));
   OptErr = Importer->getImportDeclErrorIfAny(FromOK);
-  EXPECT_FALSE(OptErr);
-  // And we should be able to import.
+  EXPECT_TRUE(OptErr);
+  // Cannot import the other member.
   CXXMethodDecl *ImportedOK = Import(FromOK, Lang_CXX);
-  EXPECT_TRUE(ImportedOK);
+  EXPECT_FALSE(ImportedOK);
+}
 
-  // Unwary clients may access X even if the error is set, so, at least make
-  // sure the class is set to be complete.
-  CXXRecordDecl *ToX = cast(ImportedOK->getDeclContext());
-  EXPECT_TRUE(ToX->isCompleteDefinition());
+// Check that an error propagates to the dependent AST nodes.
+// In the below code it means that an error in X should propagate to A.
+// And even to F since the containing A is erroneous.
+// And to all AST nodes which we visit during the import process which finally
+// ends up in a failure (in the error() function).
+TEST_P(ErrorHandlingTest, ErrorPropagatesThroughImportCycles) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  namespace NS {
+class A {
+  template  class F {};
+  class X {
+template  friend class F;
+void error() { )" ERRONEOUSSTMT R"( }
+  };
+};
+
+class B {};
+  } // NS
+  )",
+  Lang_CXX, "input0.cc");
+
+  auto *FromFRD = Firs

[PATCH] D62375: [ASTImporter] Mark erroneous nodes in from ctx

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Alexei,

Thank you for the review, I have added a test which demonstrates the changes.
By tracking the import paths and cycles we implement a very strict error 
handling mechanism, but this seems to be the way to avoid reaching any faulty 
AST nodes for the ASTImporter clients.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62375



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10950
+
+  // Do not diagnose binary literals.
+  if (ExprStr.find("0b") != llvm::StringRef::npos)

I would rather see this whole section as a three-liner:

// Do not diagnose binary, octal, or hexadecimal literals.
if (StringRef(LHSStr).startswith("0") || StringRef(RHSStr).startswith("0"))
return;




Comment at: lib/Sema/SemaExpr.cpp:10963
+  if (LeftSideValue == 2 && RightSideIntValue >= 0) {
+std::string SuggestedExpr = "1<<" + RHSStr;
+bool Overflow = false;

Here and on line 10971, I suggest whitespace around the `<<` (in the suggested 
expression).



Comment at: lib/Sema/SemaExpr.cpp:10983
+
+S.Diag(Loc, diag::note_xor_used_as_pow_silence) << ("0x2 ^ " + RHSStr);
+  } else if (LeftSideValue == 10) {

Do you currently warn on, let's say, `2uLL ^ 7`? and if so, do we care that the 
suggested expression `0x2 ^ 7` has a different type?  I imagine the answer to 
"do we care" is "no," but I thought I should ask.


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked 3 inline comments as done.
xbolva00 added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:508
 def Varargs : DiagGroup<"varargs">;
+def XorUsedAsPow : DiagGroup<"xor-used-as-pow">;
 

jfb wrote:
> Does this match the naming that GCC ended up with?
No, they have no progress yet.  GCC should not block our progress here..



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:3309
+def warn_xor_used_as_pow_shift_count_overflow : Warning<
+  "result of '%0' is %1; did you mean '%2', but shift count >= width of type">,
+  InGroup;

jfb wrote:
> This is still a bad diagnostic, I'd rather see it fixed.
Why so? Can you propose wording here?

We provide a fixit for it, e.g. 1LL<<32..



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

jfb wrote:
> Doesn't this match any expression that contains `xor`? Put another way, I 
> don't see `"xor"` used anywhere else under clang, what's usually done?
Yes, but since xor is keyword in C++, I think this is safe.


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10983
+
+S.Diag(Loc, diag::note_xor_used_as_pow_silence) << ("0x2 ^ " + RHSStr);
+  } else if (LeftSideValue == 10) {

Quuxplusone wrote:
> Do you currently warn on, let's say, `2uLL ^ 7`? and if so, do we care that 
> the suggested expression `0x2 ^ 7` has a different type?  I imagine the 
> answer to "do we care" is "no," but I thought I should ask.
We check if bidwith is same.. Bail out if not.


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

https://reviews.llvm.org/D63423



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


[PATCH] D62376: [ASTImporter] Mark erroneous nodes in shared st

2019-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Alexei,

Thanks for the review!
I have provided test cases for the 3 previous patches on which this one depends 
on. I will provide additional tests next week for this one, and of course will 
address the other comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62376



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

xbolva00 wrote:
> jfb wrote:
> > Doesn't this match any expression that contains `xor`? Put another way, I 
> > don't see `"xor"` used anywhere else under clang, what's usually done?
> Yes, but since xor is keyword in C++, I think this is safe.
I believe JF is worried about expressions like `constexpr int flexor_exponent = 
3; return 10 ^ flexor_exponent;`. That expression contains the substring 
`"xor"` but does not use the `xor` keyword. Which reminds me, can you add some 
test cases showing what behavior you expect for operands that are not integer 
literals but still compile-time `const`, or `constexpr`, or template arguments?


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

Quuxplusone wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > Doesn't this match any expression that contains `xor`? Put another way, I 
> > > don't see `"xor"` used anywhere else under clang, what's usually done?
> > Yes, but since xor is keyword in C++, I think this is safe.
> I believe JF is worried about expressions like `constexpr int flexor_exponent 
> = 3; return 10 ^ flexor_exponent;`. That expression contains the substring 
> `"xor"` but does not use the `xor` keyword. Which reminds me, can you add 
> some test cases showing what behavior you expect for operands that are not 
> integer literals but still compile-time `const`, or `constexpr`, or template 
> arguments?
Ah, I will change it to “ xor “.


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread JF Bastien via Phabricator via cfe-commits
jfb added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

xbolva00 wrote:
> Quuxplusone wrote:
> > xbolva00 wrote:
> > > jfb wrote:
> > > > Doesn't this match any expression that contains `xor`? Put another way, 
> > > > I don't see `"xor"` used anywhere else under clang, what's usually done?
> > > Yes, but since xor is keyword in C++, I think this is safe.
> > I believe JF is worried about expressions like `constexpr int 
> > flexor_exponent = 3; return 10 ^ flexor_exponent;`. That expression 
> > contains the substring `"xor"` but does not use the `xor` keyword. Which 
> > reminds me, can you add some test cases showing what behavior you expect 
> > for operands that are not integer literals but still compile-time `const`, 
> > or `constexpr`, or template arguments?
> Ah, I will change it to “ xor “.
Spaces aren't the only valid whitespace character :)

```
2 xor
   31
```


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

https://reviews.llvm.org/D63423



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


[PATCH] D63180: [clang-doc] Adds HTML generator

2019-06-21 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett added inline comments.



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:87
+std::string CloseTag = I.SelfClosing ? "/>" : ">";
+writeLine("<" + I.Name + Attrs.str() + CloseTag, OS);
+  } else if (I.Kind == "HTMLEndTagComment") {

You shouldn't be using writeLine here, since it wraps the tag in an extra  
element (which is okay for all the other pieces, but is weird on a specified 
HTML element.



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:89
+  } else if (I.Kind == "HTMLEndTagComment") {
+writeLine("", OS);
+  } else if (I.Kind == "TextComment") {

Same as above



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:110
+for (const auto &N : I.Members)
+  Members << "| " << N << " |\n";
+  writeLine(Members.str(), OS);

The pipes don't mean anything in HTML, so you can remove them.



Comment at: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp:214-218
+  HTML->Children.back()->Kind = "HTMLStartTagComment";
+  HTML->Children.back()->Name = "li";
+  HTML->Children.emplace_back(llvm::make_unique());
+  HTML->Children.back()->Kind = "TextComment";
+  HTML->Children.back()->Text = " Testing.";

For the sake of vaguely valid HTML in the test output, it'd be nice if we had 
an end tag for the  element as well.



Comment at: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp:287
+Defined at line 10 of test.cpp
+
+ Brief description.

Should the whole comment be wrapped in a  element?


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

https://reviews.llvm.org/D63180



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

jfb wrote:
> xbolva00 wrote:
> > Quuxplusone wrote:
> > > xbolva00 wrote:
> > > > jfb wrote:
> > > > > Doesn't this match any expression that contains `xor`? Put another 
> > > > > way, I don't see `"xor"` used anywhere else under clang, what's 
> > > > > usually done?
> > > > Yes, but since xor is keyword in C++, I think this is safe.
> > > I believe JF is worried about expressions like `constexpr int 
> > > flexor_exponent = 3; return 10 ^ flexor_exponent;`. That expression 
> > > contains the substring `"xor"` but does not use the `xor` keyword. Which 
> > > reminds me, can you add some test cases showing what behavior you expect 
> > > for operands that are not integer literals but still compile-time 
> > > `const`, or `constexpr`, or template arguments?
> > Ah, I will change it to “ xor “.
> Spaces aren't the only valid whitespace character :)
> 
> ```
> 2 xor
>31
> ```
I will rework it to chech only XOR op, not the while expr.


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

https://reviews.llvm.org/D63423



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


r364078 - Ensure that top-level QualType objects also have a "kind" field when dumping the AST to JSON.

2019-06-21 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Fri Jun 21 10:14:25 2019
New Revision: 364078

URL: http://llvm.org/viewvc/llvm-project?rev=364078&view=rev
Log:
Ensure that top-level QualType objects also have a "kind" field when dumping 
the AST to JSON.

Modified:
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/test/AST/ast-dump-types-json.cpp

Modified: cfe/trunk/lib/AST/JSONNodeDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/JSONNodeDumper.cpp?rev=364078&r1=364077&r2=364078&view=diff
==
--- cfe/trunk/lib/AST/JSONNodeDumper.cpp (original)
+++ cfe/trunk/lib/AST/JSONNodeDumper.cpp Fri Jun 21 10:14:25 2019
@@ -78,6 +78,7 @@ void JSONNodeDumper::Visit(const Type *T
 
 void JSONNodeDumper::Visit(QualType T) {
   JOS.attribute("id", createPointerRepresentation(T.getAsOpaquePtr()));
+  JOS.attribute("kind", "QualType");
   JOS.attribute("type", createQualType(T));
   JOS.attribute("qualifiers", T.split().Quals.getAsString());
 }

Modified: cfe/trunk/test/AST/ast-dump-types-json.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-types-json.cpp?rev=364078&r1=364077&r2=364078&view=diff
==
--- cfe/trunk/test/AST/ast-dump-types-json.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-types-json.cpp Fri Jun 21 10:14:25 2019
@@ -18,6 +18,8 @@ typedef void (CDECL *TestMacroQualifiedT
 typedef void (T::* TestMemberFunctionPointerType)();
 typedef int T::*TestMemberDataPointerType;
 
+typedef int TestQualTypePrinting(const char* c);
+
 // NOTE: CHECK lines have been autogenerated by gen_ast_dump_json_test.py
 
 
@@ -354,5 +356,75 @@ typedef int T::*TestMemberDataPointerTyp
 // CHECK-NEXT: }
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
+// CHECK-NEXT:  ]
+// CHECK-NEXT: }
+
+
+// CHECK:  "kind": "TypedefDecl",
+// CHECK-NEXT:  "loc": {
+// CHECK-NEXT:   "col": 13,
+// CHECK-NEXT:   "file": "{{.*}}",
+// CHECK-NEXT:   "line": 21
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "range": {
+// CHECK-NEXT:   "begin": {
+// CHECK-NEXT:"col": 1,
+// CHECK-NEXT:"file": "{{.*}}",
+// CHECK-NEXT:"line": 21
+// CHECK-NEXT:   },
+// CHECK-NEXT:   "end": {
+// CHECK-NEXT:"col": 47,
+// CHECK-NEXT:"file": "{{.*}}",
+// CHECK-NEXT:"line": 21
+// CHECK-NEXT:   }
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "name": "TestQualTypePrinting",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "qualType": "int (const char *)"
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "inner": [
+// CHECK-NEXT:   {
+// CHECK-NEXT:"id": "0x{{.*}}",
+// CHECK-NEXT:"kind": "FunctionProtoType",
+// CHECK-NEXT:"type": {
+// CHECK-NEXT: "qualType": "int (const char *)"
+// CHECK-NEXT:},
+// CHECK-NEXT:"cc": "cdecl",
+// CHECK-NEXT:"inner": [
+// CHECK-NEXT: {
+// CHECK-NEXT:  "id": "0x{{.*}}",
+// CHECK-NEXT:  "kind": "BuiltinType",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "qualType": "int"
+// CHECK-NEXT:  }
+// CHECK-NEXT: },
+// CHECK-NEXT: {
+// CHECK-NEXT:  "id": "0x{{.*}}",
+// CHECK-NEXT:  "kind": "PointerType",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "qualType": "const char *"
+// CHECK-NEXT:  },
+// CHECK-NEXT:  "inner": [
+// CHECK-NEXT:   {
+// CHECK-NEXT:"id": "0x{{.*}}",
+// CHECK-NEXT:"kind": "QualType",
+// CHECK-NEXT:"type": {
+// CHECK-NEXT: "qualType": "const char"
+// CHECK-NEXT:},
+// CHECK-NEXT:"qualifiers": "const",
+// CHECK-NEXT:"inner": [
+// CHECK-NEXT: {
+// CHECK-NEXT:  "id": "0x{{.*}}",
+// CHECK-NEXT:  "kind": "BuiltinType",
+// CHECK-NEXT:  "type": {
+// CHECK-NEXT:   "qualType": "char"
+// CHECK-NEXT:  }
+// CHECK-NEXT: }
+// CHECK-NEXT:]
+// CHECK-NEXT:   }
+// CHECK-NEXT:  ]
+// CHECK-NEXT: }
+// CHECK-NEXT:]
+// CHECK-NEXT:   }
 // CHECK-NEXT:  ]
 // CHECK-NEXT: }


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


r364080 - [OPENMP]Fix PR42068: Vla type is not captured.

2019-06-21 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Fri Jun 21 10:28:41 2019
New Revision: 364080

URL: http://llvm.org/viewvc/llvm-project?rev=364080&view=rev
Log:
[OPENMP]Fix PR42068: Vla type is not captured.

If the variably modified type is declared outside of the captured region
and then used in the cast expression along with array subscript
expression, the type is not captured and it leads to the compiler crash.

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/OpenMP/parallel_codegen.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=364080&r1=364079&r2=364080&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Jun 21 10:28:41 2019
@@ -4737,6 +4737,33 @@ Sema::CreateBuiltinArraySubscriptExpr(Ex
   assert(VK == VK_RValue || LangOpts.CPlusPlus ||
  !ResultType.isCForbiddenLValueType());
 
+  if (LHSExp->IgnoreParenImpCasts()->getType()->isVariablyModifiedType() &&
+  FunctionScopes.size() > 1) {
+if (auto *TT =
+LHSExp->IgnoreParenImpCasts()->getType()->getAs()) {
+  for (auto I = FunctionScopes.rbegin(),
+E = std::prev(FunctionScopes.rend());
+   I != E; ++I) {
+auto *CSI = dyn_cast(*I);
+if (CSI == nullptr)
+  break;
+DeclContext *DC = nullptr;
+if (auto *LSI = dyn_cast(CSI))
+  DC = LSI->CallOperator;
+else if (auto *CRSI = dyn_cast(CSI))
+  DC = CRSI->TheCapturedDecl;
+else if (auto *BSI = dyn_cast(CSI))
+  DC = BSI->TheDecl;
+if (DC) {
+  if (DC->containsDecl(TT->getDecl()))
+break;
+  captureVariablyModifiedType(
+  Context, LHSExp->IgnoreParenImpCasts()->getType(), CSI);
+}
+  }
+}
+  }
+
   return new (Context)
   ArraySubscriptExpr(LHSExp, RHSExp, ResultType, VK, OK, RLoc);
 }

Modified: cfe/trunk/test/OpenMP/parallel_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_codegen.cpp?rev=364080&r1=364079&r2=364080&view=diff
==
--- cfe/trunk/test/OpenMP/parallel_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_codegen.cpp Fri Jun 21 10:28:41 2019
@@ -15,16 +15,20 @@
 // CHECK-DEBUG-DAG: %struct.ident_t = type { i32, i32, i32, i32, i8* }
 // CHECK-DEBUG-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] 
c";unknown;unknown;0;0;;\00"
 // CHECK-DEBUG-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr global 
%struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x 
i8], [23 x i8]* [[STR]], i32 0, i32 0) }
-// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;main;[[@LINE+15]];1;;\00"
-// CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+7]];1;;\00"
+// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;main;[[@LINE+19]];1;;\00"
+// CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x i8] 
c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+8]];1;;\00"
 
 template 
 void foo(T argc) {}
 
 template 
 int tmain(T argc) {
+  typedef double (*chunk_t)[argc[0][0]];
 #pragma omp parallel
+  {
   foo(argc);
+  chunk_t var;(void)var[0][0];
+  }
   return 0;
 }
 
@@ -90,7 +94,7 @@ int main (int argc, char **argv) {
 
 // CHECK:   define linkonce_odr {{[a-z\_\b]*[ ]?i32}} [[TMAIN]](i8** %argc)
 // CHECK:   store i8** %argc, i8*** [[ARGC_ADDR:%.+]],
-// CHECK-NEXT:  call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, 
...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 1, void 
(i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***)* [[OMP_OUTLINED:@.+]] to 
void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]])
+// CHECK:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, 
...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 2, void 
(i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i64)* [[OMP_OUTLINED:@.+]] 
to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i64 %{{.+}})
 // CHECK-NEXT:  ret i32 0
 // CHECK-NEXT:  }
 // CHECK-DEBUG:   define linkonce_odr i32 [[TMAIN]](i8** %argc)
@@ -101,23 +105,23 @@ int main (int argc, char **argv) {
 // CHECK-DEBUG-NEXT:  store i8** %argc, i8*** [[ARGC_ADDR:%.+]],
 // CHECK-DEBUG:  [[KMPC_LOC_PSOURCE_REF:%.+]] = getelementptr inbounds 
%struct.ident_t, %struct.ident_t* [[LOC_2_ADDR]], i32 0, i32 4
 // CHECK-DEBUG-NEXT:  store i8* getelementptr inbounds ([{{.+}} x i8], [{{.+}} 
x i8]* [[LOC2]], i32 0, i32 0), i8** [[KMPC_LOC_PSOURCE_REF]]
-// CHECK-DEBUG-NEXT:  call void (%struct.ident_t*, i32, void (i32*, i32*, 
...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[LOC_2_ADDR]], i32 1, void 
(i32*, i32*, ...)* bitc

[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

xbolva00 wrote:
> jfb wrote:
> > xbolva00 wrote:
> > > Quuxplusone wrote:
> > > > xbolva00 wrote:
> > > > > jfb wrote:
> > > > > > Doesn't this match any expression that contains `xor`? Put another 
> > > > > > way, I don't see `"xor"` used anywhere else under clang, what's 
> > > > > > usually done?
> > > > > Yes, but since xor is keyword in C++, I think this is safe.
> > > > I believe JF is worried about expressions like `constexpr int 
> > > > flexor_exponent = 3; return 10 ^ flexor_exponent;`. That expression 
> > > > contains the substring `"xor"` but does not use the `xor` keyword. 
> > > > Which reminds me, can you add some test cases showing what behavior you 
> > > > expect for operands that are not integer literals but still 
> > > > compile-time `const`, or `constexpr`, or template arguments?
> > > Ah, I will change it to “ xor “.
> > Spaces aren't the only valid whitespace character :)
> > 
> > ```
> > 2 xor
> >31
> > ```
> I will rework it to chech only XOR op, not the while expr.
Well, 10 ^ flexor .. 

 We cannot reach xor check, flexor is not a integer literal. So I will rework 
nothing here.


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

xbolva00 wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > xbolva00 wrote:
> > > > Quuxplusone wrote:
> > > > > xbolva00 wrote:
> > > > > > jfb wrote:
> > > > > > > Doesn't this match any expression that contains `xor`? Put 
> > > > > > > another way, I don't see `"xor"` used anywhere else under clang, 
> > > > > > > what's usually done?
> > > > > > Yes, but since xor is keyword in C++, I think this is safe.
> > > > > I believe JF is worried about expressions like `constexpr int 
> > > > > flexor_exponent = 3; return 10 ^ flexor_exponent;`. That expression 
> > > > > contains the substring `"xor"` but does not use the `xor` keyword. 
> > > > > Which reminds me, can you add some test cases showing what behavior 
> > > > > you expect for operands that are not integer literals but still 
> > > > > compile-time `const`, or `constexpr`, or template arguments?
> > > > Ah, I will change it to “ xor “.
> > > Spaces aren't the only valid whitespace character :)
> > > 
> > > ```
> > > 2 xor
> > >31
> > > ```
> > I will rework it to chech only XOR op, not the while expr.
> Well, 10 ^ flexor .. 
> 
>  We cannot reach xor check, flexor is not a integer literal. So I will rework 
> nothing here.
```
#define flexor 7
```
Now `flexor` is an integer literal. (A test case for this would be beneficial.)


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

https://reviews.llvm.org/D63423



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-06-21 Thread JF Bastien via Phabricator via cfe-commits
jfb added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10929
+// Do not diagnose if xor keyword is used.
+if (ExprStr.find("xor") != llvm::StringRef::npos)
+  return;

aaron.ballman wrote:
> xbolva00 wrote:
> > xbolva00 wrote:
> > > jfb wrote:
> > > > xbolva00 wrote:
> > > > > Quuxplusone wrote:
> > > > > > xbolva00 wrote:
> > > > > > > jfb wrote:
> > > > > > > > Doesn't this match any expression that contains `xor`? Put 
> > > > > > > > another way, I don't see `"xor"` used anywhere else under 
> > > > > > > > clang, what's usually done?
> > > > > > > Yes, but since xor is keyword in C++, I think this is safe.
> > > > > > I believe JF is worried about expressions like `constexpr int 
> > > > > > flexor_exponent = 3; return 10 ^ flexor_exponent;`. That expression 
> > > > > > contains the substring `"xor"` but does not use the `xor` keyword. 
> > > > > > Which reminds me, can you add some test cases showing what behavior 
> > > > > > you expect for operands that are not integer literals but still 
> > > > > > compile-time `const`, or `constexpr`, or template arguments?
> > > > > Ah, I will change it to “ xor “.
> > > > Spaces aren't the only valid whitespace character :)
> > > > 
> > > > ```
> > > > 2 xor
> > > >31
> > > > ```
> > > I will rework it to chech only XOR op, not the while expr.
> > Well, 10 ^ flexor .. 
> > 
> >  We cannot reach xor check, flexor is not a integer literal. So I will 
> > rework nothing here.
> ```
> #define flexor 7
> ```
> Now `flexor` is an integer literal. (A test case for this would be 
> beneficial.)
Also, as I've said above:
```
constexpr long long operator"" _xor(unsigned long long v)
{ return v; }
auto i = 10 ^ 5_xor;
```



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

https://reviews.llvm.org/D63423



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


r364081 - Fix ARM buildbot.

2019-06-21 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Fri Jun 21 10:41:20 2019
New Revision: 364081

URL: http://llvm.org/viewvc/llvm-project?rev=364081&view=rev
Log:
Fix ARM buildbot.

Modified:
cfe/trunk/test/CodeGenCXX/tail-padding.cpp

Modified: cfe/trunk/test/CodeGenCXX/tail-padding.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/tail-padding.cpp?rev=364081&r1=364080&r2=364081&view=diff
==
--- cfe/trunk/test/CodeGenCXX/tail-padding.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/tail-padding.cpp Fri Jun 21 10:41:20 2019
@@ -44,21 +44,21 @@ namespace NoUniqueAddr {
   static_assert(sizeof(E) == sizeof(void*) + 8 + alignof(void*));
 
   // CHECK: define {{.*}} @_ZN12NoUniqueAddr1CC1EOS0_
-  // CHECK: call void @_ZN12NoUniqueAddr1AC2ERKS0_(
+  // CHECK: call {{.*}} @_ZN12NoUniqueAddr1AC2ERKS0_(
   // CHECK: store i32 {{.*}} @_ZTVN12NoUniqueAddr1CE
   // Copy the full size of B.
   // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}, i8* {{.*}}, i64 
8, i1 false)
   C f(C c) { return c; }
 
   // CHECK: define {{.*}} @_ZN12NoUniqueAddr1DC1EOS0_
-  // CHECK: call void @_ZN12NoUniqueAddr1AC2ERKS0_(
+  // CHECK: call {{.*}} @_ZN12NoUniqueAddr1AC2ERKS0_(
   // CHECK: store i32 {{.*}} @_ZTVN12NoUniqueAddr1DE
   // Copy just the data size of B, to avoid overwriting the A base class.
   // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}, i8* {{.*}}, i64 
7, i1 false)
   D f(D d) { return d; }
 
   // CHECK: define {{.*}} @_ZN12NoUniqueAddr1EC1EOS0_
-  // CHECK: call void @_ZN12NoUniqueAddr1AC2ERKS0_(
+  // CHECK: call {{.*}} @_ZN12NoUniqueAddr1AC2ERKS0_(
   // CHECK: store i32 {{.*}} @_ZTVN12NoUniqueAddr1EE
   // We can copy the full size of B here. (As it happens, we fold the copy of 
'x' into
   // this memcpy, so we're copying 8 bytes either way.)
@@ -71,7 +71,7 @@ namespace NoUniqueAddr {
   };
 
   // CHECK: define {{.*}} @_ZN12NoUniqueAddr1FC1ERKS0_
-  // CHECK: call void @_ZN12NoUniqueAddr1AC2ERKS0_(
+  // CHECK: call {{.*}} @_ZN12NoUniqueAddr1AC2ERKS0_(
   // CHECK: store i32 {{.*}} @_ZTVN12NoUniqueAddr1FE
   // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}, i8* {{.*}}, i64 
7, i1 false)
   F f(F x) { return x; }


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


Re: [PATCH] D63451: P0840R2: support for [[no_unique_address]] attribute

2019-06-21 Thread Richard Smith via cfe-commits
Thanks, should hopefully be fixed by r364081.

On Fri, 21 Jun 2019 at 01:12, Yvan Roux via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> This commit broke ARM bots, logs are available here:
>
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/13576/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Atail-padding.cpp
>
> Thanks,
> Yvan
>
> On Thu, 20 Jun 2019 at 23:06, John McCall via Phabricator via
> llvm-commits  wrote:
> >
> > rjmccall added a comment.
> >
> > In D63451#1552609 , @rsmith
> wrote:
> >
> > > In D63451#1549563 ,
> @rjmccall wrote:
> > >
> > > > Can this attribute not be applied to a base class, or to a type?
> > >
> > >
> > > The standard attribute forbids that right now. We could add a custom
> attribute that permits it, but we're required to diagnose application of
> the standard attribute to a type -- though a warning would suffice to
> satisfy that requirement. (Because this gives "same as a base class"
> layout, adding it to a base class wouldn't have any effect right now, but
> we could certainly say that the attribute on a class type also implies the
> class is not POD for the purpose of layout, to permit tail padding reuse.)
> >
> >
> > I think we're talking about slightly different things.
> >
> > You're trying to make sure that fields can take advantage of the layout
> optimizations available to base classes so that library code doesn't need
> to contort to e.g. use the empty-base-class optimization just to avoid
> wasting an entire pointer to store an empty allocator.  This attribute
> seems well-targeted for that.
> >
> > Totally separately from that — but perhaps better-related to the name of
> the attribute — I know that some projects have, in the past, had surprising
> problems with the rule that class layout can't place empty base classes at
> the same offset as other objects of the same type.  For example, IIRC
> WebKit used to have a `Noncopyable` class that deleted its copy constructor
> and copy-assignment operators, and there was an idiom to inherit from this
> in order to disable copying, and at one point they discovered that some
> fairly important class was quite a bit larger than expected because of this
> rule — I think they were also using the base class redundantly throughout
> the hierarchy because they didn't expect there to be any harm to doing so.
> They would've no doubt appreciated the ability to just put the attribute on
> `Noncopyable`.  But of course they fixed that years ago, so I can't say
> that it's a serious issue for them now.
> >
> >
> > Repository:
> >   rL LLVM
> >
> > CHANGES SINCE LAST ACTION
> >   https://reviews.llvm.org/D63451/new/
> >
> > https://reviews.llvm.org/D63451
> >
> >
> >
> > ___
> > llvm-commits mailing list
> > llvm-comm...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r364087 - Quote path to Python executable in case it has spaces

2019-06-21 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Fri Jun 21 11:17:04 2019
New Revision: 364087

URL: http://llvm.org/viewvc/llvm-project?rev=364087&view=rev
Log:
Quote path to Python executable in case it has spaces

These days Python 3 is typically installed into C:/Program Files, so
cope with that.

Similar to r364077 in compiler-rt.

Modified:
clang-tools-extra/trunk/test/lit.cfg.py

Modified: clang-tools-extra/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/lit.cfg.py?rev=364087&r1=364086&r2=364087&view=diff
==
--- clang-tools-extra/trunk/test/lit.cfg.py (original)
+++ clang-tools-extra/trunk/test/lit.cfg.py Fri Jun 21 11:17:04 2019
@@ -118,21 +118,31 @@ if platform.system() not in ['Windows']:
 if config.clang_staticanalyzer:
 config.available_features.add('static-analyzer')
 
+# Get shlex.quote if available (added in 3.3), and fall back to pipes.quote if
+# it's not available.
+try:
+import shlex
+sh_quote = shlex.quote
+except:
+import pipes
+sh_quote = pipes.quote
+python_exec = sh_quote(config.python_executable)
+
 check_clang_tidy = os.path.join(
 config.test_source_root, "clang-tidy", "check_clang_tidy.py")
 config.substitutions.append(
 ('%check_clang_tidy',
- '%s %s' % (config.python_executable, check_clang_tidy)) )
+ '%s %s' % (python_exec, check_clang_tidy)) )
 clang_tidy_diff = os.path.join(
 config.test_source_root, "..", "clang-tidy", "tool", "clang-tidy-diff.py")
 config.substitutions.append(
 ('%clang_tidy_diff',
- '%s %s' % (config.python_executable, clang_tidy_diff)) )
+ '%s %s' % (python_exec, clang_tidy_diff)) )
 run_clang_tidy = os.path.join(
 config.test_source_root, "..", "clang-tidy", "tool", "run-clang-tidy.py")
 config.substitutions.append(
 ('%run_clang_tidy',
- '%s %s' % (config.python_executable, run_clang_tidy)) )
+ '%s %s' % (python_exec, run_clang_tidy)) )
 
 clangd_benchmarks_dir = os.path.join(os.path.dirname(config.clang_tools_dir),
  "tools", "clang", "tools", "extra",


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


RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread via cfe-commits
Hi Rainer,

I tried your patch and it still has problems. First, the "%s" was being 
replaced with the actual path by LIT, so I replaced that with "%%s" which then 
created the response file correctly, but now the response file contains this:

/IC:\src\git\dev\llvm\tools\clang\test\Driver\Inputs\\cl-response-file\ /DFOO=2

Which unfortunately gets interpreted by the compiler as:

"-I" 
"C:\\src\\git\\dev\\llvm\\tools\\clang\\test\\Driver\\Inputscl-response-file\\"
 "-D" "FOO=2"

Which doesn't match the CHECK line. Note the 4 backslashes. I think this could 
probably be fixed by just using a regex to match 1 or more backslashes?

Douglas Yung

-Original Message-
From: Rainer Orth  
Sent: Friday, June 21, 2019 7:02
To: Yung, Douglas 
Cc: r...@gcc.gnu.org; cfe-commits@lists.llvm.org
Subject: Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Hi Douglas,

> Your change appears to have broken the one platform you didn't test, 
> Windows. :)

sorry about that.  Unfortunately, I know next to nothing about Windows and 
don't have access to any system to test.

That said...

> Script:
> --
> : 'RUN: at line 7'; printf
> '/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
> \llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
> /DFOO=2' >
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\ll
> vm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp

... I should have looked at the autoconf manual first which has a whole section 
on the can of worms that is echo and how to properly use printf instead.

> Looking into this locally, the path contains "\t", so the response file that 
> is generated looks like this:
>
> C:\src\git\merge\llvm\tools\clang\test\Driver>type 
> cl-response-file.c.tmp.rsp /IC:\src\git\merge\llvm ools

The path not only contains \t, but \c as well, so the path is truncated after " 
ools".

> Can you take a look to see if there is something that works for all platforms 
> including Windows?

Judging from both the autoconf manual and my local testing, the following 
should work properly:

// RUN: printf '%s\n' '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp

i.e. use printf '%s\n' to do the printing.  I should have done this in the 
first place since otherwise the response file wasn't newline-terminated.  
Obviously that didn't matter on Solaris and Linux.

Once you've confirmed this works on Windows, I'll submit a proper follow-up 
patch.

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D63579: [clang-scan-deps] print the dependencies to stdout and remove the need to use -MD options in the CDB

2019-06-21 Thread Alex Lorenz via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL364088: [clang-scan-deps] print the dependencies to stdout 
(authored by arphaman, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63579?vs=205938&id=206039#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63579

Files:
  cfe/trunk/include/clang/Frontend/Utils.h
  cfe/trunk/lib/Frontend/DependencyFile.cpp
  cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
  cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
  cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp

Index: cfe/trunk/include/clang/Frontend/Utils.h
===
--- cfe/trunk/include/clang/Frontend/Utils.h
+++ cfe/trunk/include/clang/Frontend/Utils.h
@@ -132,6 +132,9 @@
   bool sawDependency(StringRef Filename, bool FromModule, bool IsSystem,
  bool IsModuleFile, bool IsMissing) final override;
 
+protected:
+  void outputDependencyFile(llvm::raw_ostream &OS);
+
 private:
   void outputDependencyFile(DiagnosticsEngine &Diags);
 
Index: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
===
--- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
+++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
@@ -1,12 +1,12 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs -MD -MF DIR/regular_cdb.d",
-  "file": "DIR/regular_cdb.cpp"
+  "command": "clang -E -fsyntax-only DIR/regular_cdb2.cpp -IInputs -D INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
+  "file": "DIR/regular_cdb2.cpp"
 },
 {
   "directory": "DIR",
-  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs -D INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
+  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs",
   "file": "DIR/regular_cdb.cpp"
 }
 ]
Index: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
===
--- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
+++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
@@ -2,26 +2,35 @@
 // RUN: rm -rf %t.cdb
 // RUN: mkdir -p %t.dir
 // RUN: cp %s %t.dir/regular_cdb.cpp
+// RUN: cp %s %t.dir/regular_cdb2.cpp
 // RUN: mkdir %t.dir/Inputs
 // RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
 // RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
 // RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/regular_cdb.json > %t.cdb
 //
-// RUN: clang-scan-deps -compilation-database %t.cdb -j 1
-// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
-// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
-// RUN: rm -rf %t.dir/regular_cdb.d %t.dir/regular_cdb2.d
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 1 | \
+// RUN:   FileCheck --check-prefixes=CHECK1,CHECK2,CHECK2NO %s
 //
-// RUN: clang-scan-deps -compilation-database %t.cdb -j 2
-// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
-// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
+// Make sure we didn't produce any dependency files!
+// RUN: not cat %t.dir/regular_cdb.d
+// RUN: not cat %t.dir/regular_cdb2.d
+//
+// The output order is non-deterministic when using more than one thread,
+// so check the output using two runs. Note that the 'NOT' check is not used
+// as it might fail if the results for `regular_cdb.cpp` are reported before
+// `regular_cdb2.cpp`.
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 | \
+// RUN:   FileCheck --check-prefix=CHECK1 %s
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 | \
+// RUN:   FileCheck --check-prefix=CHECK2 %s
 
 #include "header.h"
 
-// CHECK: regular_cdb.cpp
-// CHECK-NEXT: Inputs{{/|\\}}header.h
-// CHECK-NOT: header2
+// CHECK1: regular_cdb2.cpp
+// CHECK1-NEXT: Inputs{{/|\\}}header.h
+// CHECK1-NEXT: Inputs{{/|\\}}header2.h
 
 // CHECK2: regular_cdb.cpp
 // CHECK2-NEXT: Inputs{{/|\\}}header.h
-// CHECK2-NEXT: Inputs{{/|\\}}header2.h
+// CHECK2NO-NOT: header2
Index: cfe/trunk/lib/Frontend/DependencyFile.cpp
===
--- cfe/trunk/lib/Frontend/DependencyFile.cpp
+++ cfe/trunk/lib/Frontend/DependencyFile.cpp
@@ -322,6 +322,10 @@
 return;
   }
 
+  outputDependencyFile(OS);
+}
+
+void DependencyFileGenerator::outputDependencyFile(llvm::raw_ostream &OS) {
   // Write out the dependency targets, trying to avoid overly long
   // lines when possible. We try our best to emit exactly the same
   // dependency file as GCC (4.2), assuming the included files are the
Index: cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
+++ cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -29,12 +29,43 @@
 
 namespace {
 
+class SharedS

r364088 - [clang-scan-deps] print the dependencies to stdout

2019-06-21 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Fri Jun 21 11:24:55 2019
New Revision: 364088

URL: http://llvm.org/viewvc/llvm-project?rev=364088&view=rev
Log:
[clang-scan-deps] print the dependencies to stdout
and remove the need to use -MD options in the CDB

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

Modified:
cfe/trunk/include/clang/Frontend/Utils.h
cfe/trunk/lib/Frontend/DependencyFile.cpp
cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp

Modified: cfe/trunk/include/clang/Frontend/Utils.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/Utils.h?rev=364088&r1=364087&r2=364088&view=diff
==
--- cfe/trunk/include/clang/Frontend/Utils.h (original)
+++ cfe/trunk/include/clang/Frontend/Utils.h Fri Jun 21 11:24:55 2019
@@ -132,6 +132,9 @@ public:
   bool sawDependency(StringRef Filename, bool FromModule, bool IsSystem,
  bool IsModuleFile, bool IsMissing) final override;
 
+protected:
+  void outputDependencyFile(llvm::raw_ostream &OS);
+
 private:
   void outputDependencyFile(DiagnosticsEngine &Diags);
 

Modified: cfe/trunk/lib/Frontend/DependencyFile.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/DependencyFile.cpp?rev=364088&r1=364087&r2=364088&view=diff
==
--- cfe/trunk/lib/Frontend/DependencyFile.cpp (original)
+++ cfe/trunk/lib/Frontend/DependencyFile.cpp Fri Jun 21 11:24:55 2019
@@ -322,6 +322,10 @@ void DependencyFileGenerator::outputDepe
 return;
   }
 
+  outputDependencyFile(OS);
+}
+
+void DependencyFileGenerator::outputDependencyFile(llvm::raw_ostream &OS) {
   // Write out the dependency targets, trying to avoid overly long
   // lines when possible. We try our best to emit exactly the same
   // dependency file as GCC (4.2), assuming the included files are the

Modified: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=364088&r1=364087&r2=364088&view=diff
==
--- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (original)
+++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Fri Jun 21 11:24:55 
2019
@@ -1,12 +1,12 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs -MD -MF 
DIR/regular_cdb.d",
-  "file": "DIR/regular_cdb.cpp"
+  "command": "clang -E -fsyntax-only DIR/regular_cdb2.cpp -IInputs -D 
INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
+  "file": "DIR/regular_cdb2.cpp"
 },
 {
   "directory": "DIR",
-  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs -D 
INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
+  "command": "clang -E -fsyntax-only DIR/regular_cdb.cpp -IInputs",
   "file": "DIR/regular_cdb.cpp"
 }
 ]

Modified: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=364088&r1=364087&r2=364088&view=diff
==
--- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (original)
+++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Fri Jun 21 11:24:55 2019
@@ -2,26 +2,35 @@
 // RUN: rm -rf %t.cdb
 // RUN: mkdir -p %t.dir
 // RUN: cp %s %t.dir/regular_cdb.cpp
+// RUN: cp %s %t.dir/regular_cdb2.cpp
 // RUN: mkdir %t.dir/Inputs
 // RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
 // RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
 // RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/regular_cdb.json > %t.cdb
 //
-// RUN: clang-scan-deps -compilation-database %t.cdb -j 1
-// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
-// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
-// RUN: rm -rf %t.dir/regular_cdb.d %t.dir/regular_cdb2.d
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 1 | \
+// RUN:   FileCheck --check-prefixes=CHECK1,CHECK2,CHECK2NO %s
 //
-// RUN: clang-scan-deps -compilation-database %t.cdb -j 2
-// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
-// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
+// Make sure we didn't produce any dependency files!
+// RUN: not cat %t.dir/regular_cdb.d
+// RUN: not cat %t.dir/regular_cdb2.d
+//
+// The output order is non-deterministic when using more than one thread,
+// so check the output using two runs. Note that the 'NOT' check is not used
+// as it might fail if the results for `regular_cdb.cpp` are reported before
+// `regular_cdb2.cpp`.
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 | \
+// RUN:   FileCheck --check-prefix=CHECK1 %s
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 | \
+// RUN:   FileCheck --check-prefix=CHECK2 %s
 
 #include "header.h"
 
-// CHECK: reg

[PATCH] D63600: [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

This causes the test to fail on Windows:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/7712

There seems to be something wrong with the blamelist, so it didn't send email. 
I see this in the log from the previous build on that bot:

  Updating llvm to 363241 at ...

But buildbot thinks the previous build was testing r364000, so it didn't send 
any notifications.

`printf` seems like the wrong command to use to test backslash handling, since 
it interprets them as escapes. `%S` expands to a path containing backslashes, 
and the test logs seem consistent with that theory. I'll go ahead and revert 
this.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63600



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


r364089 - Revert [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Fri Jun 21 11:33:20 2019
New Revision: 364089

URL: http://llvm.org/viewvc/llvm-project?rev=364089&view=rev
Log:
Revert [test][Driver] Fix Clang :: Driver/cl-response-file.c

This reverts r363985 (git commit d5f16d6cfccc4b0b13b6c01d16c673886d53e695)

This test can't use printf on Windows because the path contains
backslashes which must not be interpreted as escapes by printf.

Modified:
cfe/trunk/test/Driver/cl-response-file.c

Modified: cfe/trunk/test/Driver/cl-response-file.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-response-file.c?rev=364089&r1=364088&r2=364089&view=diff
==
--- cfe/trunk/test/Driver/cl-response-file.c (original)
+++ cfe/trunk/test/Driver/cl-response-file.c Fri Jun 21 11:33:20 2019
@@ -4,7 +4,7 @@
 
 
 
-// RUN: printf '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp
+// RUN: echo '/I%S\Inputs\cl-response-file\ /DFOO=2' > %t.rsp
 // RUN: %clang_cl /c -### @%t.rsp -- %s 2>&1 | FileCheck %s
 
 // CHECK: "-I" "{{.*}}\\Inputs\\cl-response-file\\" "-D" "FOO=2"


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


[PATCH] D63626: [clang][NewPM] Remove exception handling before loading pgo sample profile data

2019-06-21 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added a comment.

In D63626#1553054 , @chandlerc wrote:

> See inline comment, but I think we should just drop the testing of the 
> function attribute bit here rather than adjusting the pipeline.


Ok. Removed the pipeline change for now.

In D63626#1553646 , @davidxl wrote:

> Is there a bug reference somewhere?


No bug has been filed for this, but I'm not sure if this is a bug if there 
aren't really any issues with PGO under the new PM.




Comment at: llvm/lib/Passes/PassBuilder.cpp:665-668
+// We must also remove exception handling before attaching sample profile
+// data.
+MPM.addPass(
+createModuleToPostOrderCGSCCPassAdaptor(PostOrderFunctionAttrsPass()));

tejohnson wrote:
> chandlerc wrote:
> > Does the this need to go before the EarlyFPM as well as before the sample 
> > profile loader?
> > 
> > Also, this is ... a pretty expensive thing to do... Do we really need this? 
> > We've been using ThinLTO and sample PGO with the new PM for a long time and 
> > haven't seen any real issue. I think we can probably just leave this 
> > difference between the two pass managers and remove the test for this pass 
> > running rather than adding it.
> > 
> > CC-ing some others just to double check, but I'm not aware of any issues 
> > we've seen with PGO that were because of this discrepancy.
> We don't tend to use exception handling so might not be hitting the issue 
> described in the headline.
> 
> If this is fixing an issue with SamplePGO and EH cleanup interactions, can 
> you add a test that tests for that (i.e. is there a code optimization issue 
> currently?).
I'm not entirely familiar with the expected codegen for SamplePGO or PruneEH 
and don't really know if not adding these 2 passes breaks anything.

Under the legacy PM, exception handling was removed via `PruneEH` before 
creating the sample profile loader, so this change was meant to match the 
behavior since `function-attrs` and `function(simplify-cfg)` (the new PM 
equivalent for `-prune-eh`) did not initially run before 
`SampleProfileLoaderPass` was added to the pipeline.

The original patch that added `CodeGen/pgo-sample.c` (D21197) doesn't seem to 
have any codegen tests either and only checks that PruneEH runs before sample 
profile loader creation, so I'm also unsure of what code optimizations are 
meant to happen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63626



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


[PATCH] D63626: [clang][NewPM] Remove exception handling before loading pgo sample profile data

2019-06-21 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 206041.
leonardchan marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63626

Files:
  clang/test/CodeGen/pgo-sample.c


Index: clang/test/CodeGen/pgo-sample.c
===
--- clang/test/CodeGen/pgo-sample.c
+++ clang/test/CodeGen/pgo-sample.c
@@ -1,6 +1,6 @@
 // Test if PGO sample use passes are invoked.
 //
 // Ensure Pass PGOInstrumentationGenPass is invoked.
-// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample.prof %s 
-mllvm -debug-pass=Structure -emit-llvm -o - 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample.prof %s 
-mllvm -debug-pass=Structure -emit-llvm -o - -fno-experimental-new-pass-manager 
2>&1 | FileCheck %s
 // CHECK: Remove unused exception handling info
 // CHECK: Sample profile pass


Index: clang/test/CodeGen/pgo-sample.c
===
--- clang/test/CodeGen/pgo-sample.c
+++ clang/test/CodeGen/pgo-sample.c
@@ -1,6 +1,6 @@
 // Test if PGO sample use passes are invoked.
 //
 // Ensure Pass PGOInstrumentationGenPass is invoked.
-// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample.prof %s -mllvm -debug-pass=Structure -emit-llvm -o - 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample.prof %s -mllvm -debug-pass=Structure -emit-llvm -o - -fno-experimental-new-pass-manager 2>&1 | FileCheck %s
 // CHECK: Remove unused exception handling info
 // CHECK: Sample profile pass
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

2019-06-21 Thread via cfe-commits
Hi Rainer,

I figured it out. Because you are using printf, you no longer need the '\\c'. 
If I use the following RUN line, the test passes on both Windows/linux (I don't 
have solaris to test unfortunately):

// RUN: printf '%%s\n' '/I%S\Inputs\cl-response-file\ /DFOO=2' > %t.rsp

I can submit this patch for you if you would like.

Douglas Yung

-Original Message-
From: Rainer Orth  
Sent: Friday, June 21, 2019 7:02
To: Yung, Douglas 
Cc: r...@gcc.gnu.org; cfe-commits@lists.llvm.org
Subject: Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Hi Douglas,

> Your change appears to have broken the one platform you didn't test, 
> Windows. :)

sorry about that.  Unfortunately, I know next to nothing about Windows and 
don't have access to any system to test.

That said...

> Script:
> --
> : 'RUN: at line 7'; printf
> '/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
> \llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
> /DFOO=2' >
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\ll
> vm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp

... I should have looked at the autoconf manual first which has a whole section 
on the can of worms that is echo and how to properly use printf instead.

> Looking into this locally, the path contains "\t", so the response file that 
> is generated looks like this:
>
> C:\src\git\merge\llvm\tools\clang\test\Driver>type 
> cl-response-file.c.tmp.rsp /IC:\src\git\merge\llvm ools

The path not only contains \t, but \c as well, so the path is truncated after " 
ools".

> Can you take a look to see if there is something that works for all platforms 
> including Windows?

Judging from both the autoconf manual and my local testing, the following 
should work properly:

// RUN: printf '%s\n' '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp

i.e. use printf '%s\n' to do the printing.  I should have done this in the 
first place since otherwise the response file wasn't newline-terminated.  
Obviously that didn't matter on Solaris and Linux.

Once you've confirmed this works on Windows, I'll submit a proper follow-up 
patch.

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D63663: [clang-doc] Add html links to the parents of a RecordInfo

2019-06-21 Thread Diego Astiazarán via Phabricator via cfe-commits
DiegoAstiazaran created this revision.
DiegoAstiazaran added reviewers: juliehockett, jakehehrlich, lebedev.ri.
DiegoAstiazaran added a project: clang-tools-extra.
Herald added subscribers: kadircet, arphaman.

 tags are added for the parents of records.
The link redirects to the parent's info file.

Depends on D63180 .


https://reviews.llvm.org/D63663

Files:
  clang-tools-extra/clang-doc/Generators.cpp
  clang-tools-extra/clang-doc/Generators.h
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/MDGenerator.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
  clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -39,7 +39,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(---
@@ -89,7 +90,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(---
@@ -148,7 +150,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(---
@@ -194,7 +197,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(---
@@ -331,7 +335,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(---
Index: clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/MDGeneratorTest.cpp
@@ -38,7 +38,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected = R"raw(# namespace Namespace
 
@@ -101,7 +102,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected = R"raw(# class r
 
@@ -162,7 +164,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected = R"raw(### f
 
@@ -190,7 +193,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected = R"raw(| enum class e |
 
@@ -320,7 +324,8 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expected =
   R"raw(### f
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
@@ -9,6 +9,7 @@
 #include "ClangDocTest.h"
 #include "Generators.h"
 #include "Representation.h"
+#include "Serialize.h"
 #include "gtest/gtest.h"
 
 namespace clang {
@@ -38,7 +39,9 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  auto Err = G->generateDocForInfo(&I, Actual);
+
+  std::map> Infos;
+  auto Err = G->generateDocForInfo(&I, Actual, Infos);
   assert(!Err);
   std::string Expe

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

2019-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5609
+def warn_mul_in_bool_context : Warning<
+  "'*' in bool context, maybe you mean '&&'?">,
+  InGroup;

xbolva00 wrote:
> aaron.ballman wrote:
> > I would appreciate seeing some motivating examples for this case, because 
> > it seems like the `&&` suggestion is misleading more often than it's 
> > helpful in the current test cases.
> > 
> > Also, what is a "bool context"?
> Bool context - places where we expect boolean expressions.
> 
> If you have idea for better terminology, I am happy to apply it.
> 
> Yeah, I will remove “&&” suggestion.. 
I don't have a good recommendation for a replacement for "boolean context", so 
I suppose we can leave it.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5625
+  "evaluate to 'true'">,
+  InGroup;
+

xbolva00 wrote:
> aaron.ballman wrote:
> > This one seems like it should be in the `TautologicalConstantCompare` 
> > group, no?
> Yes, we could move it there.
Don't *all* of these effectively boil down to a tautological comparison?


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] D63663: [clang-doc] Add html links to the parents of a RecordInfo

2019-06-21 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett added a comment.

General design thought: could we move the path name construction to 
`Serialize.cpp`? Essentially, move the logic that builds the path name from the 
namespaces and name to the serialize step (you'll have to add the 
`OutDirectory` to the `ClangDocContext` so that you can access it in the 
mapper), and then the `GetInfoOuputFile()` function in `ClangDocMain.cpp` would 
take the `Info.Path` string as a parameter and do the directory construction 
and whatnot.

With that, you could then also add the `Path` field to `Reference`s, so that 
you wouldn't need to pass a map around in the generation phase. What do you 
think?


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

https://reviews.llvm.org/D63663



___
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

2019-06-21 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5625
+  "evaluate to 'true'">,
+  InGroup;
+

aaron.ballman wrote:
> xbolva00 wrote:
> > aaron.ballman wrote:
> > > This one seems like it should be in the `TautologicalConstantCompare` 
> > > group, no?
> > Yes, we could move it there.
> Don't *all* of these effectively boil down to a tautological comparison?
So you propose put IntInBoolContext into TautologicalConstantCompare ?


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


  1   2   >