date:20160511

Re: [PATCH] D18478: python bindings: expose the clang version string

2016-05-11 Thread John Törnblom via cfe-commits

john.tornblom added a comment.

Any suggestions on how to test this? Just check for non-empty string?


http://reviews.llvm.org/D18478



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

Re: r269270 - [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

Thanks,

Reverted r269276

On Wed, May 11, 2016 at 9:38 PM, NAKAMURA Takumi  wrote:
> Bruno, it still fails. See;
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/12119
> http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/2847
>
> On Thu, May 12, 2016 at 12:29 PM Bruno Cardoso Lopes via cfe-commits
>  wrote:
>>
>> Author: bruno
>> Date: Wed May 11 22:23:36 2016
>> New Revision: 269270
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269270=rev
>> Log:
>> [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate
>> lookup
>>
>> The way we currently build the internal VFS overlay representation leads
>> to inefficient path search and might yield wrong answers when asked for
>> recursive or regular directory iteration.
>>
>> Currently, when reading an YAML file, each YAML root entry is placed
>> inside a new root in the filesystem overlay. In the crash reproducer, a
>> simple "@import Foundation" currently maps to 43 roots, and when looking
>> up paths, we traverse a directory tree for each of these different
>> roots, until we find a match (or don't). This has two consequences:
>>
>> - It's slow.
>> - Directory iteration gives incomplete results since it only return
>> results within one root - since contents of the same directory can be
>> declared inside different roots, the result isn't accurate.
>>
>> This is in part fault of the way we currently write out the YAML file
>> when emitting the crash reproducer - we could generate only one root and
>> that would make it fast and correct again. However, we should not rely
>> on how the client writes the YAML, but provide a good internal
>> representation regardless.
>>
>> This patch builds a proper virtual directory tree out of the YAML
>> representation, allowing faster search and proper iteration. Besides the
>> crash reproducer, this potentially benefits other VFS clients.
>>
>> Modified:
>> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>
>> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269270=269269=269270=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
>> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Wed May 11 22:23:36 2016
>> @@ -719,7 +719,13 @@ public:
>>  Status S)
>>: Entry(EK_Directory, Name), Contents(std::move(Contents)),
>>  S(std::move(S)) {}
>> +  RedirectingDirectoryEntry(StringRef Name, Status S)
>> +  : Entry(EK_Directory, Name), S(std::move(S)) {}
>>Status getStatus() { return S; }
>> +  void addContent(std::unique_ptr Content) {
>> +Contents.push_back(std::move(Content));
>> +  }
>> +  Entry *getLastContent() const { return Contents.back().get(); }
>>typedef decltype(Contents)::iterator iterator;
>>iterator contents_begin() { return Contents.begin(); }
>>iterator contents_end() { return Contents.end(); }
>> @@ -747,6 +753,7 @@ public:
>>  return UseName == NK_NotSet ? GlobalUseExternalName
>>  : (UseName == NK_External);
>>}
>> +  NameKind getUseName() const { return UseName; }
>>static bool classof(const Entry *E) { return E->getKind() == EK_File; }
>>  };
>>
>> @@ -1023,6 +1030,70 @@ class RedirectingFileSystemParser {
>>  return true;
>>}
>>
>> +  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
>> + Entry *ParentEntry = nullptr) {
>> +if (!ParentEntry) { // Look for a existent root
>> +  for (const std::unique_ptr  : FS->Roots) {
>> +if (Name.equals(Root->getName())) {
>> +  ParentEntry = Root.get();
>> +  return ParentEntry;
>> +}
>> +  }
>> +} else { // Advance to the next component
>> +  auto *DE = dyn_cast(ParentEntry);
>> +  for (std::unique_ptr  :
>> +   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
>> +auto *DirContent =
>> dyn_cast(Content.get());
>> +if (DirContent && Name.equals(Content->getName()))
>> +  return DirContent;
>> +  }
>> +}
>> +
>> +// ... or create a new one
>> +std::unique_ptr E =
>> llvm::make_unique(
>> +Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(),
>> 0, 0,
>> + 0, file_type::directory_file, sys::fs::all_all));
>> +
>> +if (!ParentEntry) { // Add a new root to the overlay
>> +  FS->Roots.push_back(std::move(E));
>> +  ParentEntry = FS->Roots.back().get();
>> +  return ParentEntry;
>> +}
>> +
>> +auto *DE = dyn_cast(ParentEntry);
>> +DE->addContent(std::move(E));
>> +return DE->getLastContent();
>> +  }
>> +
>> +  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
>> +

r269276 - Revert "[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup"

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

Author: bruno
Date: Wed May 11 23:43:27 2016
New Revision: 269276

URL: http://llvm.org/viewvc/llvm-project?rev=269276=rev
Log:
Revert "[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more 
accurate lookup"

Reverts r269270, buildbots still failing:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/12119
http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/2847

Modified:
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269276=269275=269276=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Wed May 11 23:43:27 2016
@@ -719,13 +719,7 @@ public:
 Status S)
   : Entry(EK_Directory, Name), Contents(std::move(Contents)),
 S(std::move(S)) {}
-  RedirectingDirectoryEntry(StringRef Name, Status S)
-  : Entry(EK_Directory, Name), S(std::move(S)) {}
   Status getStatus() { return S; }
-  void addContent(std::unique_ptr Content) {
-Contents.push_back(std::move(Content));
-  }
-  Entry *getLastContent() const { return Contents.back().get(); }
   typedef decltype(Contents)::iterator iterator;
   iterator contents_begin() { return Contents.begin(); }
   iterator contents_end() { return Contents.end(); }
@@ -753,7 +747,6 @@ public:
 return UseName == NK_NotSet ? GlobalUseExternalName
 : (UseName == NK_External);
   }
-  NameKind getUseName() const { return UseName; }
   static bool classof(const Entry *E) { return E->getKind() == EK_File; }
 };
 
@@ -1030,70 +1023,6 @@ class RedirectingFileSystemParser {
 return true;
   }
 
-  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
- Entry *ParentEntry = nullptr) {
-if (!ParentEntry) { // Look for a existent root
-  for (const std::unique_ptr  : FS->Roots) {
-if (Name.equals(Root->getName())) {
-  ParentEntry = Root.get();
-  return ParentEntry;
-}
-  }
-} else { // Advance to the next component
-  auto *DE = dyn_cast(ParentEntry);
-  for (std::unique_ptr  :
-   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
-auto *DirContent = dyn_cast(Content.get());
-if (DirContent && Name.equals(Content->getName()))
-  return DirContent;
-  }
-}
-
-// ... or create a new one
-std::unique_ptr E = llvm::make_unique(
-Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(), 0, 0,
- 0, file_type::directory_file, sys::fs::all_all));
-
-if (!ParentEntry) { // Add a new root to the overlay
-  FS->Roots.push_back(std::move(E));
-  ParentEntry = FS->Roots.back().get();
-  return ParentEntry;
-}
-
-auto *DE = dyn_cast(ParentEntry);
-DE->addContent(std::move(E));
-return DE->getLastContent();
-  }
-
-  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
- Entry *NewParentE = nullptr) {
-StringRef Name = SrcE->getName();
-switch (SrcE->getKind()) {
-case EK_Directory: {
-  auto *DE = dyn_cast(SrcE);
-  assert(DE && "Must be a directory");
-  // Empty directories could be present in the YAML as a way to
-  // describe a file for a current directory after some of its subdir
-  // is parsed. This only leads to redundant walks, ignore it.
-  if (!Name.empty())
-NewParentE = lookupOrCreateEntry(FS, Name, NewParentE);
-  for (std::unique_ptr  :
-   llvm::make_range(DE->contents_begin(), DE->contents_end()))
-uniqueOverlayTree(FS, SubEntry.get(), NewParentE);
-  break;
-}
-case EK_File: {
-  auto *FE = dyn_cast(SrcE);
-  assert(FE && "Must be a file");
-  assert(NewParentE && "Parent entry must exist");
-  auto *DE = dyn_cast(NewParentE);
-  DE->addContent(llvm::make_unique(
-  Name, FE->getExternalContentsPath(), FE->getUseName()));
-  break;
-}
-}
-  }
-
   std::unique_ptr parseEntry(yaml::Node *N, RedirectingFileSystem *FS) {
 yaml::MappingNode *M = dyn_cast(N);
 if (!M) {
@@ -1296,7 +1225,6 @@ public:
 };
 
 DenseMap Keys(std::begin(Fields), std::end(Fields));
-std::vector RootEntries;
 
 // Parse configuration and 'roots'
 for (yaml::MappingNode::iterator I = Top->begin(), E = Top->end(); I != E;
@@ -1319,7 +1247,7 @@ public:
 for (yaml::SequenceNode::iterator I = Roots->begin(), E = Roots->end();
  I != E; ++I) {
   if (std::unique_ptr E = parseEntry(&*I, FS))
-RootEntries.push_back(std::move(E));
+FS->Roots.push_back(std::move(E));
   else

Re: r269270 - [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread NAKAMURA Takumi via cfe-commits

Bruno, it still fails. See;
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/12119
http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/2847

On Thu, May 12, 2016 at 12:29 PM Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bruno
> Date: Wed May 11 22:23:36 2016
> New Revision: 269270
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269270=rev
> Log:
> [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate
> lookup
>
> The way we currently build the internal VFS overlay representation leads
> to inefficient path search and might yield wrong answers when asked for
> recursive or regular directory iteration.
>
> Currently, when reading an YAML file, each YAML root entry is placed
> inside a new root in the filesystem overlay. In the crash reproducer, a
> simple "@import Foundation" currently maps to 43 roots, and when looking
> up paths, we traverse a directory tree for each of these different
> roots, until we find a match (or don't). This has two consequences:
>
> - It's slow.
> - Directory iteration gives incomplete results since it only return
> results within one root - since contents of the same directory can be
> declared inside different roots, the result isn't accurate.
>
> This is in part fault of the way we currently write out the YAML file
> when emitting the crash reproducer - we could generate only one root and
> that would make it fast and correct again. However, we should not rely
> on how the client writes the YAML, but provide a good internal
> representation regardless.
>
> This patch builds a proper virtual directory tree out of the YAML
> representation, allowing faster search and proper iteration. Besides the
> crash reproducer, this potentially benefits other VFS clients.
>
> Modified:
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269270=269269=269270=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Wed May 11 22:23:36 2016
> @@ -719,7 +719,13 @@ public:
>  Status S)
>: Entry(EK_Directory, Name), Contents(std::move(Contents)),
>  S(std::move(S)) {}
> +  RedirectingDirectoryEntry(StringRef Name, Status S)
> +  : Entry(EK_Directory, Name), S(std::move(S)) {}
>Status getStatus() { return S; }
> +  void addContent(std::unique_ptr Content) {
> +Contents.push_back(std::move(Content));
> +  }
> +  Entry *getLastContent() const { return Contents.back().get(); }
>typedef decltype(Contents)::iterator iterator;
>iterator contents_begin() { return Contents.begin(); }
>iterator contents_end() { return Contents.end(); }
> @@ -747,6 +753,7 @@ public:
>  return UseName == NK_NotSet ? GlobalUseExternalName
>  : (UseName == NK_External);
>}
> +  NameKind getUseName() const { return UseName; }
>static bool classof(const Entry *E) { return E->getKind() == EK_File; }
>  };
>
> @@ -1023,6 +1030,70 @@ class RedirectingFileSystemParser {
>  return true;
>}
>
> +  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
> + Entry *ParentEntry = nullptr) {
> +if (!ParentEntry) { // Look for a existent root
> +  for (const std::unique_ptr  : FS->Roots) {
> +if (Name.equals(Root->getName())) {
> +  ParentEntry = Root.get();
> +  return ParentEntry;
> +}
> +  }
> +} else { // Advance to the next component
> +  auto *DE = dyn_cast(ParentEntry);
> +  for (std::unique_ptr  :
> +   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
> +auto *DirContent =
> dyn_cast(Content.get());
> +if (DirContent && Name.equals(Content->getName()))
> +  return DirContent;
> +  }
> +}
> +
> +// ... or create a new one
> +std::unique_ptr E =
> llvm::make_unique(
> +Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(),
> 0, 0,
> + 0, file_type::directory_file, sys::fs::all_all));
> +
> +if (!ParentEntry) { // Add a new root to the overlay
> +  FS->Roots.push_back(std::move(E));
> +  ParentEntry = FS->Roots.back().get();
> +  return ParentEntry;
> +}
> +
> +auto *DE = dyn_cast(ParentEntry);
> +DE->addContent(std::move(E));
> +return DE->getLastContent();
> +  }
> +
> +  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
> + Entry *NewParentE = nullptr) {
> +StringRef Name = SrcE->getName();
> +switch (SrcE->getKind()) {
> +case EK_Directory: {
> +  auto *DE = dyn_cast(SrcE);
> +  assert(DE && "Must be a directory");
> +

[clang-tools-extra] r269275 - [clang-tidy] Improve misc-redundant-expression and decrease false-positive

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 23:32:47 2016
New Revision: 269275

URL: http://llvm.org/viewvc/llvm-project?rev=269275=rev
Log:
[clang-tidy] Improve misc-redundant-expression and decrease false-positive

Summary:
This patch is adding support for conditional expression and overloaded 
operators.

To decrease false-positive, this patch is adding a list of banned macro names 
that
has multiple variant with same integer value.

Also fixed support for template instantiation and added an unittest.

Reviewers: alexfh

Subscribers: klimek, Sarcasm, cfe-commits

Differential Revision: http://reviews.llvm.org/D19703

Modified:
clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-redundant-expression.rst
clang-tools-extra/trunk/test/clang-tidy/misc-redundant-expression.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp?rev=269275=269274=269275=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp Wed 
May 11 23:32:47 2016
@@ -9,8 +9,10 @@
 
 #include "RedundantExpressionCheck.h"
 #include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
 
 using namespace clang::ast_matchers;
 
@@ -18,7 +20,18 @@ namespace clang {
 namespace tidy {
 namespace misc {
 
-static bool AreIdenticalExpr(const Expr *Left, const Expr *Right) {
+static const char KnownBannedMacroNames[] =
+"EAGAIN;EWOULDBLOCK;SIGCLD;SIGCHLD;";
+
+static bool areEquivalentNameSpecifier(const NestedNameSpecifier *Left,
+   const NestedNameSpecifier *Right) {
+  llvm::FoldingSetNodeID LeftID, RightID;
+  Left->Profile(LeftID);
+  Right->Profile(RightID);
+  return LeftID == RightID;
+}
+
+static bool areEquivalentExpr(const Expr *Left, const Expr *Right) {
   if (!Left || !Right)
 return !Left && !Right;
 
@@ -33,8 +46,8 @@ static bool AreIdenticalExpr(const Expr
   Expr::const_child_iterator LeftIter = Left->child_begin();
   Expr::const_child_iterator RightIter = Right->child_begin();
   while (LeftIter != Left->child_end() && RightIter != Right->child_end()) {
-if (!AreIdenticalExpr(dyn_cast(*LeftIter),
-  dyn_cast(*RightIter)))
+if (!areEquivalentExpr(dyn_cast(*LeftIter),
+   dyn_cast(*RightIter)))
   return false;
 ++LeftIter;
 ++RightIter;
@@ -53,7 +66,8 @@ static bool AreIdenticalExpr(const Expr
   case Stmt::IntegerLiteralClass: {
 llvm::APInt LeftLit = cast(Left)->getValue();
 llvm::APInt RightLit = cast(Right)->getValue();
-return LeftLit.getBitWidth() == RightLit.getBitWidth() && LeftLit == 
RightLit;
+return LeftLit.getBitWidth() == RightLit.getBitWidth() &&
+   LeftLit == RightLit;
   }
   case Stmt::FloatingLiteralClass:
 return cast(Left)->getValue().bitwiseIsEqual(
@@ -62,6 +76,13 @@ static bool AreIdenticalExpr(const Expr
 return cast(Left)->getBytes() ==
cast(Right)->getBytes();
 
+  case Stmt::DependentScopeDeclRefExprClass:
+if (cast(Left)->getDeclName() !=
+cast(Right)->getDeclName())
+  return false;
+return areEquivalentNameSpecifier(
+cast(Left)->getQualifier(),
+cast(Right)->getQualifier());
   case Stmt::DeclRefExprClass:
 return cast(Left)->getDecl() ==
cast(Right)->getDecl();
@@ -89,22 +110,52 @@ static bool AreIdenticalExpr(const Expr
   }
 }
 
-AST_MATCHER(BinaryOperator, OperandsAreEquivalent) {
-  return AreIdenticalExpr(Node.getLHS(), Node.getRHS());
+AST_MATCHER(BinaryOperator, operandsAreEquivalent) {
+  return areEquivalentExpr(Node.getLHS(), Node.getRHS());
+}
+
+AST_MATCHER(ConditionalOperator, expressionsAreEquivalent) {
+  return areEquivalentExpr(Node.getTrueExpr(), Node.getFalseExpr());
+}
+
+AST_MATCHER(CallExpr, parametersAreEquivalent) {
+  return Node.getNumArgs() == 2 &&
+ areEquivalentExpr(Node.getArg(0), Node.getArg(1));
 }
 
-AST_MATCHER(BinaryOperator, isInMacro) {
+AST_MATCHER(BinaryOperator, binaryOperatorIsInMacro) {
   return Node.getOperatorLoc().isMacroID();
 }
 
-AST_MATCHER(Expr, isInstantiationDependent) {
-  return Node.isInstantiationDependent();
+AST_MATCHER(ConditionalOperator, conditionalOperatorIsInMacro) {
+  return Node.getQuestionLoc().isMacroID() || Node.getColonLoc().isMacroID();
+}
+
+AST_MATCHER(Expr, isMacro) { return Node.getExprLoc().isMacroID(); }
+
+AST_MATCHER_P(Expr, expandedByMacro, std::set, Names) {
+  const SourceManager  = Finder->getASTContext().getSourceManager();
+  const LangOptions  = Finder->getASTContext().getLangOpts();
+

r269274 - Add an AST matcher for string-literal length

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 23:20:04 2016
New Revision: 269274

URL: http://llvm.org/viewvc/llvm-project?rev=269274=rev
Log:
Add an AST matcher for string-literal length

Summary:
This patch is adding support for a matcher to check string literal length.

This matcher is used in clang-tidy checkers and is part of this refactoring:
  see: http://reviews.llvm.org/D19841

Reviewers: sbenza, klimek, aaron.ballman

Subscribers: alexfh, klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D19876

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=269274=269273=269274=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Wed May 11 23:20:04 2016
@@ -644,7 +644,8 @@ Not matching Hex-encoded chars (e.g. 0x1
 though.
 
 Example matches 'a', L'a'
-  char ch = 'a'; wchar_t chw = L'a';
+  char ch = 'a';
+  wchar_t chw = L'a';
 
 
 
@@ -652,7 +653,8 @@ Example matches 'a', L'a'
 Matches 
compound (i.e. non-scalar) literals
 
 Example match: {1}, (1, 2)
-  int array[4] = {1}; vector int myvec = (vector int)(1, 2);
+  int array[4] = {1};
+  vector int myvec = (vector int)(1, 2);
 
 
 
@@ -1217,7 +1219,8 @@ Example match: ({ int X = 4; X; })
 Matches string 
literals (also matches wide string literals).
 
 Example matches "abcd", L"abcd"
-  char *s = "abcd"; wchar_t *ws = L"abcd"
+  char *s = "abcd";
+  wchar_t *ws = L"abcd";
 
 
 
@@ -2191,14 +2194,19 @@ compoundStmt(statementCountIs(0)))
 
 
 Matcherhttp://clang.llvm.org/doxygen/classclang_1_1ConstantArrayType.html;>ConstantArrayTypehasSizeunsigned N
-Matches ConstantArrayType 
nodes that have the specified size.
+Matches nodes that have the 
specified size.
 
 Given
   int a[42];
   int b[2 * 21];
   int c[41], d[43];
+  char *s = "abcd";
+  wchar_t *ws = L"abcd";
+  char *w = "a";
 constantArrayType(hasSize(42))
   matches "int a[42]" and "int b[2 * 21]"
+stringLiteral(hasSize(4))
+  matches "abcd", L"abcd"
 
 
 
@@ -2955,6 +2963,23 @@ Usable as: Matcherhttp://cl
 
 
 
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1StringLiteral.html;>StringLiteralhasSizeunsigned N
+Matches nodes that have the 
specified size.
+
+Given
+  int a[42];
+  int b[2 * 21];
+  int c[41], d[43];
+  char *s = "abcd";
+  wchar_t *ws = L"abcd";
+  char *w = "a";
+constantArrayType(hasSize(42))
+  matches "int a[42]" and "int b[2 * 21]"
+stringLiteral(hasSize(4))
+  matches "abcd", L"abcd"
+
+
+
 Matcherhttp://clang.llvm.org/doxygen/classclang_1_1TagDecl.html;>TagDeclisDefinition
 Matches if a 
declaration has a body attached.
 

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=269274=269273=269274=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed May 11 23:20:04 2016
@@ -1560,7 +1560,8 @@ const internal::VariadicDynCastAllOfMatc
 ///
 /// Example matches "abcd", L"abcd"
 /// \code
-///   char *s = "abcd"; wchar_t *ws = L"abcd"
+///   char *s = "abcd";
+///   wchar_t *ws = L"abcd";
 /// \endcode
 const internal::VariadicDynCastAllOfMatcher<
   Stmt,
@@ -1573,7 +1574,8 @@ const internal::VariadicDynCastAllOfMatc
 ///
 /// Example matches 'a', L'a'
 /// \code
-///   char ch = 'a'; wchar_t chw = L'a';
+///   char ch = 'a';
+///   wchar_t chw = L'a';
 /// \endcode
 const internal::VariadicDynCastAllOfMatcher<
   Stmt,
@@ -1609,7 +1611,8 @@ const internal::VariadicDynCastAllOfMatc
 ///
 /// Example match: {1}, (1, 2)
 /// \code
-///   int array[4] = {1}; vector int myvec = (vector int)(1, 2);
+///   int array[4] = {1};
+///   vector int myvec = (vector int)(1, 2);
 /// \endcode
 const internal::VariadicDynCastAllOfMatcher<
   Stmt,
@@ -4228,18 +4231,26 @@ AST_TYPELOC_TRAVERSE_MATCHER(hasElementT
 ///   matches "int a[2]"
 AST_TYPE_MATCHER(ConstantArrayType, constantArrayType);
 
-/// \brief Matches \c ConstantArrayType nodes that have the specified size.
+/// \brief Matches nodes that have the specified size.
 ///
 /// Given
 /// \code
 ///   int a[42];
 ///   int b[2 * 21];
 ///   int c[41], d[43];
+///   char *s = "abcd";
+///   wchar_t *ws = L"abcd";
+///   char *w = "a";
 /// \endcode
 /// constantArrayType(hasSize(42))
 ///   matches "int a[42]" and "int b[2 * 21]"
-AST_MATCHER_P(ConstantArrayType, hasSize, unsigned, N) {
-  return Node.getSize() == N;
+/// stringLiteral(hasSize(4))
+///   matches "abcd", L"abcd"
+AST_POLYMORPHIC_MATCHER_P(hasSize,
+

r269271 - [MS ABI] Don't crash when zero-initializing a vbase which contains a vbase

2016-05-11 Thread David Majnemer via cfe-commits

Author: majnemer
Date: Wed May 11 22:51:52 2016
New Revision: 269271

URL: http://llvm.org/viewvc/llvm-project?rev=269271=rev
Log:
[MS ABI] Don't crash when zero-initializing a vbase which contains a vbase

Bases can be zero-initialized: the storage is zero-initialized before
the base constructor is run.
The MS ABI has a quirk where base VBPtrs are not installed by the
base constructor but by the most derived class.  In particular, they are
installed before the base constructor is run.
The derived constructor must be careful to zero-initialize only the bits
of the class which haven't already been populated by virtual base
pointers.

While we correctly avoided this scenario, we didn't handle the case
where the base class has virtual bases which have virtual bases.

Modified:
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprCXX.cpp?rev=269271=269270=269271=diff
==
--- cfe/trunk/lib/CodeGen/CGExprCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprCXX.cpp Wed May 11 22:51:52 2016
@@ -370,6 +370,9 @@ static void EmitNullBaseClassInitializat
   std::vector VBPtrOffsets =
   CGF.CGM.getCXXABI().getVBPtrOffsets(Base);
   for (CharUnits VBPtrOffset : VBPtrOffsets) {
+// Stop before we hit any virtual base pointers located in virtual bases.
+if (VBPtrOffset >= NVSize)
+  break;
 std::pair LastStore = Stores.pop_back_val();
 CharUnits LastStoreOffset = LastStore.first;
 CharUnits LastStoreSize = LastStore.second;

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp?rev=269271=269270=269271=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-inheritance.cpp Wed May 11 
22:51:52 2016
@@ -499,3 +499,25 @@ void callit(C *p) {
 // CHECK: %[[B_i8:.*]] = getelementptr i8, i8* %{{.*}}, i32 4
 // CHECK: call x86_thiscallcc void @"\01?g@C@pr27621@@UAEXXZ"(i8* %[[B_i8]])
 }
+
+namespace test6 {
+class A {};
+class B : virtual A {};
+class C : virtual B {
+  virtual void m_fn1();
+  float field;
+};
+class D : C {
+  D();
+};
+D::D() : C() {}
+// CHECK-LABEL: define x86_thiscallcc %"class.test6::D"* 
@"\01??0D@test6@@AAE@XZ"(
+// CHECK:   %[[THIS:.*]] = load %"class.test6::D"*, %"class.test6::D"**
+// CHECK:   br i1 %{{.*}}, label %[[INIT_VBASES:.*]], label %[[SKIP_VBASES:.*]]
+
+// CHECK: %[[SKIP_VBASES]]
+// CHECK:   %[[C:.*]] = bitcast %"class.test6::D"* %[[THIS]] to 
%"class.test6::C"*
+// CHECK:   %[[C_i8:.*]] = bitcast %"class.test6::C"* %[[C]] to i8*
+// CHECK:   %[[FIELD:.*]] = getelementptr inbounds i8, i8* %[[C_i8]], i32 8
+// CHECK:   call void @llvm.memset.p0i8.i32(i8* %[[FIELD]], i8 0, i32 4, i32 
4, i1 false)
+}


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

r269270 - [VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

Author: bruno
Date: Wed May 11 22:23:36 2016
New Revision: 269270

URL: http://llvm.org/viewvc/llvm-project?rev=269270=rev
Log:
[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup

The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.

Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:

- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.

This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.

This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.

Modified:
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269270=269269=269270=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Wed May 11 22:23:36 2016
@@ -719,7 +719,13 @@ public:
 Status S)
   : Entry(EK_Directory, Name), Contents(std::move(Contents)),
 S(std::move(S)) {}
+  RedirectingDirectoryEntry(StringRef Name, Status S)
+  : Entry(EK_Directory, Name), S(std::move(S)) {}
   Status getStatus() { return S; }
+  void addContent(std::unique_ptr Content) {
+Contents.push_back(std::move(Content));
+  }
+  Entry *getLastContent() const { return Contents.back().get(); }
   typedef decltype(Contents)::iterator iterator;
   iterator contents_begin() { return Contents.begin(); }
   iterator contents_end() { return Contents.end(); }
@@ -747,6 +753,7 @@ public:
 return UseName == NK_NotSet ? GlobalUseExternalName
 : (UseName == NK_External);
   }
+  NameKind getUseName() const { return UseName; }
   static bool classof(const Entry *E) { return E->getKind() == EK_File; }
 };
 
@@ -1023,6 +1030,70 @@ class RedirectingFileSystemParser {
 return true;
   }
 
+  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
+ Entry *ParentEntry = nullptr) {
+if (!ParentEntry) { // Look for a existent root
+  for (const std::unique_ptr  : FS->Roots) {
+if (Name.equals(Root->getName())) {
+  ParentEntry = Root.get();
+  return ParentEntry;
+}
+  }
+} else { // Advance to the next component
+  auto *DE = dyn_cast(ParentEntry);
+  for (std::unique_ptr  :
+   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
+auto *DirContent = dyn_cast(Content.get());
+if (DirContent && Name.equals(Content->getName()))
+  return DirContent;
+  }
+}
+
+// ... or create a new one
+std::unique_ptr E = llvm::make_unique(
+Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(), 0, 0,
+ 0, file_type::directory_file, sys::fs::all_all));
+
+if (!ParentEntry) { // Add a new root to the overlay
+  FS->Roots.push_back(std::move(E));
+  ParentEntry = FS->Roots.back().get();
+  return ParentEntry;
+}
+
+auto *DE = dyn_cast(ParentEntry);
+DE->addContent(std::move(E));
+return DE->getLastContent();
+  }
+
+  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
+ Entry *NewParentE = nullptr) {
+StringRef Name = SrcE->getName();
+switch (SrcE->getKind()) {
+case EK_Directory: {
+  auto *DE = dyn_cast(SrcE);
+  assert(DE && "Must be a directory");
+  // Empty directories could be present in the YAML as a way to
+  // describe a file for a current directory after some of its subdir
+  // is parsed. This only leads to redundant walks, ignore it.
+  if (!Name.empty())
+NewParentE = lookupOrCreateEntry(FS, Name, NewParentE);
+  for (std::unique_ptr  :
+   llvm::make_range(DE->contents_begin(), DE->contents_end()))
+uniqueOverlayTree(FS, SubEntry.get(), NewParentE);
+  break;
+}
+

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

> What are the platform-specifics for crash reproducing? Shouldn't it
> basically be saving some files and storing some data for reconstructing?

Feature-wise the crash reproducer for modules could "just" work for
windows, there should not be anything platform-specific, I never
tested it on windows though :-)

Darwin requires lot of custom logic to handle frameworks, and those
use recursive and normal directory iterators to scan inner frameworks;
depending on the way we write the YAML file, the VFS wouldn't be able
to correctly grab all subdirs / files, which this patch fixes. We
don't collect everything because we don't want every reproducer to
contain the whole SDK.

> We've recently been working on a `--reproduce` for LLD and we haven't needed
> any ifdefs for windows (some tests that rely on really long path names need
> to be turned off, but the feature still works).

The ifdefs are for realpath or related-to, which I mentioned
previously should be abstracted properly soon.

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.

2016-05-11 Thread Alexey Bataev via cfe-commits

Yes, mangled names for vector versions are added as attributes to the 
original function.

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

12.05.2016 6:00, Hal Finkel пишет:
> Hi Alexey,
>
> As I recall, Xinmin's RFC discussed encoding the various possible manglings 
> for vector functions in some attribute. Is that what this does? It is 
> difficult to tell from the test case what's actually happing here.
>
>   -Hal
>
> - Original Message -
>> From: "Alexey Bataev" 
>> To: "Hal Finkel" 
>> Cc: cfe-commits@lists.llvm.org
>> Sent: Wednesday, May 11, 2016 9:38:27 PM
>> Subject: Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.
>>
>> Hal,
>>
>> According to Xinmin's RFC the codegen for 'declare simd' in clang
>> includes only generation of special (Vector ABI) mangled names for
>> future vectorized versions of elemental functions. Actual vector
>> versions must be generated by a backend. Xinmin and his team are
>> working
>> on this.
>>
>> The mangling part was accepted by David Majnemer (that's why I had to
>> implement it in clang), but RFC for a backend pass for generation of
>> vector functions is still under review, I think
>>
>> Best regards,
>> Alexey Bataev
>> =
>> Software Engineer
>> Intel Compiler Team
>>
>> 11.05.2016 20:46, Hal Finkel пишет:
>>> Hi Alexey,
>>>
>>> I'm a bit confused regarding what this patch does, in part because
>>> the test case does not test any of the function argument or return
>>> types. Does it generate these "simd" functions taking scalar
>>> arguments? I'd expect that what this does is that it generates
>>> functions taking vector arguments and producing vector results. It
>>> would then extract the scalar values from those arguments and feed
>>> them into the scalar code (replicated N times), and then insert
>>> the results into the vector return value. The SLP vectorizer will
>>> then vectorize the function if profitable.
>>>
>>> Thanks again,
>>> Hal
>>>
>>> - Original Message -
 From: "Alexey Bataev via cfe-commits" 
 To: cfe-commits@lists.llvm.org
 Sent: Friday, May 6, 2016 4:40:08 AM
 Subject: r268721 - [OPENMP 4.0] Codegen for 'declare simd'
 directive.

 Author: abataev
 Date: Fri May  6 04:40:08 2016
 New Revision: 268721

 URL: http://llvm.org/viewvc/llvm-project?rev=268721=rev
 Log:
 [OPENMP 4.0] Codegen for 'declare simd' directive.

 OpenMP 4.0 adds support for elemental functions using declarative
 directive '#pragma omp declare simd'. Patch adds mangling for simd
 functions in accordance with
 https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt

 Added:
   cfe/trunk/test/OpenMP/declare_simd_codegen.cpp
 Modified:
   cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
   cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
   cfe/trunk/lib/CodeGen/CodeGenFunction.cpp

 Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=268721=268720=268721=diff
 ==
 --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
 +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri May  6 04:40:08
 2016
 @@ -6042,3 +6042,228 @@ void CGOpenMPRuntime::emitTargetEnterOrE
ThenGenRCG(CGF);
  }
}
 +
 +namespace {
 +  /// Kind of parameter in a function with 'declare simd'
 directive.
 +  enum ParamKindTy { LinearWithVarStride, Linear, Uniform, Vector
 };
 +  /// Attribute set of the parameter.
 +  struct ParamAttrTy {
 +ParamKindTy Kind = Vector;
 +llvm::APSInt StrideOrArg;
 +llvm::APSInt Alignment;
 +  };
 +} // namespace
 +
 +static unsigned evaluateCDTSize(const FunctionDecl *FD,
 +ArrayRef ParamAttrs)
 {
 +  // Every vector variant of a SIMD-enabled function has a vector
 length (VLEN).
 +  // If OpenMP clause "simdlen" is used, the VLEN is the value of
 the argument
 +  // of that clause. The VLEN value must be power of 2.
 +  // In other case the notion of the function`s "characteristic
 data
 type" (CDT)
 +  // is used to compute the vector length.
 +  // CDT is defined in the following order:
 +  //   a) For non-void function, the CDT is the return type.
 +  //   b) If the function has any non-uniform, non-linear
 parameters, then the
 +  //   CDT is the type of the first such parameter.
 +  //   c) If the CDT determined by a) or b) above is struct,
 union,
 or class
 +  //   type which is pass-by-value (except for the type that maps
 to
 the
 +  //   built-in complex data type), the characteristic data

Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.

2016-05-11 Thread Hal Finkel via cfe-commits

Hi Alexey,

As I recall, Xinmin's RFC discussed encoding the various possible manglings for 
vector functions in some attribute. Is that what this does? It is difficult to 
tell from the test case what's actually happing here.

 -Hal

- Original Message -
> From: "Alexey Bataev" 
> To: "Hal Finkel" 
> Cc: cfe-commits@lists.llvm.org
> Sent: Wednesday, May 11, 2016 9:38:27 PM
> Subject: Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.
> 
> Hal,
> 
> According to Xinmin's RFC the codegen for 'declare simd' in clang
> includes only generation of special (Vector ABI) mangled names for
> future vectorized versions of elemental functions. Actual vector
> versions must be generated by a backend. Xinmin and his team are
> working
> on this.
> 
> The mangling part was accepted by David Majnemer (that's why I had to
> implement it in clang), but RFC for a backend pass for generation of
> vector functions is still under review, I think
> 
> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
> 
> 11.05.2016 20:46, Hal Finkel пишет:
> > Hi Alexey,
> >
> > I'm a bit confused regarding what this patch does, in part because
> > the test case does not test any of the function argument or return
> > types. Does it generate these "simd" functions taking scalar
> > arguments? I'd expect that what this does is that it generates
> > functions taking vector arguments and producing vector results. It
> > would then extract the scalar values from those arguments and feed
> > them into the scalar code (replicated N times), and then insert
> > the results into the vector return value. The SLP vectorizer will
> > then vectorize the function if profitable.
> >
> > Thanks again,
> > Hal
> >
> > - Original Message -
> >> From: "Alexey Bataev via cfe-commits" 
> >> To: cfe-commits@lists.llvm.org
> >> Sent: Friday, May 6, 2016 4:40:08 AM
> >> Subject: r268721 - [OPENMP 4.0] Codegen for 'declare simd'
> >> directive.
> >>
> >> Author: abataev
> >> Date: Fri May  6 04:40:08 2016
> >> New Revision: 268721
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=268721=rev
> >> Log:
> >> [OPENMP 4.0] Codegen for 'declare simd' directive.
> >>
> >> OpenMP 4.0 adds support for elemental functions using declarative
> >> directive '#pragma omp declare simd'. Patch adds mangling for simd
> >> functions in accordance with
> >> https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt
> >>
> >> Added:
> >>  cfe/trunk/test/OpenMP/declare_simd_codegen.cpp
> >> Modified:
> >>  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> >>  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> >>  cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> >>
> >> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=268721=268720=268721=diff
> >> ==
> >> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> >> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri May  6 04:40:08
> >> 2016
> >> @@ -6042,3 +6042,228 @@ void CGOpenMPRuntime::emitTargetEnterOrE
> >>   ThenGenRCG(CGF);
> >> }
> >>   }
> >> +
> >> +namespace {
> >> +  /// Kind of parameter in a function with 'declare simd'
> >> directive.
> >> +  enum ParamKindTy { LinearWithVarStride, Linear, Uniform, Vector
> >> };
> >> +  /// Attribute set of the parameter.
> >> +  struct ParamAttrTy {
> >> +ParamKindTy Kind = Vector;
> >> +llvm::APSInt StrideOrArg;
> >> +llvm::APSInt Alignment;
> >> +  };
> >> +} // namespace
> >> +
> >> +static unsigned evaluateCDTSize(const FunctionDecl *FD,
> >> +ArrayRef ParamAttrs)
> >> {
> >> +  // Every vector variant of a SIMD-enabled function has a vector
> >> length (VLEN).
> >> +  // If OpenMP clause "simdlen" is used, the VLEN is the value of
> >> the argument
> >> +  // of that clause. The VLEN value must be power of 2.
> >> +  // In other case the notion of the function`s "characteristic
> >> data
> >> type" (CDT)
> >> +  // is used to compute the vector length.
> >> +  // CDT is defined in the following order:
> >> +  //   a) For non-void function, the CDT is the return type.
> >> +  //   b) If the function has any non-uniform, non-linear
> >> parameters, then the
> >> +  //   CDT is the type of the first such parameter.
> >> +  //   c) If the CDT determined by a) or b) above is struct,
> >> union,
> >> or class
> >> +  //   type which is pass-by-value (except for the type that maps
> >> to
> >> the
> >> +  //   built-in complex data type), the characteristic data type
> >> is
> >> int.
> >> +  //   d) If none of the above three cases is applicable, the CDT
> >> is
> >> int.
> >> +  // The VLEN is then determined based on the CDT and the size of
> >> vector
> >> +  // register of that ISA for which current

Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.

2016-05-11 Thread Alexey Bataev via cfe-commits

Hal,

According to Xinmin's RFC the codegen for 'declare simd' in clang 
includes only generation of special (Vector ABI) mangled names for 
future vectorized versions of elemental functions. Actual vector 
versions must be generated by a backend. Xinmin and his team are working 
on this.

The mangling part was accepted by David Majnemer (that's why I had to 
implement it in clang), but RFC for a backend pass for generation of 
vector functions is still under review, I think

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

11.05.2016 20:46, Hal Finkel пишет:
> Hi Alexey,
>
> I'm a bit confused regarding what this patch does, in part because the test 
> case does not test any of the function argument or return types. Does it 
> generate these "simd" functions taking scalar arguments? I'd expect that what 
> this does is that it generates functions taking vector arguments and 
> producing vector results. It would then extract the scalar values from those 
> arguments and feed them into the scalar code (replicated N times), and then 
> insert the results into the vector return value. The SLP vectorizer will then 
> vectorize the function if profitable.
>
> Thanks again,
> Hal
>
> - Original Message -
>> From: "Alexey Bataev via cfe-commits" 
>> To: cfe-commits@lists.llvm.org
>> Sent: Friday, May 6, 2016 4:40:08 AM
>> Subject: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.
>>
>> Author: abataev
>> Date: Fri May  6 04:40:08 2016
>> New Revision: 268721
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=268721=rev
>> Log:
>> [OPENMP 4.0] Codegen for 'declare simd' directive.
>>
>> OpenMP 4.0 adds support for elemental functions using declarative
>> directive '#pragma omp declare simd'. Patch adds mangling for simd
>> functions in accordance with
>> https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt
>>
>> Added:
>>  cfe/trunk/test/OpenMP/declare_simd_codegen.cpp
>> Modified:
>>  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>>  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
>>  cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=268721=268720=268721=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri May  6 04:40:08
>> 2016
>> @@ -6042,3 +6042,228 @@ void CGOpenMPRuntime::emitTargetEnterOrE
>>   ThenGenRCG(CGF);
>> }
>>   }
>> +
>> +namespace {
>> +  /// Kind of parameter in a function with 'declare simd' directive.
>> +  enum ParamKindTy { LinearWithVarStride, Linear, Uniform, Vector };
>> +  /// Attribute set of the parameter.
>> +  struct ParamAttrTy {
>> +ParamKindTy Kind = Vector;
>> +llvm::APSInt StrideOrArg;
>> +llvm::APSInt Alignment;
>> +  };
>> +} // namespace
>> +
>> +static unsigned evaluateCDTSize(const FunctionDecl *FD,
>> +ArrayRef ParamAttrs) {
>> +  // Every vector variant of a SIMD-enabled function has a vector
>> length (VLEN).
>> +  // If OpenMP clause "simdlen" is used, the VLEN is the value of
>> the argument
>> +  // of that clause. The VLEN value must be power of 2.
>> +  // In other case the notion of the function`s "characteristic data
>> type" (CDT)
>> +  // is used to compute the vector length.
>> +  // CDT is defined in the following order:
>> +  //   a) For non-void function, the CDT is the return type.
>> +  //   b) If the function has any non-uniform, non-linear
>> parameters, then the
>> +  //   CDT is the type of the first such parameter.
>> +  //   c) If the CDT determined by a) or b) above is struct, union,
>> or class
>> +  //   type which is pass-by-value (except for the type that maps to
>> the
>> +  //   built-in complex data type), the characteristic data type is
>> int.
>> +  //   d) If none of the above three cases is applicable, the CDT is
>> int.
>> +  // The VLEN is then determined based on the CDT and the size of
>> vector
>> +  // register of that ISA for which current vector version is
>> generated. The
>> +  // VLEN is computed using the formula below:
>> +  //   VLEN  = sizeof(vector_register) / sizeof(CDT),
>> +  // where vector register size specified in section 3.2.1 Registers
>> and the
>> +  // Stack Frame of original AMD64 ABI document.
>> +  QualType RetType = FD->getReturnType();
>> +  if (RetType.isNull())
>> +return 0;
>> +  ASTContext  = FD->getASTContext();
>> +  QualType CDT;
>> +  if (!RetType.isNull() && !RetType->isVoidType())
>> +CDT = RetType;
>> +  else {
>> +unsigned Offset = 0;
>> +if (auto *MD = dyn_cast(FD)) {
>> +  if (ParamAttrs[Offset].Kind == Vector)
>> +CDT = C.getPointerType(C.getRecordType(MD->getParent()));
>> +  ++Offset;
>> +}
>> +if

[PATCH] D20194: [ModuleMap][CrashReproducer] Collect headers from inner frameworks

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

bruno created this revision.
bruno added a reviewer: benlangmuir.
bruno added a subscriber: cfe-commits.

(1) Collect headers under inner frameworks (frameworks inside other
other frameworks).
(2) Make sure we also collect the right header files inside them.

More info on (2):

Consider a dummy framework module B, with header Frameworks/B/B.h. Now
consider that another framework A, with header Frameworks/A/A.h, has a
layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the
"B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that
Frameworks/A/A.h includes .

When parsing header Frameworks/A/A.h, framework module lookup is
performed in search for B, and it happens that
"Frameworks/A/Frameworks/B/B.h" path is registered in the module instead
of real "Frameworks/B/B.h". This occurs because
"Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager,
when looking for inner framework modules under Frameworks/A/Frameworks.
This makes Frameworks/A/Frameworks/B/B.h the default cached named inside
the FileManager for the B.h file UID.

This leads to modules being built without consistent paths to underlying
header files. This is usually not a problem in regular compilation flow,
but it's an issue when running the crash reproducer. The issue is that
clangs collect "Frameworks/A/Frameworks/B/B.h" but not
"Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So
make sure we also collect the original header.

http://reviews.llvm.org/D20194

Files:
  lib/Lex/ModuleMap.cpp
  test/Modules/Inputs/crash-recovery/Frameworks/A.framework/Headers/A.h
  test/Modules/Inputs/crash-recovery/Frameworks/B.framework/Headers/B.h
  
test/Modules/Inputs/crash-recovery/Frameworks/B.framework/Modules/module.modulemap
  test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Headers/I.h
  
test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Modules/module.modulemap
  test/Modules/Inputs/crash-recovery/Frameworks/module.modulemap
  test/Modules/crash-vfs-umbrella-frameworks.m

Index: test/Modules/crash-vfs-umbrella-frameworks.m
===
--- /dev/null
+++ test/Modules/crash-vfs-umbrella-frameworks.m
@@ -0,0 +1,42 @@
+// REQUIRES: crash-recovery, shell
+
+// FIXME: This XFAIL is cargo-culted from crash-report.c. Do we need it?
+// XFAIL: mingw32
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t/i %t/m %t
+// RUN: cp -a %S/Inputs/crash-recovery/Frameworks %t/i/
+// RUN: mkdir -p %t/i/Frameworks/A.framework/Frameworks
+// RUN: ln -s ../../B.framework %t/i/Frameworks/A.framework/Frameworks/B.framework
+
+// RUN: not env FORCE_CLANG_DIAGNOSTICS_CRASH= TMPDIR=%t TEMP=%t TMP=%t \
+// RUN: %clang -nostdinc -fsyntax-only %s \
+// RUN: -F %/t/i/Frameworks -fmodules \
+// RUN: -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
+
+// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
+// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
+// RUN: find %t/crash-vfs-*.cache/vfs | \
+// RUN:   grep "B.framework/Headers/B.h" | count 1
+
+// CHECK: Preprocessed source(s) and associated run script(s) are located at:
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+
+// CHECKYAML:  'type': 'directory',
+// CHECKYAML:  'name': "/[[PATH:.*]]/i/Frameworks/A.framework/Frameworks/B.framework/Headers",
+// CHECKYAML-NEXT:  'contents': [
+// CHECKYAML-NEXT:{
+// CHECKYAML-NEXT:  'type': 'file',
+// CHECKYAML-NEXT:  'name': "B.h",
+// CHECKYAML-NEXT:  'external-contents': "/[[PATH]]/i/Frameworks/B.framework/Headers/B.h"
+
+// CHECKYAML:  'type': 'directory',
+// CHECKYAML:  'name': "/[[PATH]]/i/Frameworks/B.framework/Headers",
+// CHECKYAML-NEXT:  'contents': [
+// CHECKYAML-NEXT:{
+// CHECKYAML-NEXT:  'type': 'file',
+// CHECKYAML-NEXT:  'name': "B.h",
+// CHECKYAML-NEXT:  'external-contents': "/[[PATH]]/i/Frameworks/B.framework/Headers/B.h"
+
+@import I;
Index: test/Modules/Inputs/crash-recovery/Frameworks/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/crash-recovery/Frameworks/module.modulemap
@@ -0,0 +1,2 @@
+framework module * [extern_c] {
+}
Index: test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Modules/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Modules/module.modulemap
@@ -0,0 +1,5 @@
+framework module I [extern_c] {
+  umbrella header "I.h"
+  export *
+  module * { export * }
+}
Index: test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Headers/I.h
===
--- /dev/null
+++ test/Modules/Inputs/crash-recovery/Frameworks/I.framework/Headers/I.h
@@ -0,0 +1,2 @@
+
+#import 
Index:

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread Sean Silva via cfe-commits

On Wed, May 11, 2016 at 10:46 AM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> > I'm glad to help, but it makes me uneasy to have somebody working on a
> > filesystem abstraction that does not have ready access to test and debug
> > their changes across the major host platforms that LLVM supports (linux,
> > mac, windows). Is there any way you can get access? I don't think that
> > windows 10 is critical here; win7 or win8 are fine.
>
> I'm mostly trying to make the crash reproducers to work on Darwin;


What are the platform-specifics for crash reproducing? Shouldn't it
basically be saving some files and storing some data for reconstructing?
We've recently been working on a `--reproduce` for LLD and we haven't
needed any ifdefs for windows (some tests that rely on really long path
names need to be turned off, but the feature still works).

-- Sean Silva


> the
> improvements to VFS are in fact side-effects here, not something I'm
> working full time on. It would be awesome to have it working on other
> platforms out-of-the-box, but I just don't have the bandwidth to do
> it. That said, I'm gonna make sure we don't regress on windows, but
> unless I have help or get time to setup such machine, I can't
> guarantee this improvements are going to be supported on windows.
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D20192: [Sema] Fix bug to do with lookup of template friend function in namespace

2016-05-11 Thread Erik Pilkington via cfe-commits

erik.pilkington created this revision.
erik.pilkington added a reviewer: rsmith.
erik.pilkington added a subscriber: cfe-commits.

Clang erroneously rejects the following code because it does not find the 
default argument for `makeType` :

```
namespace n {
  template  struct Type {
template  friend Type makeType();
  };

  template  Type makeType();

  void f() {
Type t;
n::makeType<>(); // Error, lookup finds wrong version of makeType
  }
} // end namespace n
```

The problem is that during instantiation of `Type` on the previous line 
the default template argument version of `makeType` is incorrectly swapped out 
of `DeclContext::LookupPtr` for the friend version. This patch fixes that by 
disallowing the swap in `NamedDecl::declarationReplaces()`.

This patch looks like it's a fix for PR10856, PR18038, PR20877, and PR26962.


http://reviews.llvm.org/D20192

Files:
  lib/AST/Decl.cpp
  test/SemaTemplate/friend-template.cpp

Index: test/SemaTemplate/friend-template.cpp
===
--- test/SemaTemplate/friend-template.cpp
+++ test/SemaTemplate/friend-template.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 // PR5057
 namespace test0 {
   namespace std {
@@ -69,16 +69,13 @@
 
   template struct X2a;
 
-  template struct X2b;
+  template struct X2b; // expected-note {{previous 
non-type template parameter with type 'int' is here}}
 
   template
   class X3 {
 template friend struct X2a;
 
-// FIXME: the redeclaration note ends up here because redeclaration
-// lookup ends up finding the friend target from X3.
-template friend struct X2b; // expected-error 
{{template non-type parameter has a different type 'long' in template 
redeclaration}} \
-  // expected-note {{previous non-type template parameter with type 'int' 
is here}}
+template friend struct X2b; // expected-error 
{{template non-type parameter has a different type 'long' in template 
redeclaration}}
   };
 
   X3 x3i; // okay
@@ -297,14 +294,10 @@
   int n = C::D().f();
 
   struct F {
-template struct G;
+template struct G; // expected-note {{previous non-type template 
parameter with type 'int' is here}}
   };
   template struct H {
-// FIXME: As with cases above, the note here is on an unhelpful 
declaration,
-// and should point to the declaration of G within F.
-template friend struct F::G; // \
-  // expected-error {{different type 'char' in template redeclaration}} \
-  // expected-note {{previous}}
+template friend struct F::G; // expected-error {{different type 'char' 
in template redeclaration}}
   };
   H h1; // ok
   H h2; // expected-note {{instantiation}}
@@ -329,3 +322,16 @@
 foo(b); // expected-note {{in instantiation}}
   }
 }
+
+namespace PR26962 {
+template  struct Type {
+  template  friend Type makeType();
+};
+
+template  Type makeType();
+
+void f() {
+  Type t;
+  PR26962::makeType<>();
+}
+} // end PR26962
Index: lib/AST/Decl.cpp
===
--- lib/AST/Decl.cpp
+++ lib/AST/Decl.cpp
@@ -1520,6 +1520,10 @@
   if (OldD->isFromASTFile() && isFromASTFile())
 return false;
 
+  // Do not replace a declaration with a friend.
+  if (getFriendObjectKind() != FOK_None)
+return false;
+
   // A kind mismatch implies that the declaration is not replaced.
   if (OldD->getKind() != getKind())
 return false;


Index: test/SemaTemplate/friend-template.cpp
===
--- test/SemaTemplate/friend-template.cpp
+++ test/SemaTemplate/friend-template.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
 // PR5057
 namespace test0 {
   namespace std {
@@ -69,16 +69,13 @@
 
   template struct X2a;
 
-  template struct X2b;
+  template struct X2b; // expected-note {{previous non-type template parameter with type 'int' is here}}
 
   template
   class X3 {
 template friend struct X2a;
 
-// FIXME: the redeclaration note ends up here because redeclaration
-// lookup ends up finding the friend target from X3.
-template friend struct X2b; // expected-error {{template non-type parameter has a different type 'long' in template redeclaration}} \
-  // expected-note {{previous non-type template parameter with type 'int' is here}}
+template friend struct X2b; // expected-error {{template non-type parameter has a different type 'long' in template redeclaration}}
   };
 
   X3 x3i; // okay
@@ -297,14 +294,10 @@
   int n = C::D().f();
 
   struct F {
-template struct G;
+template struct G; // expected-note {{previous non-type template parameter with type 'int' is here}}
   };
   template struct H {
-// FIXME: As with cases above, the note here is on an unhelpful declaration,
-// and should point to the declaration

r269257 - [tooling] Remove redundant inline keyword

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 19:22:28 2016
New Revision: 269257

URL: http://llvm.org/viewvc/llvm-project?rev=269257=rev
Log:
[tooling] Remove redundant inline keyword

Summary:
The inline keywords are redundant.
Introduce by this commit to try to fix broken build bots:
  http://reviews.llvm.org/D20180

Tested on Debug and Release build [linux].
Tested on Release + Shared (-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON) 
[linux]
Tested on Release [windows]

Reviewers: alexfh

Subscribers: cfe-commits, klimek

Differential Revision: http://reviews.llvm.org/D20189

Modified:
cfe/trunk/include/clang/Tooling/FixIt.h

Modified: cfe/trunk/include/clang/Tooling/FixIt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/FixIt.h?rev=269257=269256=269257=diff
==
--- cfe/trunk/include/clang/Tooling/FixIt.h (original)
+++ cfe/trunk/include/clang/Tooling/FixIt.h Wed May 11 19:22:28 2016
@@ -40,26 +40,26 @@ inline SourceRange getSourceRange(const
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  inline SourceRange getSourceRange(const T ) {
+template  SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-inline StringRef getText(const T , const ASTContext ) {
+StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  inline FixItHint createRemoval(const T ) {
+template  FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-inline FixItHint createReplacement(const D , const S ,
+FixItHint createReplacement(const D , const S ,
const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));


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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-05-11 Thread don hinton via cfe-commits

hintonda added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:36
@@ +35,3 @@
+
+bool UseNoexceptCheck::helper(const MatchFinder::MatchResult ,
+  const SourceRange ,

alexfh wrote:
> The name "helper" doesn't say much. I'm sure we can come up with a much more 
> useful name. The interface could also be more convenient. It looks like this 
> function could return a `FixItHint` (which could possibly be `isNull()`, if 
> no replacement is possible/needed). It could also use an 
> `Optional` or some other way to inform the caller that there's no 
> action required.
Happy to rename it, but not sure making it more convenient serves much of a 
purpose.  For this checker, we either find a dynamic exception specification 
and produce a FixItHint, or we don't.  

Did you have some other behavior you wanted me to add?


http://reviews.llvm.org/D18575



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

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb added a comment.

In http://reviews.llvm.org/D20180#427893, @rnk wrote:

> In http://reviews.llvm.org/D20180#427840, @alexfh wrote:
>
> > `inline` seems to be completely redundant here. Can you try removing it and 
> > running whatever build configurations were failing without 
> > http://reviews.llvm.org/D20182?
>
>
> My bad, it's explicit function template specializations that need to be 
> marked inline when in headers.

Hmm, it's my bad! I tried it to solve broken bot.
 I try it that way because it is implemented with "inline" in 
ASTMatcherInternal:

Example:

  template <>
  inline const Stmt *GetBodyMatcher::get(const FunctionDecl 
) {
return Node.doesThisDeclarationHaveABody() ? Node.getBody() : nullptr;
  }

But, it's "explicit template specialisation" in the above case.

Revert patch is ready: http://reviews.llvm.org/D20189

Still thanks Reid for helping finding the repro case.

Repository:
  rL LLVM

http://reviews.llvm.org/D20180

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

Re: [PATCH] D20189: [tooling] Remove redundant inline keyword

2016-05-11 Thread Alexander Kornienko via cfe-commits

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

LG


http://reviews.llvm.org/D20189



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh requested changes to this revision.
This revision now requires changes to proceed.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:36
@@ +35,3 @@
+
+bool UseNoexceptCheck::helper(const MatchFinder::MatchResult ,
+  const SourceRange ,

The name "helper" doesn't say much. I'm sure we can come up with a much more 
useful name. The interface could also be more convenient. It looks like this 
function could return a `FixItHint` (which could possibly be `isNull()`, if no 
replacement is possible/needed). It could also use an `Optional` or 
some other way to inform the caller that there's no action required.


http://reviews.llvm.org/D18575



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

[libcxxabi] r269255 - libc++abi: make __cxa_call_unexpected visible

2016-05-11 Thread Saleem Abdulrasool via cfe-commits

Author: compnerd
Date: Wed May 11 18:56:37 2016
New Revision: 269255

URL: http://llvm.org/viewvc/llvm-project?rev=269255=rev
Log:
libc++abi: make __cxa_call_unexpected visible

This may be invoked by the compiler, and needs to be made available so that the
users can reference it.

Modified:
libcxxabi/trunk/src/cxa_personality.cpp

Modified: libcxxabi/trunk/src/cxa_personality.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_personality.cpp?rev=269255=269254=269255=diff
==
--- libcxxabi/trunk/src/cxa_personality.cpp (original)
+++ libcxxabi/trunk/src/cxa_personality.cpp Wed May 11 18:56:37 2016
@@ -1166,7 +1166,7 @@ __gxx_personality_v0(_Unwind_State state
 
 
 __attribute__((noreturn))
-void
+_LIBCXXABI_FUNC_VIS void
 __cxa_call_unexpected(void* arg)
 {
 _Unwind_Exception* unwind_exception = static_cast<_Unwind_Exception*>(arg);


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

[PATCH] D20189: [tooling] Remove redundant inline keyword

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb created this revision.
etienneb added a reviewer: alexfh.
etienneb added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

The inline keywords are redundant.
Introduce by this commit to try to fix broken build bots:
  http://reviews.llvm.org/D20180

Tested on Debug and Release build [linux].
Tested on Release + Shared (-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON) 
[linux]
Tested on Release [windows]

http://reviews.llvm.org/D20189

Files:
  include/clang/Tooling/FixIt.h

Index: include/clang/Tooling/FixIt.h
===
--- include/clang/Tooling/FixIt.h
+++ include/clang/Tooling/FixIt.h
@@ -40,26 +40,26 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  inline SourceRange getSourceRange(const T ) {
+template  SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-inline StringRef getText(const T , const ASTContext ) {
+StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  inline FixItHint createRemoval(const T ) {
+template  FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-inline FixItHint createReplacement(const D , const S ,
+FixItHint createReplacement(const D , const S ,
const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));


Index: include/clang/Tooling/FixIt.h
===
--- include/clang/Tooling/FixIt.h
+++ include/clang/Tooling/FixIt.h
@@ -40,26 +40,26 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  inline SourceRange getSourceRange(const T ) {
+template  SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-inline StringRef getText(const T , const ASTContext ) {
+StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  inline FixItHint createRemoval(const T ) {
+template  FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-inline FixItHint createReplacement(const D , const S ,
+FixItHint createReplacement(const D , const S ,
const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Reid Kleckner via cfe-commits

rnk added a comment.

In http://reviews.llvm.org/D20180#427840, @alexfh wrote:

> `inline` seems to be completely redundant here. Can you try removing it and 
> running whatever build configurations were failing without 
> http://reviews.llvm.org/D20182?

My bad, it's explicit function template specializations that need to be marked 
inline when in headers.

Repository:
  rL LLVM

http://reviews.llvm.org/D20180

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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-05-11 Thread don hinton via cfe-commits

hintonda updated this revision to Diff 56984.
hintonda added a comment.

Created helper function and moved most logic there.  Also address a
few comments.


http://reviews.llvm.org/D18575

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  clang-tidy/modernize/UseOverrideCheck.cpp
  clang-tidy/utils/LexerUtils.cpp
  clang-tidy/utils/LexerUtils.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/modernize-use-noexcept.rst
  test/clang-tidy/modernize-use-noexcept-macro.cpp
  test/clang-tidy/modernize-use-noexcept.cpp

Index: test/clang-tidy/modernize-use-noexcept.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept.cpp
@@ -0,0 +1,22 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A{};
+class B{};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foo' uses dynamic exception specification 'throw()'; use 'noexcept' instead [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw(...)'; use 'noexcept(false)' instead [modernize-use-noexcept]
+// CHECK-FIXES: void bar() noexcept(false);
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'foobar' uses dynamic exception specification 'throw(A, B)'; use 'noexcept(false)' instead [modernize-use-noexcept]
+// CHECK-FIXES: void foobar() noexcept(false)
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+#define NOEXCEPT noexcept
+
+void bar() throw() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw()'; use 'NOEXCEPT' instead [modernize-use-noexcept]
+// CHECK-FIXES: void bar() NOEXCEPT {}
+
+// Should not trigger a replacement.
+void foo() noexcept(true);
+
Index: docs/clang-tidy/checks/modernize-use-noexcept.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-use-noexcept.rst
@@ -0,0 +1,50 @@
+.. title:: clang-tidy - modernize-use-noexcept
+
+modernize-use-noexcept
+==
+
+The check converts dynamic exception specifications, e.g., throw(),
+throw([,...]), or throw(...) to noexcept, noexcept(false),
+or a user defined macro.
+
+Example
+---
+
+.. code-block:: c++
+
+  void foo() throw();
+	void bar() throw(int) {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() noexcept;
+	void bar() noexcept(false) {}
+
+
+User defined macros
+---
+
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with
+``noexcept(false)``.  Additinally, users can also use
+:option:``ReplacementString`` to specify a macro to use instead of
+``noexcept``.  This is useful when maintaining source code that must
+be compiled with older compilers that don't support the ``noexcept``
+keyword.
+
+Example
+^^^
+
+.. code-block:: c++
+
+  void foo() throw() {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() NOEXCEPT {}
+
+if the ``ReplacementString`` option is set to ``NOEXCEPT``.
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -191,6 +191,11 @@
   Selectively replaces string literals containing escaped characters with raw
   string literals.
 
+- New `modernize-use-noexcept
+  `_ check
+
+  Replaces dynamic exception specifications with noexcept.
+
 - New `performance-faster-string-find
   `_ check
 
Index: clang-tidy/utils/LexerUtils.h
===
--- clang-tidy/utils/LexerUtils.h
+++ clang-tidy/utils/LexerUtils.h
@@ -12,6 +12,7 @@
 
 #include "clang/AST/ASTContext.h"
 #include "clang/Lex/Lexer.h"
+#include "llvm/ADT/SmallVector.h"
 
 namespace clang {
 namespace tidy {
@@ -23,6 +24,10 @@
 Token getPreviousNonCommentToken(const ASTContext ,
  SourceLocation Location);
 
+SmallVector ParseTokens(const ASTContext ,
+   const SourceManager ,
+

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb added a comment.

I'm sure you're right: they are redundant keywords.
I'm preparing the revert patch, and I'm running tests over multiple build types.


Repository:
  rL LLVM

http://reviews.llvm.org/D20180



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

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh added a subscriber: alexfh.
alexfh added a comment.

`inline` seems to be completely redundant here. Can you try removing it and 
running whatever build configurations were failing without 
http://reviews.llvm.org/D20182?


Repository:
  rL LLVM

http://reviews.llvm.org/D20180



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

Re: [PATCH] D20182: [clang-tidy] Add missing dependency of libtooling to misc module

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

LG. Thanks for fixing.


Repository:
  rL LLVM

http://reviews.llvm.org/D20182



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

Re: [PATCH] D18424: [Clang] Fix Clang-tidy modernize-deprecated-headers warnings; other minor fixes

2016-05-11 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko updated this revision to Diff 56959.
Eugene.Zelenko added a comment.
Herald added subscribers: dschuff, jfb.

Updated from trunk. More Include What You Use warnings fixes.


Repository:
  rL LLVM

http://reviews.llvm.org/D18424

Files:
  include/clang-c/Index.h
  include/clang/Analysis/Analyses/ThreadSafetyTIL.h
  include/clang/Basic/Linkage.h
  include/clang/Basic/TargetBuiltins.h
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/Driver/Types.cpp
  lib/Frontend/CodeGenOptions.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Lex/HeaderSearch.cpp
  lib/Lex/ModuleMap.cpp
  lib/Sema/DelayedDiagnostic.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Tooling/Core/QualTypeNames.cpp
  tools/libclang/CIndexDiagnostic.h
  unittests/libclang/LibclangTest.cpp

Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -12,23 +12,35 @@
 //===--===//
 
 #include "clang/Serialization/ASTWriter.h"
-#include "clang/Serialization/ModuleFileExtension.h"
 #include "ASTCommon.h"
 #include "ASTReaderInternals.h"
 #include "MultiOnDiskHashTable.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTUnresolvedSet.h"
+#include "clang/AST/Attr.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclContextInternals.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclFriend.h"
-#include "clang/AST/DeclLookups.h"
+#include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/LambdaCapture.h"
+#include "clang/AST/NestedNameSpecifier.h"
+#include "clang/AST/RawCommentList.h"
+#include "clang/AST/TemplateName.h"
 #include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
 #include "clang/AST/TypeLocVisitor.h"
+#include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
-#include "clang/Basic/FileSystemStatCache.h"
+#include "clang/Basic/FileSystemOptions.h"
+#include "clang/Basic/Lambda.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/Module.h"
+#include "clang/Basic/ObjCRuntime.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/SourceManagerInternals.h"
 #include "clang/Basic/TargetInfo.h"
@@ -38,29 +50,50 @@
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/HeaderSearchOptions.h"
 #include "clang/Lex/MacroInfo.h"
+#include "clang/Lex/ModuleMap.h"
 #include "clang/Lex/PreprocessingRecord.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/PreprocessorOptions.h"
+#include "clang/Lex/Token.h"
 #include "clang/Sema/IdentifierResolver.h"
+#include "clang/Sema/ObjCMethodList.h"
 #include "clang/Sema/Sema.h"
+#include "clang/Sema/Weak.h"
 #include "clang/Serialization/ASTReader.h"
+#include "clang/Serialization/Module.h"
+#include "clang/Serialization/ModuleFileExtension.h"
 #include "clang/Serialization/SerializationDiagnostic.h"
 #include "llvm/ADT/APFloat.h"
 #include "llvm/ADT/APInt.h"
+#include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/IntrusiveRefCntPtr.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/Bitcode/BitCodes.h"
 #include "llvm/Bitcode/BitstreamWriter.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/Support/Compression.h"
 #include "llvm/Support/EndianStream.h"
-#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/OnDiskHashTable.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 using namespace clang;
 using namespace clang::serialization;
@@ -83,6 +116,7 @@
 //===--===//
 
 namespace clang {
+
   class ASTTypeWriter {
 ASTWriter 
 ASTRecordWriter Record;
@@ -127,6 +161,7 @@
 #define ABSTRACT_TYPE(Class, Base)
 #include "clang/AST/TypeNodes.def"
   };
+
 } // end namespace clang
 
 void ASTTypeWriter::VisitBuiltinType(const BuiltinType *T) {
@@ -516,28 +551,36 @@
 void TypeLocWriter::VisitComplexTypeLoc(ComplexTypeLoc TL) {
   Record.AddSourceLocation(TL.getNameLoc());
 }
+
 void TypeLocWriter::VisitPointerTypeLoc(PointerTypeLoc TL) {
   Record.AddSourceLocation(TL.getStarLoc());
 }
+
 void TypeLocWriter::VisitDecayedTypeLoc(DecayedTypeLoc TL) {
   // nothing to do
 }
+
 void TypeLocWriter::VisitAdjustedTypeLoc(AdjustedTypeLoc TL) {
   // nothing to do
 }
+
 void TypeLocWriter::VisitBlockPointerTypeLoc(BlockPointerTypeLoc TL) {
   Record.AddSourceLocation(TL.getCaretLoc());
 }
+
 void

r269242 - Fixed msvc warnings

2016-05-11 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Wed May 11 16:55:37 2016
New Revision: 269242

URL: http://llvm.org/viewvc/llvm-project?rev=269242=rev
Log:
Fixed msvc warnings

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=269242=269241=269242=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Wed May 11 16:55:37 2016
@@ -775,6 +775,7 @@ static const char* getSectionNameForBitc
   case Triple::UnknownObjectFormat:
 return ".llvmbc";
   }
+  llvm_unreachable("Unimplemented ObjectFormatType");
 }
 
 static const char* getSectionNameForCommandline(const Triple ) {
@@ -786,6 +787,7 @@ static const char* getSectionNameForComm
   case Triple::UnknownObjectFormat:
 return ".llvmcmd";
   }
+  llvm_unreachable("Unimplemented ObjectFormatType");
 }
 
 // With -fembed-bitcode, save a copy of the llvm IR as data in the


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

Re: Patch submission for bug 27400

2016-05-11 Thread Vedant Kumar via cfe-commits

Hi,

Thanks for the patch!

This patch is missing a small, lit-style test case. You can find examples of 
test cases here:

  extra/test/clang-tidy/

Apart from that, my only other nit-pick is that llvm uses 2-space indents, and 
spaces between "if" and "(".

If you reply to this list with an updated patch, someone would be happy to 
commit it for you.

best
vedant

> On May 11, 2016, at 10:01 AM, Mads Ravn via cfe-commits 
>  wrote:
> 
> Hi,
> 
> I would like to submit a patch for 
> https://llvm.org/bugs/show_bug.cgi?id=27400 . 
> 
> Beside attaching the patch, is there anything I should be aware of? I have 
> not submitted a patch before.
> 
> You can find the patch attached to this mail.
> 
> Kind regards,
> Mads Ravn
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

Re: [PATCH] D20182: [clang-tidy] Add missing dependency of libtooling to misc module

2016-05-11 Thread Etienne Bergeron via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269240: [clang-tidy] Add missing dependency of libtooling to 
misc module (authored by etienneb).

Changed prior to commit:
  http://reviews.llvm.org/D20182?vs=56963=56966#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20182

Files:
  clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt

Index: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
@@ -50,4 +50,5 @@
   clangLex
   clangTidy
   clangTidyUtils
+  clangTooling
   )


Index: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
@@ -50,4 +50,5 @@
   clangLex
   clangTidy
   clangTidyUtils
+  clangTooling
   )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r269240 - [clang-tidy] Add missing dependency of libtooling to misc module

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 16:32:29 2016
New Revision: 269240

URL: http://llvm.org/viewvc/llvm-project?rev=269240=rev
Log:
[clang-tidy] Add missing dependency of libtooling to misc module

Summary:
The new API for fixit is in libtooling and the library misc in clang-tidy
didn't had the appropriate dependency.

This commit was breaking some build bots:
http://reviews.llvm.org/D19547

This commit tried (but failed) to fix it:
http://reviews.llvm.org/D20180

To repro, you can make a build with these flags:
```
cmake -DBUILD_SHARED_LIBS=ON
```

Thanks rnk@ for helping figuring out.

Reviewers: alexfh, rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20182

Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=269240=269239=269240=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Wed May 11 16:32:29 
2016
@@ -50,4 +50,5 @@ add_clang_library(clangTidyMiscModule
   clangLex
   clangTidy
   clangTidyUtils
+  clangTooling
   )


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

Re: [PATCH] D20132: [libclang] Add clang_getAllSkippedRanges function

2016-05-11 Thread Cameron via cfe-commits

cameron314 updated this revision to Diff 56964.
cameron314 added a comment.

Here's a test!


http://reviews.llvm.org/D20132

Files:
  include/clang-c/Index.h
  tools/libclang/CIndex.cpp
  unittests/libclang/LibclangTest.cpp

Index: unittests/libclang/LibclangTest.cpp
===
--- unittests/libclang/LibclangTest.cpp
+++ unittests/libclang/LibclangTest.cpp
@@ -15,6 +15,9 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
+#include 
+#include 
 #define DEBUG_TYPE "libclang-test"
 
 TEST(libclang, clang_parseTranslationUnit2_InvalidArgs) {
@@ -349,21 +352,25 @@
   clang_ModuleMapDescriptor_dispose(MMD);
 }
 
-class LibclangReparseTest : public ::testing::Test {
+class LibclangParseTest : public ::testing::Test {
   std::set Files;
+  typedef std::unique_ptr fixed_addr_string;
+  std::map UnsavedFileContents;
 public:
   std::string TestDir;
   CXIndex Index;
   CXTranslationUnit ClangTU;
   unsigned TUFlags;
+  std::vector UnsavedFiles;
 
   void SetUp() override {
 llvm::SmallString<256> Dir;
 ASSERT_FALSE(llvm::sys::fs::createUniqueDirectory("libclang-test", Dir));
 TestDir = Dir.str();
 TUFlags = CXTranslationUnit_DetailedPreprocessingRecord |
-  clang_defaultEditingTranslationUnitOptions();
+  clang_defaultEditingTranslationUnitOptions();
 Index = clang_createIndex(0, 0);
+ClangTU = nullptr;
   }
   void TearDown() override {
 clang_disposeTranslationUnit(ClangTU);
@@ -384,6 +391,77 @@
 OS << Contents;
 assert(OS.good());
   }
+  void MapUnsavedFile(std::string Filename, const std::string ) {
+if (!llvm::sys::path::is_absolute(Filename)) {
+  llvm::SmallString<256> Path(TestDir);
+  llvm::sys::path::append(Path, Filename);
+  Filename = Path.str();
+}
+auto it = UnsavedFileContents.emplace(
+fixed_addr_string(new std::string(Filename)),
+fixed_addr_string(new std::string(Contents)));
+UnsavedFiles.push_back({
+it.first->first->c_str(),   // filename
+it.first->second->c_str(),  // contents
+it.first->second->size()// length
+});
+  }
+  template
+  void Traverse(const F ) {
+CXCursor TuCursor = clang_getTranslationUnitCursor(ClangTU);
+std::reference_wrapper FunctorRef = std::cref(TraversalFunctor);
+clang_visitChildren(TuCursor,
+,
+);
+  }
+private:
+  template
+  static CXChildVisitResult TraverseStateless(CXCursor cx, CXCursor parent,
+  CXClientData data) {
+TState *State = static_cast(data);
+return State->get()(cx, parent);
+  }
+};
+
+TEST_F(LibclangParseTest, AllSkippedRanges) {
+  std::string Header = "header.h", Main = "main.cpp";
+  WriteFile(Header,
+"#ifdef MANGOS\n"
+"printf(\"mmm\");\n"
+"#endif");
+  WriteFile(Main,
+"#include \"header.h\"\n"
+"#ifdef KIWIS\n"
+"printf(\"mmm!!\");\n"
+"#endif");
+
+  ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
+   nullptr, 0, TUFlags);
+
+  CXSourceRangeList *Ranges = clang_getAllSkippedRanges(ClangTU);
+  EXPECT_EQ(2, Ranges->count);
+  
+  CXSourceLocation cxl;
+  unsigned line;
+  cxl = clang_getRangeStart(Ranges->ranges[0]);
+  clang_getSpellingLocation(cxl, nullptr, , nullptr, nullptr);
+  EXPECT_EQ(1, line);
+  cxl = clang_getRangeEnd(Ranges->ranges[0]);
+  clang_getSpellingLocation(cxl, nullptr, , nullptr, nullptr);
+  EXPECT_EQ(3, line);
+
+  cxl = clang_getRangeStart(Ranges->ranges[1]);
+  clang_getSpellingLocation(cxl, nullptr, , nullptr, nullptr);
+  EXPECT_EQ(2, line);
+  cxl = clang_getRangeEnd(Ranges->ranges[1]);
+  clang_getSpellingLocation(cxl, nullptr, , nullptr, nullptr);
+  EXPECT_EQ(4, line);
+
+  clang_disposeSourceRangeList(Ranges);
+}
+
+class LibclangReparseTest : public LibclangParseTest {
+public:
   void DisplayDiagnostics() {
 unsigned NumDiagnostics = clang_getNumDiagnostics(ClangTU);
 for (unsigned i = 0; i < NumDiagnostics; ++i) {
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -7680,6 +7680,33 @@
   return skipped;
 }
 
+CXSourceRangeList *clang_getAllSkippedRanges(CXTranslationUnit TU) {
+  CXSourceRangeList *skipped = new CXSourceRangeList;
+  skipped->count = 0;
+  skipped->ranges = nullptr;
+
+  if (isNotUsableTU(TU)) {
+LOG_BAD_TU(TU);
+return skipped;
+  }
+
+  ASTUnit *astUnit = cxtu::getASTUnit(TU);
+  PreprocessingRecord *ppRec = astUnit->getPreprocessor().getPreprocessingRecord();
+  if (!ppRec)
+return skipped;
+
+  ASTContext  = astUnit->getASTContext();
+
+  const std::vector  = ppRec->getSkippedRanges();
+
+  skipped->count = SkippedRanges.size();
+  skipped->ranges = new CXSourceRange[skipped->count];
+  for (unsigned i = 0, ei = skipped->count; i != ei; ++i)
+

Re: [PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

2016-05-11 Thread Nico Weber via cfe-commits

thakis added a comment.

Ok, that seems fine then. Thanks much for checking!


http://reviews.llvm.org/D20136



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

[PATCH] D20182: [clang-tidy] Add missing dependency of libtooling to misc module

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb created this revision.
etienneb added reviewers: alexfh, rnk.
etienneb added a subscriber: cfe-commits.

The new API for fixit is in libtooling and the library misc in clang-tidy
didn't had the appropriate dependency.

This commit was breaking some build bots:
http://reviews.llvm.org/D19547

This commit tried (but failed) to fix it:
http://reviews.llvm.org/D20180

To repro, you can make a build with these flags:
```
cmake -DBUILD_SHARED_LIBS=ON
```

Thanks rnk@ for helping figuring out.

http://reviews.llvm.org/D20182

Files:
  clang-tidy/misc/CMakeLists.txt

Index: clang-tidy/misc/CMakeLists.txt
===
--- clang-tidy/misc/CMakeLists.txt
+++ clang-tidy/misc/CMakeLists.txt
@@ -50,4 +50,5 @@
   clangLex
   clangTidy
   clangTidyUtils
+  clangTooling
   )


Index: clang-tidy/misc/CMakeLists.txt
===
--- clang-tidy/misc/CMakeLists.txt
+++ clang-tidy/misc/CMakeLists.txt
@@ -50,4 +50,5 @@
   clangLex
   clangTidy
   clangTidyUtils
+  clangTooling
   )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20131: Fixed crash during code completion in file included within declaration

2016-05-11 Thread Cameron via cfe-commits

cameron314 added inline comments.


Comment at: lib/Lex/PPLexerChange.cpp:380-383
@@ -379,4 +379,6 @@
 CurLexer->FormTokenWithChars(Result, CurLexer->BufferEnd, tok::eof);
 CurLexer.reset();
+if (CurLexerKind == CLK_Lexer)
+  CurLexerKind = CLK_CachingLexer;
   } else {
 assert(CurPTHLexer && "Got EOF but no current lexer set!");

Ah, wait, yes this also prevents the crash if I remove the `CurLexer.reset()` 
and use `CurLexer->cutOffLexing()`, but it not only produces an error about a 
missing '}', but an error about an extra '}' just after, which doesn't really 
make sense. That means it's inspecting tokens past the EOF that was injected.


http://reviews.llvm.org/D20131



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

Re: [PATCH] D20131: Fixed crash during code completion in file included within declaration

2016-05-11 Thread Cameron via cfe-commits

cameron314 updated this revision to Diff 56961.
cameron314 added a comment.

Ah, perfect, thanks.
Behold, a test that fails without the patch and passes with it :-)


http://reviews.llvm.org/D20131

Files:
  lib/Lex/PPLexerChange.cpp
  test/CodeCompletion/include-within-declaration.c

Index: test/CodeCompletion/include-within-declaration.c
===
--- /dev/null
+++ test/CodeCompletion/include-within-declaration.c
@@ -0,0 +1,11 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: echo 'MACRO(here)' > %t/y.h
+// Clang will generate an error in this case (though internally the correct 
completions
+// are present -- this can be seen via libclang) but it should not crash. If 
it crashes
+// then `not` will fail, otherwise the test succeeds.
+// RUN: not %clang_cc1 -fsyntax-only -code-completion-at=%t/y.h:1:7 -I %t %s
+
+enum {
+#define MACRO(a) FOO
+#include "y.h"
+};
Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -378,6 +378,8 @@
 Result.startToken();
 CurLexer->FormTokenWithChars(Result, CurLexer->BufferEnd, tok::eof);
 CurLexer.reset();
+if (CurLexerKind == CLK_Lexer)
+  CurLexerKind = CLK_CachingLexer;
   } else {
 assert(CurPTHLexer && "Got EOF but no current lexer set!");
 CurPTHLexer->getEOF(Result);


Index: test/CodeCompletion/include-within-declaration.c
===
--- /dev/null
+++ test/CodeCompletion/include-within-declaration.c
@@ -0,0 +1,11 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: echo 'MACRO(here)' > %t/y.h
+// Clang will generate an error in this case (though internally the correct completions
+// are present -- this can be seen via libclang) but it should not crash. If it crashes
+// then `not` will fail, otherwise the test succeeds.
+// RUN: not %clang_cc1 -fsyntax-only -code-completion-at=%t/y.h:1:7 -I %t %s
+
+enum {
+#define MACRO(a) FOO
+#include "y.h"
+};
Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -378,6 +378,8 @@
 Result.startToken();
 CurLexer->FormTokenWithChars(Result, CurLexer->BufferEnd, tok::eof);
 CurLexer.reset();
+if (CurLexerKind == CLK_Lexer)
+  CurLexerKind = CLK_CachingLexer;
   } else {
 assert(CurPTHLexer && "Got EOF but no current lexer set!");
 CurPTHLexer->getEOF(Result);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

2016-05-11 Thread Adrian McCarthy via cfe-commits

amccarth added inline comments.


Comment at: lib/Driver/MSVCToolChain.cpp:478
@@ +477,3 @@
+
+  const DWORD VersionSize = ::GetFileVersionInfoSizeW(ClExeWide.c_str(),
+  nullptr);

amccarth wrote:
> thakis wrote:
> > amccarth wrote:
> > > amccarth wrote:
> > > > thakis wrote:
> > > > > amccarth wrote:
> > > > > > Yes, it looks in the executable (which I tried to emphasize with 
> > > > > > the method name).
> > > > > > 
> > > > > > I don't think this is very expensive given that Explorer often 
> > > > > > makes zillions of such calls, but I'm open to other suggestions.
> > > > > > 
> > > > > > I know that you can't use a library that's newer than the compiler 
> > > > > > (because it may use new language features), but I don't know if 
> > > > > > that applies in the other direction or how we would safely and 
> > > > > > reliably map directory names to library versions and therefore to 
> > > > > > compiler versions.
> > > > > I agree that figuring out the right value for fmsc-version 
> > > > > automatically somehow is definitely something we should do.
> > > > > 
> > > > > I forgot that `getVisualStudioBinariesFolder` already works by 
> > > > > looking for cl.exe in PATH, so cl.exe's metadata is already warmed up 
> > > > > in the disk cache. However, GetFileVersionInfoW() probably opens 
> > > > > cl.exe itself and does some PE parsing to get at the version, and 
> > > > > that probably is in cold cache territory. 
> > > > > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003(v=vs.85).aspx
> > > > >  suggests that this function might open several files).
> > > > > 
> > > > > `getVisualStudioBinariesFolder` checks:
> > > > > 
> > > > > 1. getenv("VCINSTALLDIR")
> > > > > 2. cl.exe in getenv("PATH")
> > > > > 3. registry (via getVisualStudioInstallDir)
> > > > > 
> > > > > The common cases are 1 and 3. For 1, for default installs, the 
> > > > > version number is part of the directory name (for default installs, 
> > > > > what most people have). For 3, the version number is in the registry 
> > > > > key we query. So in most cases we shouldn't have to look at cl.exe 
> > > > > itself. And for the cases where we would have to look, maybe it's ok 
> > > > > to require an explicit fmsc-version flag.
> > > > The version number in the directory name and the registry is the 
> > > > version number of Visual Studio not of the compiler.  Yes, we could do 
> > > > a mapping (VS 14 comes bundled with CL 19), assuming Microsoft 
> > > > continues to keep VS releases and compiler releases in sync, and it 
> > > > means this code will forever need updates to the mapping data.
> > > > 
> > > > The mapping would give just the major version number, which might be 
> > > > all that matters now, but if there's ever a CL 19.1 that has different 
> > > > compatibility requirements (and is maybe released out-of-band with 
> > > > Visual Studio), we'd be stuck.
> > > > 
> > > > Getting the actual version from the compiler seems the most accurate 
> > > > and future-proof way to check.  If that's too expensive, then maybe we 
> > > > should abandon the idea of detecting the default for compatibility.
> > > I'll do some research to figure out the actual costs.  I suspect that 
> > > walking the PATH for the executable may be far more expensive, but I'll 
> > > get some numbers and report back.
> > Compilers being released independently of VC versions and fractional compat 
> > numbers sounds like things we can worry about when they happen (probably 
> > not soon, right?).
> > 
> > We already walk PATH, so that wouldn't be an additional cost.
> > 
> > Be sure to measure cold disk cache perf impact (which is tricky on Windows 
> > since there's as far as I know no way to tell the OS to drop its caches). 
> > As far as I know file metadata is stored with the directory node on NTFS, 
> > so stating files doesn't warm up file content accesses.
> > Compilers being released independently of VC versions and fractional compat 
> > numbers sounds like things we can worry about when they happen (probably 
> > not soon, right?).
> 
> It already happens.  Herb Sutter talks about it in one of his blogs:  "Soon 
> after VC++11 ships we have announced we will do out-of-band releases for 
> additional C++11 conformance which will naturally also include more C11 
> features that are in the C subset of C++11."  In this case, it's just the 
> build number (of major.minor.build) that's updating, but it's for increasing 
> conformance, which is exactly a compatibility issue.
> 
> > We already walk PATH, so that wouldn't be an additional cost.
> 
> I suspect we may be walking it more than once, which can be expensive even if 
> the cache is all warmed up.  This is one of the things I'm checking.  If it's 
> a problem, I'll propose a patch to cache the result from the first walk.
> 
> > stating files doesn't warm up file content accesses.
> 
> That

Re: [PATCH] D20131: Fixed crash during code completion in file included within declaration

2016-05-11 Thread Richard Smith via cfe-commits

rsmith added a comment.

In http://reviews.llvm.org/D20131#427717, @cameron314 wrote:

> I have no way to distinguish between a crash and the normal errors (with 
> hidden completions). Is there any other way to test this?

If you use `// RUN: not %clang_cc1 -code-completion-at=[...]`, the test should 
pass if clang fails normally but fail if clang crashes.

http://reviews.llvm.org/D20131

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

r269234 - [VFS][Unittests] Make dir iteration tests depend only on content

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

Author: bruno
Date: Wed May 11 15:58:47 2016
New Revision: 269234

URL: http://llvm.org/viewvc/llvm-project?rev=269234=rev
Log:
[VFS][Unittests] Make dir iteration tests depend only on content

Do not rely on any specific order while comparing the results of
directory iteration.

Modified:
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=269234=269233=269234=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Wed May 11 15:58:47 2016
@@ -370,16 +370,23 @@ TEST(VirtualFileSystemTest, BasicRealFSR
 }
 
 template 
-static void checkContents(DirIter I, ArrayRef Expected) {
+static void checkContents(DirIter I, ArrayRef ExpectedOut) {
   std::error_code EC;
-  auto ExpectedIter = Expected.begin(), ExpectedEnd = Expected.end();
-  for (DirIter E;
-   !EC && I != E && ExpectedIter != ExpectedEnd;
-   I.increment(EC), ++ExpectedIter)
-EXPECT_EQ(*ExpectedIter, I->getName());
+  SmallVector Expected(ExpectedOut.begin(), ExpectedOut.end());
+  SmallVector InputToCheck;
 
-  EXPECT_EQ(ExpectedEnd, ExpectedIter);
-  EXPECT_EQ(DirIter(), I);
+  // Do not rely on iteration order to check for contents, sort both
+  // content vectors before comparison.
+  for (DirIter E; !EC && I != E; I.increment(EC))
+InputToCheck.push_back(I->getName());
+
+  std::sort(InputToCheck.begin(), InputToCheck.end());
+  std::sort(Expected.begin(), Expected.end());
+  EXPECT_EQ(InputToCheck.size(), Expected.size());
+
+  unsigned LastElt = std::min(InputToCheck.size(), Expected.size());
+  for (unsigned Idx = 0; Idx != LastElt; ++Idx)
+EXPECT_EQ(Expected[Idx], StringRef(InputToCheck[Idx]));
 }
 
 TEST(VirtualFileSystemTest, OverlayIteration) {


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

Re: [PATCH] D20131: Fixed crash during code completion in file included within declaration

2016-05-11 Thread Cameron via cfe-commits

cameron314 added a comment.

I fixed this last July so the details are a little hazy, but fortunately it 
turns out I documented what I had found:

> It seems when clang parses an enum declaration, it first parses the 
> declaration specifiers, then stops if a semicolon is present.

>  The trouble is, an #include could cause the file to change part-way through 
> the declaration. If completion is enabled, then when leaving the included 
> file in which the completion was requested, the tokenizer is cleared (clang 
> tries to simulate an EOF at that point to prevent further parsing).

>  But, while the tokenizer is cleared, the rest of the declaration still needs 
> to be parsed, and the peeked token (a semicolon here) can no longer be 
> advanced over, since it refers in this case to a token in a tokenizer that 
> has been freed. Boom, null reference exception!

>  It seems changing the lexer kind to the caching lexer when the artificial 
> EOF is inserted does the right thing in this case – a cached EOF token is 
> returned on the advancement of the peeked semicolon.

I tried to add a test; I can reproduce the crash, and with this patch it no 
longer crashes, but because there's a subsequent parsing error after the 
completion point, when passing via `clang.exe` only the error diagnostics are 
printed without any of the completions (compared to libclang which allows you 
to retrieve both the completions and the diagnostics). This means I cannot 
write a RUN command in the lit test without it failing (the exit code is 
non-zero). I have no way to distinguish between a crash and the normal errors 
(with hidden completions). Is there any other way to test this?

Comment at: lib/Lex/PPLexerChange.cpp:380-382
@@ -379,3 +379,5 @@
 CurLexer->FormTokenWithChars(Result, CurLexer->BufferEnd, tok::eof);
 CurLexer.reset();
+if (CurLexerKind == CLK_Lexer)
+  CurLexerKind = CLK_CachingLexer;
   } else {

rsmith wrote:
> Can you use `CurLexer->cutOffLexing()` instead?
Nope, still crashes when I try (before the reset, obviously).

http://reviews.llvm.org/D20131

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

r269231 - Preserve the FoundDecl when performing overload resolution for constructors.

2016-05-11 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Wed May 11 15:37:46 2016
New Revision: 269231

URL: http://llvm.org/viewvc/llvm-project?rev=269231=rev
Log:
Preserve the FoundDecl when performing overload resolution for constructors.
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.

Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/Sema/Overload.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Sema/TemplateDeduction.h
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/lib/Sema/TreeTransform.h

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=269231=269230=269231=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Wed May 11 15:37:46 2016
@@ -16,6 +16,7 @@
 #define LLVM_CLANG_AST_EXPRCXX_H
 
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/LambdaCapture.h"
 #include "clang/AST/TemplateBase.h"
@@ -26,9 +27,6 @@
 
 namespace clang {
 
-class CXXConstructorDecl;
-class CXXDestructorDecl;
-class CXXMethodDecl;
 class CXXTemporary;
 class MSPropertyDecl;
 class TemplateArgumentListInfo;
@@ -1168,18 +1166,21 @@ private:
   SourceLocation Loc;
   SourceRange ParenOrBraceRange;
   unsigned NumArgs : 16;
-  bool Elidable : 1;
-  bool HadMultipleCandidates : 1;
-  bool ListInitialization : 1;
-  bool StdInitListInitialization : 1;
-  bool ZeroInitialization : 1;
+  unsigned Elidable : 1;
+  unsigned HadMultipleCandidates : 1;
+  unsigned ListInitialization : 1;
+  unsigned StdInitListInitialization : 1;
+  unsigned ZeroInitialization : 1;
   unsigned ConstructKind : 2;
   Stmt **Args;
 
+  void setConstructor(CXXConstructorDecl *C) { Constructor = C; }
+
 protected:
   CXXConstructExpr(const ASTContext , StmtClass SC, QualType T,
SourceLocation Loc,
-   CXXConstructorDecl *d, bool elidable,
+   NamedDecl *Found, CXXConstructorDecl *Ctor,
+   bool Elidable,
ArrayRef Args,
bool HadMultipleCandidates,
bool ListInitialization,
@@ -1198,15 +1199,13 @@ protected:
 public:
   /// \brief Construct an empty C++ construction expression.
   explicit CXXConstructExpr(EmptyShell Empty)
-: Expr(CXXConstructExprClass, Empty), Constructor(nullptr),
-  NumArgs(0), Elidable(false), HadMultipleCandidates(false),
-  ListInitialization(false), ZeroInitialization(false),
-  ConstructKind(0), Args(nullptr)
-  { }
+: CXXConstructExpr(CXXConstructExprClass, Empty) {}
 
   static CXXConstructExpr *Create(const ASTContext , QualType T,
   SourceLocation Loc,
-  CXXConstructorDecl *D, bool Elidable,
+  NamedDecl *Found,
+  CXXConstructorDecl *Ctor,
+  bool Elidable,
   ArrayRef Args,
   bool HadMultipleCandidates,
   bool ListInitialization,
@@ -1215,8 +1214,11 @@ public:
   ConstructionKind ConstructKind,
   SourceRange ParenOrBraceRange);
 
+  /// \brief Get the declaration that was found by name lookup.
+  NamedDecl *getFoundDecl() const;
+
+  /// \brief Get the constructor that this expression will (ultimately) call.
   CXXConstructorDecl *getConstructor() const { return Constructor; }
-  void setConstructor(CXXConstructorDecl *C) { Constructor = C; }
 
   SourceLocation getLocation() const { return Loc; }
   void setLocation(SourceLocation Loc) { this->Loc = Loc; }
@@ -1382,7 +1384,9 @@ class CXXTemporaryObjectExpr : public CX
   TypeSourceInfo *Type;
 
 public:
-  CXXTemporaryObjectExpr(const ASTContext , CXXConstructorDecl *Cons,
+  CXXTemporaryObjectExpr(const ASTContext ,
+ NamedDecl *Found,
+ CXXConstructorDecl *Cons,
  TypeSourceInfo *Type,
  ArrayRef Args,
  SourceRange ParenOrBraceRange,

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL:

[clang-tools-extra] r269229 - [Clang-tidy] modernize-use-bool-literals: documentation style.

2016-05-11 Thread Eugene Zelenko via cfe-commits

Author: eugenezelenko
Date: Wed May 11 15:31:50 2016
New Revision: 269229

URL: http://llvm.org/viewvc/llvm-project?rev=269229=rev
Log:
[Clang-tidy] modernize-use-bool-literals: documentation style.

Fix readability-redundant-control-flow warnings in regression test.

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-bool-literals.rst
clang-tools-extra/trunk/test/clang-tidy/modernize-use-bool-literals.cpp

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=269229=269228=269229=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Wed May 11 15:31:50 2016
@@ -199,7 +199,7 @@ identified.  The improvements since the
 - New `modernize-use-bool-literals
   
`_
 check
 
-  Finds integer literals which are cast to bool.
+  Finds integer literals which are cast to ``bool``.
 
 - New `performance-faster-string-find
   
`_
 check

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-bool-literals.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-bool-literals.rst?rev=269229=269228=269229=diff
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-bool-literals.rst 
(original)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-bool-literals.rst 
Wed May 11 15:31:50 2016
@@ -3,7 +3,7 @@
 modernize-use-bool-literals
 ===
 
-Finds integer literals which are cast to bool.
+Finds integer literals which are cast to ``bool``.
 
 .. code-block:: c++
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-use-bool-literals.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-use-bool-literals.cpp?rev=269229=269228=269229=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-use-bool-literals.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-use-bool-literals.cpp Wed 
May 11 15:31:50 2016
@@ -34,7 +34,6 @@ bool MacroIntToTrue = TRUE_MACRO;
 #define FALSE_MACRO bool(0)
 // CHECK-FIXES: {{^}}#define FALSE_MACRO bool(0){{$}}
 
-
 bool TrueBool = true; // OK
 
 bool FalseBool = bool(FALSE_MACRO);
@@ -83,14 +82,12 @@ template
 void templateFunction(type) {
   type TemplateType = 0;
   // CHECK-FIXES: {{^ *}}type TemplateType = 0;{{$}}
-  return;
 }
 
 template
 void valueDependentTemplateFunction() {
   bool Boolean = c;
   // CHECK-FIXES: {{^ *}}bool Boolean = c;{{$}}
-  return;
 }
 
 template
@@ -98,7 +95,6 @@ void anotherTemplateFunction(type) {
   bool JustBool = 0;
   // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: {{.*}}
   // CHECK-FIXES: {{^ *}}bool JustBool = false;{{$}}
-  return;
 }
 
 int main() {


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

r269227 - [analyzer] Fix crash in ObjCGenericsChecker

2016-05-11 Thread Devin Coughlin via cfe-commits

Author: dcoughlin
Date: Wed May 11 15:28:41 2016
New Revision: 269227

URL: http://llvm.org/viewvc/llvm-project?rev=269227=rev
Log:
[analyzer] Fix crash in ObjCGenericsChecker

Fix a crash in the generics checker where DynamicTypePropagation tries
to get the superclass of a root class.

This is a spot-fix for a deeper issue where the checker makes assumptions
that may not hold about subtyping between the symbolically-tracked type of
a value and the compile-time types of a cast on that value.

I've added a TODO to address the underlying issue.

rdar://problem/26086914

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
cfe/trunk/test/Analysis/generics.m

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp?rev=269227=269226=269227=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp Wed May 11 
15:28:41 2016
@@ -387,6 +387,14 @@ static const ObjCObjectPointerType *getM
 }
 return From;
   }
+
+  if (To->getObjectType()->getSuperClassType().isNull()) {
+// If To has no super class and From and To aren't the same then
+// To was not actually a descendent of From. In this case the best we can
+// do is 'From'.
+return From;
+  }
+
   const auto *SuperOfTo =
   To->getObjectType()->getSuperClassType()->getAs();
   assert(SuperOfTo);
@@ -444,6 +452,23 @@ storeWhenMoreInformative(ProgramStateRef
  const ObjCObjectPointerType *StaticLowerBound,
  const ObjCObjectPointerType *StaticUpperBound,
  ASTContext ) {
+  // TODO: The above 4 cases are not exhaustive. In particular, it is possible
+  // for Current to be incomparable with StaticLowerBound, StaticUpperBound,
+  // or both.
+  //
+  // For example, suppose Foo and Bar are unrelated types.
+  //
+  //  Foo *f = ...
+  //  Bar *b = ...
+  //
+  //  id t1 = b;
+  //  f = t1;
+  //  id t2 = f; // StaticLowerBound is Foo, Current is Bar
+  //
+  // We should either constrain the callers of this function so that the stated
+  // preconditions hold (and assert it) or rewrite the function to expicitly
+  // handle the additional cases.
+
   // Precondition
   assert(StaticUpperBound->isSpecialized() ||
  StaticLowerBound->isSpecialized());

Modified: cfe/trunk/test/Analysis/generics.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/generics.m?rev=269227=269226=269227=diff
==
--- cfe/trunk/test/Analysis/generics.m (original)
+++ cfe/trunk/test/Analysis/generics.m Wed May 11 15:28:41 2016
@@ -328,6 +328,21 @@ void returnToIdVariable(NSArray : NSObject
+- (void)takesType:(T)v;
+@end
+
+void testGetMostInformativeDerivedForId(NSArray *a,
+  UnrelatedTypeGeneric *b) {
+  id idB = b;
+  a = idB; // expected-warning {{Conversion from value of type 
'UnrelatedTypeGeneric *' to incompatible type 'NSArray 
*'}}
+
+  // rdar://problem/26086914 crash here caused by symbolic type being unrelated
+  // to compile-time source type of cast.
+  id x = a; // Compile-time type is NSArray<>, Symbolic type is 
UnrelatedTypeGeneric<>.
+  [x takesType:[[NSNumber alloc] init]]; // expected-warning {{Conversion from 
value of type 'NSNumber *' to incompatible type 'NSString *'}}
+}
+
 // CHECK: diagnostics
 // CHECK-NEXT: 
 // CHECK-NEXT:  
@@ -6626,4 +6641,262 @@ void returnToIdVariable(NSArrayfile0
 // CHECK-NEXT:  
 // CHECK-NEXT:  
+// CHECK-NEXT:  
+// CHECK-NEXT:   path
+// CHECK-NEXT:   
+// CHECK-NEXT:
+// CHECK-NEXT: kindevent
+// CHECK-NEXT: location
+// CHECK-NEXT: 
+// CHECK-NEXT:  line337
+// CHECK-NEXT:  col12
+// CHECK-NEXT:  file0
+// CHECK-NEXT: 
+// CHECK-NEXT: ranges
+// CHECK-NEXT: 
+// CHECK-NEXT:   
+// CHECK-NEXT:
+// CHECK-NEXT: line337
+// CHECK-NEXT: col12
+// CHECK-NEXT: file0
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT: line337
+// CHECK-NEXT: col12
+// CHECK-NEXT: file0
+// CHECK-NEXT:
+// CHECK-NEXT:   
+// CHECK-NEXT: 
+// CHECK-NEXT: depth0
+// CHECK-NEXT: extended_message
+// CHECK-NEXT: Type UnrelatedTypeGenericNSString * 
* is inferred from implicit cast (from 
UnrelatedTypeGenericNSString * * to id)
+// CHECK-NEXT: message
+// CHECK-NEXT: Type UnrelatedTypeGenericNSString * 
* is inferred from implicit cast (from 
UnrelatedTypeGenericNSString * * to id)
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT: kindcontrol
+// CHECK-NEXT: edges
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:start
+// CHECK-NEXT:

Re: r269224 - [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Richard Smith via cfe-commits

On Wed, May 11, 2016 at 1:09 PM, Etienne Bergeron via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: etienneb
> Date: Wed May 11 15:09:17 2016
> New Revision: 269224
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269224=rev
> Log:
> [tooling] Fix missing inline keyworkd, breaking build bot.
>
> Summary:
> The missing keyword "inline" is causing some buildbot to fail.
> The symbol is not available.
>
> see:
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/2281/
>
> Reviewers: rnk
>
> Subscribers: cfe-commits, klimek
>
> Differential Revision: http://reviews.llvm.org/D20180
>
> Modified:
> cfe/trunk/include/clang/Tooling/FixIt.h
>
> Modified: cfe/trunk/include/clang/Tooling/FixIt.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/FixIt.h?rev=269224=269223=269224=diff
>
> ==
> --- cfe/trunk/include/clang/Tooling/FixIt.h (original)
> +++ cfe/trunk/include/clang/Tooling/FixIt.h Wed May 11 15:09:17 2016
> @@ -40,27 +40,27 @@ inline SourceRange getSourceRange(const
>
>  /// \brief Returns the SourceRange of an given Node. \p Node is typically
> a
>  ///'Stmt', 'Expr' or a 'Decl'.
> -template  SourceRange getSourceRange(const T ) {
> +template  inline SourceRange getSourceRange(const T ) {
>return Node.getSourceRange();
>  }
>  } // end namespace internal
>
>  // \brief Returns a textual representation of \p Node.
>  template 
> -StringRef getText(const T , const ASTContext ) {
> +inline StringRef getText(const T , const ASTContext ) {
>return internal::getText(internal::getSourceRange(Node), Context);
>  }
>
>  // \brief Returns a FixItHint to remove \p Node.
>  // TODO: Add support for related syntactical elements (i.e. comments,
> ...).
> -template  FixItHint createRemoval(const T ) {
> +template  inline FixItHint createRemoval(const T ) {
>return FixItHint::CreateRemoval(internal::getSourceRange(Node));
>  }
>
>  // \brief Returns a FixItHint to replace \p Destination by \p Source.
>  template 
> -FixItHint createReplacement(const D , const S ,
> -const ASTContext ) {
> +inline FixItHint createReplacement(const D , const S ,
> +   const ASTContext ) {
>return
> FixItHint::CreateReplacement(internal::getSourceRange(Destination),
>getText(Source, Context));
>  }
>

This change doesn't make sense -- the 'inline' here is unnecessary, and
unrelated to the build bot failure (which is not complaining about any of
these functions). It looks like the problem is that libTooling.so isn't
being linked into libclangTidyMiscModule, due to a missing dependency in
clang-tools-extra/clang-tidy/misc/CMakeLists.txt.

Please revert this and instead add a dependency on libTooling to that
CMakeLists.txt file.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Etienne Bergeron via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269224: [tooling] Fix missing inline keyworkd, breaking 
build bot. (authored by etienneb).

Changed prior to commit:
  http://reviews.llvm.org/D20180?vs=56949=56954#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20180

Files:
  cfe/trunk/include/clang/Tooling/FixIt.h

Index: cfe/trunk/include/clang/Tooling/FixIt.h
===
--- cfe/trunk/include/clang/Tooling/FixIt.h
+++ cfe/trunk/include/clang/Tooling/FixIt.h
@@ -40,27 +40,27 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  SourceRange getSourceRange(const T ) {
+template  inline SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-StringRef getText(const T , const ASTContext ) {
+inline StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  FixItHint createRemoval(const T ) {
+template  inline FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-FixItHint createReplacement(const D , const S ,
-const ASTContext ) {
+inline FixItHint createReplacement(const D , const S ,
+   const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
 }


Index: cfe/trunk/include/clang/Tooling/FixIt.h
===
--- cfe/trunk/include/clang/Tooling/FixIt.h
+++ cfe/trunk/include/clang/Tooling/FixIt.h
@@ -40,27 +40,27 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  SourceRange getSourceRange(const T ) {
+template  inline SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-StringRef getText(const T , const ASTContext ) {
+inline StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  FixItHint createRemoval(const T ) {
+template  inline FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-FixItHint createReplacement(const D , const S ,
-const ASTContext ) {
+inline FixItHint createReplacement(const D , const S ,
+   const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r269224 - [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 15:09:17 2016
New Revision: 269224

URL: http://llvm.org/viewvc/llvm-project?rev=269224=rev
Log:
[tooling] Fix missing inline keyworkd, breaking build bot.

Summary:
The missing keyword "inline" is causing some buildbot to fail.
The symbol is not available.

see: 
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/2281/

Reviewers: rnk

Subscribers: cfe-commits, klimek

Differential Revision: http://reviews.llvm.org/D20180

Modified:
cfe/trunk/include/clang/Tooling/FixIt.h

Modified: cfe/trunk/include/clang/Tooling/FixIt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/FixIt.h?rev=269224=269223=269224=diff
==
--- cfe/trunk/include/clang/Tooling/FixIt.h (original)
+++ cfe/trunk/include/clang/Tooling/FixIt.h Wed May 11 15:09:17 2016
@@ -40,27 +40,27 @@ inline SourceRange getSourceRange(const
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  SourceRange getSourceRange(const T ) {
+template  inline SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-StringRef getText(const T , const ASTContext ) {
+inline StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  FixItHint createRemoval(const T ) {
+template  inline FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-FixItHint createReplacement(const D , const S ,
-const ASTContext ) {
+inline FixItHint createReplacement(const D , const S ,
+   const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
 }


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

[libcxx][RFC] Make (w)cin/(w)cout/(w)cerr works under Windows

2016-05-11 Thread Yi-Hong Lyu via cfe-commits

Hello all,

According to that Windows mangler takes data type into account. Reference
of std::cin would be translated into ?cin@__1@std@@3V?$basic_istream@DU
?$char_traits@D@__1@std@@@12@A (class std::__1::basic_istream std::__1::cin). Definition of std::cin, in
contrast, would be translated into ?cin@__1@std@@3PADA (char *
std::__1::cin). There is a linking error because two symbols are different.
In the other hand, Itanium mangler doesn't take data type into account.
Either reference or definition of std::cin would be translated into
__ZNSt3__13cinE. To make (w)cin/(w)cout/(w)cerr works under Windows, I
rewrite part of the code under src/iostream.cpp and the patch is attached.
I am wondering whether it would be a appropriate fix for the issue.

Any comment or suggestion is welcomed,
Yi-Hong


cin_cout_cerr.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20053: [clang-tidy] Add misc-unnecessary-mutable check.

2016-05-11 Thread Aaron Ballman via cfe-commits

aaron.ballman added a subscriber: aaron.ballman.
aaron.ballman added a comment.

One quick thought: we should probably have a test that includes a macro to make 
sure nothing explodes. e.g.,

  #define FIELD(T, N) mutable T N
  class C {
FIELD(int, RemoveMutable);
FIELD(int, KeepMutable)
  
  public:
void haha() const {
  KeepMutable = 12;
}
  };

Not that I expect to run into this case often, but it would be good to ensure 
the check doesn't crash or attempt to modify the macro.



Comment at: clang-tidy/misc/UnnecessaryMutableCheck.cpp:194
@@ +193,3 @@
+void UnnecessaryMutableCheck::check(const MatchFinder::MatchResult ) {
+  const auto *MD = Result.Nodes.getNodeAs("field");
+  const auto *ClassMatch = dyn_cast(MD->getParent());

Why MD; that's usually a method decl.


Comment at: clang-tidy/misc/UnnecessaryMutableCheck.cpp:200
@@ +199,3 @@
+  if (!MD->getDeclName() || ClassMatch->isDependentContext() ||
+  !MD->isMutable())
+return;

I think this would be more useful to hoist into the matcher itself (which may 
mean adding a new AST matcher first, if there isn't already one).


http://reviews.llvm.org/D20053



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

Re: [PATCH] D20052: Add new ASTMatcher that matches dynamic exception specifications.

2016-05-11 Thread don hinton via cfe-commits

hintonda added a comment.

Great, thanks.  Btw, I don't have commit access, so could you land it for me?


http://reviews.llvm.org/D20052



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

Re: [PATCH] D20052: Add new ASTMatcher that matches dynamic exception specifications.

2016-05-11 Thread Aaron Ballman via cfe-commits

On Wed, May 11, 2016 at 3:58 PM, don hinton  wrote:
> hintonda added a comment.
>
> Great, thanks.  Btw, I don't have commit access, so could you land it for me?

Normally, yes, but I'm traveling this week and don't have a computer
that has the source code on it right now. If someone other than me can
commit on your behalf, that would be great.

~Aaron

>
>
> http://reviews.llvm.org/D20052
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19876: Add an AST matcher for string-literal length

2016-05-11 Thread Aaron Ballman via cfe-commits

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

LGTM, thank you for this!


http://reviews.llvm.org/D19876



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

Re: [PATCH] D20052: Add new ASTMatcher that matches dynamic exception specifications.

2016-05-11 Thread Aaron Ballman via cfe-commits

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

LGTM!



Comment at: include/clang/ASTMatchers/ASTMatchers.h:3229
@@ +3228,3 @@
+///   matches the declarations of j, k, and l, but not f, g, h, or i.
+AST_MATCHER(FunctionDecl, hasDynamicExceptionSpec) {
+  if (const auto *FnTy = Node.getType()->getAs())

hintonda wrote:
> aaron.ballman wrote:
> > It's a bit odd to expose this on the declaration instead of the type since 
> > the AST carries this information on the type, not the declaration. I 
> > definitely see the utility in not having to go from the decl to the type in 
> > an AST matcher, though. Can you expose it on both FunctionDecl and 
> > FunctionProtoType instead?
> It's modeled on the isNoThrow matcher directly below which used FunctionDecl, 
> so I used it for this one too.
> 
> Did you want me change this one to use FunctionProtoType or add 2 matchers, 
> one using FunctionDecl and another one using FunctionProtoType?
Ah, good point about isNoThrow. I would say leave it as FunctionDecl for now 
and maybe a follow-on patch (not requesting you do this work, btw) can convert 
it to be a polymorphic matcher that accepts FunctionDecl and FunctionProtoType.


http://reviews.llvm.org/D20052



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

Re: [PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Reid Kleckner via cfe-commits

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

lgtm

I don't see how this could be causing the problem, but it's worth a try. They 
should be marked inline anyway.


http://reviews.llvm.org/D20180



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

Re: [PATCH] D19780: Output OpenCL version in Clang diagnostics

2016-05-11 Thread Vedran Miletić via cfe-commits

rivanvx added a comment.

Could we solve that at a later point? There is one more place where such code 
is already used, but this would enlarge the scope of this patch.

If yes, I am wiling to factor it out after this is merged.


http://reviews.llvm.org/D19780



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

[PATCH] D20180: [tooling] Fix missing inline keyworkd, breaking build bot.

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb created this revision.
etienneb added a reviewer: rnk.
etienneb added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

The missing keyword "inline" is causing some buildbot to fail.
The symbol is not available.

see: 
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/2281/

http://reviews.llvm.org/D20180

Files:
  include/clang/Tooling/FixIt.h

Index: include/clang/Tooling/FixIt.h
===
--- include/clang/Tooling/FixIt.h
+++ include/clang/Tooling/FixIt.h
@@ -40,27 +40,27 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  SourceRange getSourceRange(const T ) {
+template  inline SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-StringRef getText(const T , const ASTContext ) {
+inline StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  FixItHint createRemoval(const T ) {
+template  inline FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-FixItHint createReplacement(const D , const S ,
-const ASTContext ) {
+inline FixItHint createReplacement(const D , const S ,
+   const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
 }


Index: include/clang/Tooling/FixIt.h
===
--- include/clang/Tooling/FixIt.h
+++ include/clang/Tooling/FixIt.h
@@ -40,27 +40,27 @@
 
 /// \brief Returns the SourceRange of an given Node. \p Node is typically a
 ///'Stmt', 'Expr' or a 'Decl'.
-template  SourceRange getSourceRange(const T ) {
+template  inline SourceRange getSourceRange(const T ) {
   return Node.getSourceRange();
 }
 } // end namespace internal
 
 // \brief Returns a textual representation of \p Node.
 template 
-StringRef getText(const T , const ASTContext ) {
+inline StringRef getText(const T , const ASTContext ) {
   return internal::getText(internal::getSourceRange(Node), Context);
 }
 
 // \brief Returns a FixItHint to remove \p Node.
 // TODO: Add support for related syntactical elements (i.e. comments, ...).
-template  FixItHint createRemoval(const T ) {
+template  inline FixItHint createRemoval(const T ) {
   return FixItHint::CreateRemoval(internal::getSourceRange(Node));
 }
 
 // \brief Returns a FixItHint to replace \p Destination by \p Source.
 template 
-FixItHint createReplacement(const D , const S ,
-const ASTContext ) {
+inline FixItHint createReplacement(const D , const S ,
+   const ASTContext ) {
   return FixItHint::CreateReplacement(internal::getSourceRange(Destination),
   getText(Source, Context));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20113: Fix mangled name of method with ns_consumed parameters.

2016-05-11 Thread John McCall via cfe-commits

rjmccall added a comment.

In http://reviews.llvm.org/D20113#426884, @sdefresne wrote:

> In http://reviews.llvm.org/D20113#425984, @rjmccall wrote:
>
> > This is a good catch, thanks!
>
>
> Thank you for the quick reply.
>
> Please excuse me if I misunderstood you or if my remark appear off the mark, 
> this is my first time sending patches to clang. I'm not yet completely 
> familiar with all clang concepts :-)
>
> > As a slight adjustment, It's probably better to just ignore this attribute 
> > when mangling the function type of an entity, the same way that we 
> > generally don't mangle return types because they don't affect overloading.  
> > That will require an extra flag to be passed down in a few places, but 
> > that's pretty reasonable.  This will generally allow NS_CONSUMED and 
> > NS_RETURNS_RETAINED to be placed on existing APIs without changing their 
> > mangling unless the attribute is used in a secondary position (such as the 
> > type of an argument).
>
> > 
>
> > Finally, you should give ns_returns_retained the same treatment, as well as 
> > the parameter-ABI attributes.
>

Actually, I'm sorry, I completely failed to read your patch correctly.  This is 
not the appropriate way to fix this problem; we do not want NS_CONSUMED to 
become semantically meaningful in non-ARC modes.

> I'm not really sure what you mean by "ignore this attribute when mangling the 
> function type of an entity". I read this as "we should ensure that the 
> ns_consumed attribute is only mangled if it is applied to a parameter". Is 
> this correct?

No.  There are two reasons we mangle function types.  The first is when the 
type appears somewhere "secondary" in the signature of the entity we're 
mangling, e.g. in a template argument or as the pointee type of a pointer or 
reference; it's important that this include all the information that 
distinguishes two canonically-different function types, including things like 
NS_CONSUMED under ARC.  The second is when we're mangling the declared type of 
a specific function entity.  It's only important that this include all the 
information that can distinguish overloads, and since you can't overload two 
functions based on whether one of them takes an NS_CONSUMED argument, this 
doesn't need to include those attributes.  This has multiple benefits: first, 
it makes shorter symbols and thus saves binary size, and second, it allows the 
same declaration to mangle the same in both ARC and non-ARC modes as long as it 
doesn't feature NS_CONSUMED in a secondary position.

So I think the appropriate solution is to change the mangler to ignore things 
like calling conventions, NS_CONSUMED, NS_RETURNS_RETAINED, etc. when mangling 
the direct function type of a function entity.  This will allow the same 
declaration to mangle the same way in ARC and non-ARC modes as long as 
NS_CONSUMED etc. are only used in the declaration of the function itself and 
not in, say, the types of its parameters.

That is, this declaration would mangle the same in both language modes:

  void foo(NS_CONSUMED id x);

But this declaration would not:

  void foo(void (^block)(NS_CONSUMED id x));

I think this is the best we can do, because we really don't want these 
attributes to have any semantic impact in non-ARC language modes.  If this 
isn't good enough for your use case, you will need to declare the function 
extern "C".

So, here's what you need to do.  First, don't change SemaType.cpp.  Instead, 
you should change mangleBareFunctionType in ItaniumMangle.cpp so that it does 
not mangle ns_returns_retained or anything from ExtParameterInfo when FD is 
non-null.

Thanks, and sorry for the confusion.

http://reviews.llvm.org/D20113

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

Re: [PATCH] D19932: [OpenCL] Add to_{global|local|private} builtin functions.

2016-05-11 Thread Anastasia Stulova via cfe-commits

Anastasia added inline comments.


Comment at: test/SemaOpenCL/to_addr_builtin.cl:26
@@ +25,3 @@
+#if __OPENCL_C_VERSION__ < CL_VERSION_2_0
+  // expected-error@-2{{'to_global' needs OpenCL version 2.0 or above}}
+#else

@Xiuli, I think Sam is right. Passing constant to generic violates AS 
conversion rules from s6.5.5. So error would be correct behavior of the 
compiler.


http://reviews.llvm.org/D19932



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

Re: [PATCH] D19780: Output OpenCL version in Clang diagnostics

2016-05-11 Thread Anastasia Stulova via cfe-commits

Anastasia added a comment.

Sure! Will do! Thanks!

I am thinking to factor out the version computation string into a common 
function, because we might use it in the other places too.


http://reviews.llvm.org/D19780



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

Re: [PATCH] D20103: PR27132: Proper mangling for __unaligned qualifier (now with both PR27367 and PR27666 fixed)

2016-05-11 Thread Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269220: [MSVC] Implementation of __unaligned as a proper 
type qualifier (authored by asbokhan).

Changed prior to commit:
  http://reviews.llvm.org/D20103?vs=56874=56945#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20103

Files:
  cfe/trunk/include/clang/AST/Type.h
  cfe/trunk/include/clang/Basic/AddressSpaces.h
  cfe/trunk/include/clang/Basic/Attr.td
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/include/clang/Sema/DeclSpec.h
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/AST/MicrosoftMangle.cpp
  cfe/trunk/lib/AST/TypePrinter.cpp
  cfe/trunk/lib/Parse/ParseDecl.cpp
  cfe/trunk/lib/Parse/ParseTentative.cpp
  cfe/trunk/lib/Sema/DeclSpec.cpp
  cfe/trunk/lib/Sema/SemaCodeComplete.cpp
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/lib/Sema/SemaDeclObjC.cpp
  cfe/trunk/lib/Sema/SemaExpr.cpp
  cfe/trunk/lib/Sema/SemaOverload.cpp
  cfe/trunk/lib/Sema/SemaType.cpp
  cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
  cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp
  cfe/trunk/test/Sema/MicrosoftExtensions.c
  cfe/trunk/test/Sema/address_spaces.c
  cfe/trunk/test/Sema/invalid-assignment-constant-address-space.c
  cfe/trunk/test/SemaCXX/MicrosoftExtensions.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3374,6 +3374,16 @@
 "%select{const|restrict|const and restrict|volatile|const and volatile|"
 "volatile and restrict|const, volatile, and restrict}3 qualifier"
 "%select{||s||s|s|s}3">;
+def note_ovl_candidate_bad_unaligned : Note<"candidate "
+"%select{function|function|constructor|"
+"function |function |constructor |"
+"constructor (the implicit default constructor)|"
+"constructor (the implicit copy constructor)|"
+"constructor (the implicit move constructor)|"
+"function (the implicit copy assignment operator)|"
+"function (the implicit move assignment operator)|"
+"constructor (inherited)}0%1 not viable: "
+"%ordinal4 argument (%2) would lose __unaligned qualifier">;
 def note_ovl_candidate_bad_base_to_derived_conv : Note<"candidate "
 "%select{function|function|constructor|"
 "function |function |constructor |"
Index: cfe/trunk/include/clang/Basic/Attr.td
===
--- cfe/trunk/include/clang/Basic/Attr.td
+++ cfe/trunk/include/clang/Basic/Attr.td
@@ -2157,10 +2157,6 @@
   }];
 }
 
-def Unaligned : IgnoredAttr {
-  let Spellings = [Keyword<"__unaligned">];
-}
-
 def LoopHint : Attr {
   /// #pragma clang loop  directive
   /// vectorize: vectorizes loop operations if State == Enable.
Index: cfe/trunk/include/clang/Basic/AddressSpaces.h
===
--- cfe/trunk/include/clang/Basic/AddressSpaces.h
+++ cfe/trunk/include/clang/Basic/AddressSpaces.h
@@ -25,7 +25,7 @@
 /// This uses a high starting offset so as not to conflict with any address
 /// space used by a target.
 enum ID {
-  Offset = 0x00,
+  Offset = 0x7FFF00,
 
   opencl_global = Offset,
   opencl_local,
Index: cfe/trunk/include/clang/AST/Type.h
===
--- cfe/trunk/include/clang/AST/Type.h
+++ cfe/trunk/include/clang/AST/Type.h
@@ -111,6 +111,7 @@
 /// The collection of all-type qualifiers we support.
 /// Clang supports five independent qualifiers:
 /// * C99: const, volatile, and restrict
+/// * MS: __unaligned
 /// * Embedded C (TR18037): address spaces
 /// * Objective C: the GC attributes (none, weak, or strong)
 class Qualifiers {
@@ -152,8 +153,8 @@
 
   enum {
 /// The maximum supported address space number.
-/// 24 bits should be enough for anyone.
-MaxAddressSpace = 0xffu,
+/// 23 bits should be enough for anyone.
+MaxAddressSpace = 0x7fu,
 
 /// The width of the "fast" qualifier mask.
 FastWidth = 3,
@@ -265,6 +266,13 @@
 Mask |= mask;
   }
 
+  bool hasUnaligned() const { return Mask & UMask; }
+  void setUnaligned(bool flag) {
+Mask = (Mask & ~UMask) | (flag ? UMask : 0);
+  }
+  void removeUnaligned() { Mask &= ~UMask; }
+  void addUnaligned() { Mask |= UMask; }
+
   bool hasObjCGCAttr() const { return Mask & GCAttrMask; }
   GC getObjCGCAttr() const { return GC((Mask & GCAttrMask) >> GCAttrShift); }
   void setObjCGCAttr(GC type) {
@@ -433,7 +441,9 @@
// ObjC lifetime qualifiers must match exactly.
getObjCLifetime() == other.getObjCLifetime() &&
// CVR qualifiers may subset.
-   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask));
+   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask)) &&
+   // U qualifier may superset.
+   (!other.hasUnaligned()

r269220 - [MSVC] Implementation of __unaligned as a proper type qualifier

2016-05-11 Thread Andrey Bokhanko via cfe-commits

Author: asbokhan
Date: Wed May 11 13:38:21 2016
New Revision: 269220

URL: http://llvm.org/viewvc/llvm-project?rev=269220=rev
Log:
[MSVC] Implementation of __unaligned as a proper type qualifier

This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).

It also fixes PR27367 and PR27666.

Differential Revision: http://reviews.llvm.org/D20103

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/AddressSpaces.h
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseTentative.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp
cfe/trunk/lib/Sema/SemaCodeComplete.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp
cfe/trunk/test/Sema/MicrosoftExtensions.c
cfe/trunk/test/Sema/address_spaces.c
cfe/trunk/test/Sema/invalid-assignment-constant-address-space.c
cfe/trunk/test/SemaCXX/MicrosoftExtensions.cpp

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=269220=269219=269220=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Wed May 11 13:38:21 2016
@@ -111,6 +111,7 @@ namespace clang {
 /// The collection of all-type qualifiers we support.
 /// Clang supports five independent qualifiers:
 /// * C99: const, volatile, and restrict
+/// * MS: __unaligned
 /// * Embedded C (TR18037): address spaces
 /// * Objective C: the GC attributes (none, weak, or strong)
 class Qualifiers {
@@ -152,8 +153,8 @@ public:
 
   enum {
 /// The maximum supported address space number.
-/// 24 bits should be enough for anyone.
-MaxAddressSpace = 0xffu,
+/// 23 bits should be enough for anyone.
+MaxAddressSpace = 0x7fu,
 
 /// The width of the "fast" qualifier mask.
 FastWidth = 3,
@@ -265,6 +266,13 @@ public:
 Mask |= mask;
   }
 
+  bool hasUnaligned() const { return Mask & UMask; }
+  void setUnaligned(bool flag) {
+Mask = (Mask & ~UMask) | (flag ? UMask : 0);
+  }
+  void removeUnaligned() { Mask &= ~UMask; }
+  void addUnaligned() { Mask |= UMask; }
+
   bool hasObjCGCAttr() const { return Mask & GCAttrMask; }
   GC getObjCGCAttr() const { return GC((Mask & GCAttrMask) >> GCAttrShift); }
   void setObjCGCAttr(GC type) {
@@ -433,7 +441,9 @@ public:
// ObjC lifetime qualifiers must match exactly.
getObjCLifetime() == other.getObjCLifetime() &&
// CVR qualifiers may subset.
-   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask));
+   (((Mask & CVRMask) | (other.Mask & CVRMask)) == (Mask & CVRMask)) &&
+   // U qualifier may superset.
+   (!other.hasUnaligned() || hasUnaligned());
   }
 
   /// \brief Determines if these qualifiers compatibly include another set of
@@ -501,16 +511,19 @@ public:
 
 private:
 
-  // bits: |0 1 2|3 .. 4|5  ..  7|8   ...   31|
-  //   |C R V|GCAttr|Lifetime|AddressSpace|
+  // bits: |0 1 2|3|4 .. 5|6  ..  8|9   ...   31|
+  //   |C R V|U|GCAttr|Lifetime|AddressSpace|
   uint32_t Mask;
 
-  static const uint32_t GCAttrMask = 0x18;
-  static const uint32_t GCAttrShift = 3;
-  static const uint32_t LifetimeMask = 0xE0;
-  static const uint32_t LifetimeShift = 5;
-  static const uint32_t AddressSpaceMask = ~(CVRMask|GCAttrMask|LifetimeMask);
-  static const uint32_t AddressSpaceShift = 8;
+  static const uint32_t UMask = 0x8;
+  static const uint32_t UShift = 3;
+  static const uint32_t GCAttrMask = 0x30;
+  static const uint32_t GCAttrShift = 4;
+  static const uint32_t LifetimeMask = 0x1C0;
+  static const uint32_t LifetimeShift = 6;
+  static const uint32_t AddressSpaceMask =
+  ~(CVRMask | UMask | GCAttrMask | LifetimeMask);
+  static const uint32_t AddressSpaceShift = 9;
 };
 
 /// A std::pair-like structure for storing a qualified type split
@@ -5367,9 +5380,9 @@ inline FunctionType::ExtInfo getFunction
 /// "int". However, it is not more qualified than "const volatile
 /// int".
 inline bool QualType::isMoreQualifiedThan(QualType other) const {
-  Qualifiers myQuals = getQualifiers();
-  Qualifiers otherQuals = other.getQualifiers();
-  return (myQuals != otherQuals && myQuals.compatiblyIncludes(otherQuals));
+  Qualifiers MyQuals = getQualifiers();
+  Qualifiers OtherQuals = other.getQualifiers();
+  return (MyQuals != OtherQuals &&

Re: [PATCH] D20052: Add new ASTMatcher that matches dynamic exception specifications.

2016-05-11 Thread don hinton via cfe-commits

hintonda added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:3229
@@ +3228,3 @@
+///   matches the declarations of j, k, and l, but not f, g, h, or i.
+AST_MATCHER(FunctionDecl, hasDynamicExceptionSpec) {
+  if (const auto *FnTy = Node.getType()->getAs())

aaron.ballman wrote:
> It's a bit odd to expose this on the declaration instead of the type since 
> the AST carries this information on the type, not the declaration. I 
> definitely see the utility in not having to go from the decl to the type in 
> an AST matcher, though. Can you expose it on both FunctionDecl and 
> FunctionProtoType instead?
It's modeled on the isNoThrow matcher directly below which used FunctionDecl, 
so I used it for this one too.

Did you want me change this one to use FunctionProtoType or add 2 matchers, one 
using FunctionDecl and another one using FunctionProtoType?


http://reviews.llvm.org/D20052



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

Re: [PATCH] D20010: [clang-tidy] UnnecessaryCopyInitialization - Extend to trigger on non-const "this" object argument if it is not modified

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

How many more (in relative numbers) results does this check generate now?



Comment at: clang-tidy/performance/UnnecessaryCopyInitialization.cpp:45
@@ -44,7 +44,3 @@
 
-  // Match method call expressions where the this argument is a const
-  // type or const reference. This returned const reference is highly likely to
-  // outlive the local const reference of the variable being declared.
-  // The assumption is that the const reference being returned either points
-  // to a global static variable or to a member of the called object.
-  auto ConstRefReturningMethodCallOfConstParam = cxxMemberCallExpr(
+  // Match method call expressions where the 'this' argument is only used as
+  // const, this will be checked in check() part. This returned const reference

Please enclose inline code snippets in backquotes (`this`, `check()`, etc.).


Comment at: test/clang-tidy/performance-unnecessary-copy-initialization.cpp:133
@@ -132,3 +132,3 @@
   auto AutoCopyConstructed(ExpensiveTypeReference());
   // CHECK-MESSAGES: [[@LINE-1]]:8: warning: the variable
   // CHECK-FIXES: const auto& AutoCopyConstructed(ExpensiveTypeReference());

Please include dynamic parts of the message to the CHECK lines (in this case - 
the variable name).


Repository:
  rL LLVM

http://reviews.llvm.org/D20010



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

r269214 - Relax -Wcalling-convention-cast when casting to the default convention (cdecl)

2016-05-11 Thread Reid Kleckner via cfe-commits

Author: rnk
Date: Wed May 11 12:43:13 2016
New Revision: 269214

URL: http://llvm.org/viewvc/llvm-project?rev=269214=rev
Log:
Relax -Wcalling-convention-cast when casting to the default convention (cdecl)

Modified:
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/test/Sema/callingconv-cast.c

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=269214=269213=269214=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Wed May 11 12:43:13 2016
@@ -1760,7 +1760,15 @@ static void DiagnoseCallingConvCast(Sema
   if (!FD || !FD->hasBody(Definition))
 return;
 
-  // The source expression is a pointer to a known function defined in this TU.
+  // Only warn if we are casting from the default convention to a non-default
+  // convention. This can happen when the programmer forgot to apply the 
calling
+  // convention to the function definition and then inserted this cast to
+  // satisfy the type system.
+  CallingConv DefaultCC = Self.getASTContext().getDefaultCallingConvention(
+  FD->isVariadic(), FD->isCXXInstanceMember());
+  if (DstCC == DefaultCC || SrcCC != DefaultCC)
+return;
+
   // Diagnose this cast, as it is probably bad.
   StringRef SrcCCName = FunctionType::getNameForCallConv(SrcCC);
   StringRef DstCCName = FunctionType::getNameForCallConv(DstCC);

Modified: cfe/trunk/test/Sema/callingconv-cast.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/callingconv-cast.c?rev=269214=269213=269214=diff
==
--- cfe/trunk/test/Sema/callingconv-cast.c (original)
+++ cfe/trunk/test/Sema/callingconv-cast.c Wed May 11 12:43:13 2016
@@ -21,6 +21,10 @@ void mismatched(int x) {}
 typedef void (WINAPI *callback_t)(int);
 void take_callback(callback_t callback);
 
+void WINAPI mismatched_stdcall(int x) {}
+
+void take_opaque_fn(void (*callback)(int));
+
 int main() {
   // expected-warning@+1 {{cast between incompatible calling conventions 
'cdecl' and 'stdcall'}}
   take_callback((callback_t)mismatched);
@@ -44,6 +48,11 @@ int main() {
 
   // Another way to suppress the warning.
   take_callback((callback_t)(void*)mismatched);
+
+  // Don't warn, because we're casting from stdcall to cdecl. Usually that 
means
+  // the programmer is rinsing the function pointer through some kind of opaque
+  // API.
+  take_opaque_fn((void (*)(int))mismatched_stdcall);
 }
 
 // MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "


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

Re: [PATCH] D20053: [clang-tidy] Add misc-unnecessary-mutable check.

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh added a subscriber: alexfh.


Comment at: docs/clang-tidy/checks/misc-unnecessary-mutable.rst:9
@@ +8,3 @@
+
+.. code-block:: c++
+  class SomeClass {

Please verify the documentation can be built without errors. On Ubuntu this 
boils down to:

Install sphinx: 

1. `$ sudo apt-get install sphinx-common`
2. Enable `LLVM_BUILD_DOCS` and maybe some other options in cmake.
2. `$ ninja docs-clang-tools-html` (or something similar, if you use make).


http://reviews.llvm.org/D20053



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

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

> I'm glad to help, but it makes me uneasy to have somebody working on a
> filesystem abstraction that does not have ready access to test and debug
> their changes across the major host platforms that LLVM supports (linux,
> mac, windows). Is there any way you can get access? I don't think that
> windows 10 is critical here; win7 or win8 are fine.

I'm mostly trying to make the crash reproducers to work on Darwin; the
improvements to VFS are in fact side-effects here, not something I'm
working full time on. It would be awesome to have it working on other
platforms out-of-the-box, but I just don't have the bandwidth to do
it. That said, I'm gonna make sure we don't regress on windows, but
unless I have help or get time to setup such machine, I can't
guarantee this improvements are going to be supported on windows.

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.

2016-05-11 Thread Hal Finkel via cfe-commits

Hi Alexey,

I'm a bit confused regarding what this patch does, in part because the test 
case does not test any of the function argument or return types. Does it 
generate these "simd" functions taking scalar arguments? I'd expect that what 
this does is that it generates functions taking vector arguments and producing 
vector results. It would then extract the scalar values from those arguments 
and feed them into the scalar code (replicated N times), and then insert the 
results into the vector return value. The SLP vectorizer will then vectorize 
the function if profitable.

Thanks again,
Hal

- Original Message -
> From: "Alexey Bataev via cfe-commits" 
> To: cfe-commits@lists.llvm.org
> Sent: Friday, May 6, 2016 4:40:08 AM
> Subject: r268721 - [OPENMP 4.0] Codegen for 'declare simd' directive.
> 
> Author: abataev
> Date: Fri May  6 04:40:08 2016
> New Revision: 268721
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=268721=rev
> Log:
> [OPENMP 4.0] Codegen for 'declare simd' directive.
> 
> OpenMP 4.0 adds support for elemental functions using declarative
> directive '#pragma omp declare simd'. Patch adds mangling for simd
> functions in accordance with
> https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt
> 
> Added:
> cfe/trunk/test/OpenMP/declare_simd_codegen.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> 
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=268721=268720=268721=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri May  6 04:40:08
> 2016
> @@ -6042,3 +6042,228 @@ void CGOpenMPRuntime::emitTargetEnterOrE
>  ThenGenRCG(CGF);
>}
>  }
> +
> +namespace {
> +  /// Kind of parameter in a function with 'declare simd' directive.
> +  enum ParamKindTy { LinearWithVarStride, Linear, Uniform, Vector };
> +  /// Attribute set of the parameter.
> +  struct ParamAttrTy {
> +ParamKindTy Kind = Vector;
> +llvm::APSInt StrideOrArg;
> +llvm::APSInt Alignment;
> +  };
> +} // namespace
> +
> +static unsigned evaluateCDTSize(const FunctionDecl *FD,
> +ArrayRef ParamAttrs) {
> +  // Every vector variant of a SIMD-enabled function has a vector
> length (VLEN).
> +  // If OpenMP clause "simdlen" is used, the VLEN is the value of
> the argument
> +  // of that clause. The VLEN value must be power of 2.
> +  // In other case the notion of the function`s "characteristic data
> type" (CDT)
> +  // is used to compute the vector length.
> +  // CDT is defined in the following order:
> +  //   a) For non-void function, the CDT is the return type.
> +  //   b) If the function has any non-uniform, non-linear
> parameters, then the
> +  //   CDT is the type of the first such parameter.
> +  //   c) If the CDT determined by a) or b) above is struct, union,
> or class
> +  //   type which is pass-by-value (except for the type that maps to
> the
> +  //   built-in complex data type), the characteristic data type is
> int.
> +  //   d) If none of the above three cases is applicable, the CDT is
> int.
> +  // The VLEN is then determined based on the CDT and the size of
> vector
> +  // register of that ISA for which current vector version is
> generated. The
> +  // VLEN is computed using the formula below:
> +  //   VLEN  = sizeof(vector_register) / sizeof(CDT),
> +  // where vector register size specified in section 3.2.1 Registers
> and the
> +  // Stack Frame of original AMD64 ABI document.
> +  QualType RetType = FD->getReturnType();
> +  if (RetType.isNull())
> +return 0;
> +  ASTContext  = FD->getASTContext();
> +  QualType CDT;
> +  if (!RetType.isNull() && !RetType->isVoidType())
> +CDT = RetType;
> +  else {
> +unsigned Offset = 0;
> +if (auto *MD = dyn_cast(FD)) {
> +  if (ParamAttrs[Offset].Kind == Vector)
> +CDT = C.getPointerType(C.getRecordType(MD->getParent()));
> +  ++Offset;
> +}
> +if (CDT.isNull()) {
> +  for (unsigned I = 0, E = FD->getNumParams(); I < E; ++I) {
> +if (ParamAttrs[I + Offset].Kind == Vector) {
> +  CDT = FD->getParamDecl(I)->getType();
> +  break;
> +}
> +  }
> +}
> +  }
> +  if (CDT.isNull())
> +CDT = C.IntTy;
> +  CDT = CDT->getCanonicalTypeUnqualified();
> +  if (CDT->isRecordType() || CDT->isUnionType())
> +CDT = C.IntTy;
> +  return C.getTypeSize(CDT);
> +}
> +
> +static void
> +emitX86DeclareSimdFunction(const FunctionDecl *FD, llvm::Function
> *Fn,
> +   llvm::APSInt VLENVal,
> +   ArrayRef ParamAttrs,
> +   OMPDeclareSimdDeclAttr::BranchStateTy
> State)

[clang-tools-extra] r269210 - [clang-tidy] Refactoring of FixHintUtils

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 12:38:22 2016
New Revision: 269210

URL: http://llvm.org/viewvc/llvm-project?rev=269210=rev
Log:
[clang-tidy] Refactoring of FixHintUtils

Summary:
Refactor some checkers to use the tooling re-writing API.
see: http://reviews.llvm.org/D19941

Reviewers: klimek, alexfh

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D19807

Modified:
clang-tools-extra/trunk/clang-tidy/misc/SwappedArgumentsCheck.cpp
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-swapped-arguments.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/SwappedArgumentsCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/SwappedArgumentsCheck.cpp?rev=269210=269209=269210=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/SwappedArgumentsCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/SwappedArgumentsCheck.cpp Wed May 
11 12:38:22 2016
@@ -10,6 +10,7 @@
 #include "SwappedArgumentsCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/Lex/Lexer.h"
+#include "clang/Tooling/FixIt.h"
 #include "llvm/ADT/SmallPtrSet.h"
 
 using namespace clang::ast_matchers;
@@ -46,25 +47,9 @@ static bool isImplicitCastCandidate(cons
  Cast->getCastKind() == CK_PointerToBoolean;
 }
 
-/// \brief Get a StringRef representing a SourceRange.
-static StringRef getAsString(const MatchFinder::MatchResult ,
- SourceRange R) {
-  const SourceManager  = *Result.SourceManager;
-  // Don't even try to resolve macro or include contraptions. Not worth 
emitting
-  // a fixit for.
-  if (R.getBegin().isMacroID() ||
-  !SM.isWrittenInSameFile(R.getBegin(), R.getEnd()))
-return StringRef();
-
-  const char *Begin = SM.getCharacterData(R.getBegin());
-  const char *End = SM.getCharacterData(Lexer::getLocForEndOfToken(
-  R.getEnd(), 0, SM, Result.Context->getLangOpts()));
-
-  return StringRef(Begin, End - Begin);
-}
-
 void SwappedArgumentsCheck::check(const MatchFinder::MatchResult ) {
-  auto *Call = Result.Nodes.getStmtAs("call");
+  const ASTContext  = *Result.Context;
+  const auto *Call = Result.Nodes.getStmtAs("call");
 
   llvm::SmallPtrSet UsedArgs;
   for (unsigned I = 1, E = Call->getNumArgs(); I < E; ++I) {
@@ -99,24 +84,14 @@ void SwappedArgumentsCheck::check(const
   continue;
 
 // Emit a warning and fix-its that swap the arguments.
-SourceRange LHSRange = LHS->getSourceRange(),
-RHSRange = RHS->getSourceRange();
-auto D =
-diag(Call->getLocStart(), "argument with implicit conversion from %0 "
-  "to %1 followed by argument converted from "
-  "%2 to %3, potentially swapped arguments.")
+diag(Call->getLocStart(), "argument with implicit conversion from %0 "
+  "to %1 followed by argument converted from "
+  "%2 to %3, potentially swapped arguments.")
 << LHS->getType() << LHSFrom->getType() << RHS->getType()
-<< RHSFrom->getType() << LHSRange << RHSRange;
-
-StringRef RHSString = getAsString(Result, RHSRange);
-StringRef LHSString = getAsString(Result, LHSRange);
-if (!LHSString.empty() && !RHSString.empty()) {
-  D << FixItHint::CreateReplacement(
-   CharSourceRange::getTokenRange(LHSRange), RHSString)
-<< FixItHint::CreateReplacement(
-   CharSourceRange::getTokenRange(RHSRange), LHSString);
-}
-
+<< RHSFrom->getType()
+<< tooling::fixit::createReplacement(*LHS, *RHS, Ctx)
+<< tooling::fixit::createReplacement(*RHS, *LHS, Ctx);
+
 // Remember that we emitted a warning for this argument.
 UsedArgs.insert(RHSCast);
   }

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp?rev=269210=269209=269210=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp Wed 
May 11 12:38:22 2016
@@ -10,6 +10,7 @@
 #include "ElseAfterReturnCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
 
 using namespace clang::ast_matchers;
 
@@ -28,20 +29,17 @@ void ElseAfterReturnCheck::registerMatch
   this);
 }
 
-static FixItHint removeToken(SourceLocation Loc) {
-  return FixItHint::CreateRemoval(CharSourceRange::getTokenRange(Loc, Loc));
-}
-
 void ElseAfterReturnCheck::check(const MatchFinder::MatchResult ) {
   const auto *If = Result.Nodes.getNodeAs("if");
   SourceLocation ElseLoc =

[clang-tools-extra] r269208 - [clang-tidy] Add FixIt for swapping arguments in string-constructor-checker.

2016-05-11 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Wed May 11 12:32:12 2016
New Revision: 269208

URL: http://llvm.org/viewvc/llvm-project?rev=269208=rev
Log:
[clang-tidy] Add FixIt for swapping arguments in string-constructor-checker.

Summary:
Arguments can be swapped using fixit when they are not in macros.
This is the same implementation than SwappedArguments. Some code 
got lifted to be reused.

Others checks are not safe to be fixed as they tend to be bugs or errors.
It is better to let the user manually review them.

Reviewers: alexfh

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D19547

Modified:
clang-tools-extra/trunk/clang-tidy/misc/StringConstructorCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-string-constructor.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/StringConstructorCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/StringConstructorCheck.cpp?rev=269208=269207=269208=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/StringConstructorCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/StringConstructorCheck.cpp Wed May 
11 12:32:12 2016
@@ -10,6 +10,7 @@
 #include "StringConstructorCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
 
 using namespace clang::ast_matchers;
 
@@ -54,7 +55,7 @@ void StringConstructorCheck::registerMat
   isDefinition(),
   hasType(pointerType(pointee(isAnyCharacter(), isConstQualified(,
   hasInitializer(ignoringParenImpCasts(BoundStringLiteral)));
-  auto ConstStrLiteral = expr(ignoringParenImpCasts(anyOf(
+  const auto ConstStrLiteral = expr(ignoringParenImpCasts(anyOf(
   BoundStringLiteral, declRefExpr(hasDeclaration(anyOf(
   ConstPtrStrLiteralDecl, 
ConstStrLiteralDecl));
 
@@ -88,7 +89,7 @@ void StringConstructorCheck::registerMat
   // Detect the expression: string("...", 0);
   hasArgument(1, ZeroExpr.bind("empty-string")),
   // Detect the expression: string("...", -4);
-  hasArgument(1, NegativeExpr.bind("negative-length")),
  
+  hasArgument(1, NegativeExpr.bind("negative-length")),
   // Detect the expression: string("lit", 0x1234567);
   hasArgument(1, LargeLengthExpr.bind("large-length")),
   // Detect the expression: string("lit", 5)
@@ -100,11 +101,18 @@ void StringConstructorCheck::registerMat
 }
 
 void StringConstructorCheck::check(const MatchFinder::MatchResult ) {
-  const auto *E = Result.Nodes.getNodeAs("constructor");
+  const ASTContext  = *Result.Context;
+  const auto *E = Result.Nodes.getNodeAs("constructor");
+  assert(E && "missing constructor expression");
   SourceLocation Loc = E->getLocStart();
 
   if (Result.Nodes.getNodeAs("swapped-parameter")) {
-diag(Loc, "constructor parameters are probably swapped");
+const Expr *P0 = E->getArg(0);
+const Expr *P1 = E->getArg(1);
+diag(Loc, "string constructor parameters are probably swapped;"
+  " expecting string(count, character)")
+<< tooling::fixit::createReplacement(*P0, *P1, Ctx)
+<< tooling::fixit::createReplacement(*P1, *P0, Ctx);
   } else if (Result.Nodes.getNodeAs("empty-string")) {
 diag(Loc, "constructor creating an empty string");
   } else if (Result.Nodes.getNodeAs("negative-length")) {

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-string-constructor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-string-constructor.cpp?rev=269208=269207=269208=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-string-constructor.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-string-constructor.cpp Wed May 
11 12:32:12 2016
@@ -21,9 +21,11 @@ extern const char kText3[];
 
 void Test() {
   std::string str('x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are 
probably swapped [misc-string-constructor]
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: string constructor parameters 
are probably swapped; expecting string(count, character) 
[misc-string-constructor]
+  // CHECK-FIXES: std::string str(4, 'x');  
   std::wstring wstr(L'x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are 
probably swapped
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: string constructor parameters 
are probably swapped
+  // CHECK-FIXES: std::wstring wstr(4, L'x');
   std::string s0(0, 'x');
   // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty 
string
   std::string s1(-4, 'x');


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

Re: [PATCH] D19865: [clang-tidy] - PerformanceUnnecesaryCopyInitialization - only trigger for decl stmts with single VarDecl.

2016-05-11 Thread Alexander Kornienko via cfe-commits

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

LG.


http://reviews.llvm.org/D19865



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

Re: [PATCH] D19703: [clang-tidy] Improve misc-redundant-expression and decrease false-positive

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb updated this revision to Diff 56935.
etienneb marked an inline comment as done.
etienneb added a comment.

remove useless set creation


http://reviews.llvm.org/D19703

Files:
  clang-tidy/misc/RedundantExpressionCheck.cpp
  docs/clang-tidy/checks/misc-redundant-expression.rst
  test/clang-tidy/misc-redundant-expression.cpp

Index: test/clang-tidy/misc-redundant-expression.cpp
===
--- test/clang-tidy/misc-redundant-expression.cpp
+++ test/clang-tidy/misc-redundant-expression.cpp
@@ -68,14 +68,14 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: both side of operator are equivalent
 
   if (foo(0) - 2 < foo(0) - 2) return 1;
-  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: both side of operator are equivalent  
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: both side of operator are equivalent
   if (foo(bar(0)) < (foo(bar((0) return 1;
-  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: both side of operator are equivalent  
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: both side of operator are equivalent
 
   if (P1.x < P2.x && P1.x < P2.x) return 1;
-  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: both side of operator are equivalent  
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: both side of operator are equivalent
   if (P2.a[P1.x + 2] < P2.x && P2.a[(P1.x) + (2)] < (P2.x)) return 1;
-  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: both side of operator are equivalent  
+  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: both side of operator are equivalent
 
   return 0;
 }
@@ -100,13 +100,36 @@
   return 0;
 }
 
+int TestConditional(int x, int y) {
+  int k = 0;
+  k += (y < 0) ? x : x;
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: 'true' and 'false' expression are equivalent
+  k += (y < 0) ? x + 1 : x + 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: 'true' and 'false' expression are equivalent
+  return k;
+}
+
+struct MyStruct {
+  int x;
+} Q;
+bool operator==(const MyStruct& lhs, const MyStruct& rhs) { return lhs.x == rhs.x; }
+bool TestOperator(const MyStruct& S) {
+  if (S == Q) return false;
+  return S == S;
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: both side of overloaded operator are equivalent
+}
+
 #define LT(x, y) (void)((x) < (y))
+#define COND(x, y, z) ((x)?(y):(z))
+#define EQUALS(x, y) (x) == (y)
 
 int TestMacro(int X, int Y) {
   LT(0, 0);
   LT(1, 0);
   LT(X, X);
   LT(X+1, X + 1);
+  COND(X < Y, X, X);
+  EQUALS(Q, Q);
 }
 
 int TestFalsePositive(int* A, int X, float F) {
@@ -118,3 +141,22 @@
   if (F != F && F == F) return 1;
   return 0;
 }
+
+int TestBannedMacros() {
+#define EAGAIN 3
+#define NOT_EAGAIN 3
+  if (EAGAIN == 0 | EAGAIN == 0) return 0;
+  if (NOT_EAGAIN == 0 | NOT_EAGAIN == 0) return 0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: both side of operator are equivalent
+}
+
+struct MyClass {
+static const int Value = 42;
+};
+template 
+void TemplateCheck() {
+  static_assert(T::Value == U::Value, "should be identical");
+  static_assert(T::Value == T::Value, "should be identical");
+  // CHECK-MESSAGES: :[[@LINE-1]]:26: warning: both side of overloaded operator are equivalent
+}
+void TestTemplate() { TemplateCheck(); }
Index: docs/clang-tidy/checks/misc-redundant-expression.rst
===
--- docs/clang-tidy/checks/misc-redundant-expression.rst
+++ docs/clang-tidy/checks/misc-redundant-expression.rst
@@ -12,6 +12,7 @@
   * always be a constant (zero or one)
 
 Example:
+
 .. code:: c++
 
   ((x+1) | (x+1)) // (x+1) is redundant
Index: clang-tidy/misc/RedundantExpressionCheck.cpp
===
--- clang-tidy/misc/RedundantExpressionCheck.cpp
+++ clang-tidy/misc/RedundantExpressionCheck.cpp
@@ -9,16 +9,29 @@
 
 #include "RedundantExpressionCheck.h"
 #include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
 
 using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
 namespace misc {
 
-static bool AreIdenticalExpr(const Expr *Left, const Expr *Right) {
+static const char KnownBannedMacroNames[] =
+"EAGAIN;EWOULDBLOCK;SIGCLD;SIGCHLD;";
+
+static bool AreEquivalentNameSpecifier(const NestedNameSpecifier *Left,
+   const NestedNameSpecifier *Right) {
+  llvm::FoldingSetNodeID LeftID, RightID;
+  Left->Profile(LeftID);
+  Right->Profile(RightID);
+  return LeftID == RightID;
+}
+
+static bool AreEquivalentExpr(const Expr *Left, const Expr *Right) {
   if (!Left || !Right)
 return !Left && !Right;
 
@@ -33,8 +46,8 @@
   Expr::const_child_iterator LeftIter = Left->child_begin();
   Expr::const_child_iterator RightIter = Right->child_begin();
   while (LeftIter != Left->child_end() && RightIter != Right->child_end()) {
-if

Re: [PATCH] D19547: [clang-tidy] Add FixIt for swapping arguments in string-constructor-checker.

2016-05-11 Thread Alexander Kornienko via cfe-commits

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

LG.


http://reviews.llvm.org/D19547



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

Re: [PATCH] D19703: [clang-tidy] Improve misc-redundant-expression and decrease false-positive

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb added a comment.



> We should add a hasAnyOverloadedOperatorName matcher at some point.


I proposed it to sbenza@ and he told me that the reason he did HasAnyName was 
for speed issue.
I can't tell if that one has speed issue too.

But, otherwise, I agree... for code readability... we should do it.


http://reviews.llvm.org/D19703



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh requested changes to this revision.
This revision now requires changes to proceed.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  const FunctionDecl *FuncDecl =
+  Result.Nodes.getNodeAs("functionDecl");

s/FunctionDecl/auto/


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:40
@@ +39,3 @@
+  const FunctionDecl *FuncDecl =
+  Result.Nodes.getNodeAs("functionDecl");
+  if (!FuncDecl)

s/clang:://


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:49-50
@@ +48,4 @@
+  SourceLocation CurrentLoc = Range.getEnd();
+  SourceLocation ReplaceStart;
+  SourceLocation ReplaceEnd;
+  std::string Replacement = ReplacementStr;

These two seem to represent a `SourceRange`.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:51
@@ +50,3 @@
+  SourceLocation ReplaceEnd;
+  std::string Replacement = ReplacementStr;
+  unsigned TokenLength = 0;

s/std::string/StringRef/


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:54-90
@@ +53,39 @@
+
+  SmallVector Tokens =
+  utils::lexer::ParseTokens(Context, SM, CharSourceRange(Range, true));
+  auto TokensEnd = Tokens.rend();
+  for (auto I = Tokens.rbegin(); I != TokensEnd; ++I) {
+SourceLocation Loc = I->getLocation();
+TokenLength = I->getLength();
+
+// Looking for throw(), throw([,...]), or throw(...).
+if (I->is(tok::r_paren)) {
+  if (++I == TokensEnd)
+return;
+  bool Empty = true;
+  // Found ')', now loop till we find '('.
+  while (I->isNot(tok::l_paren)) {
+Empty = false;
+if (++I == TokensEnd)
+  return;
+  }
+  if (++I == TokensEnd)
+return;
+  if (StringRef(SM.getCharacterData(I->getLocation()), I->getLength()) ==
+  "throw") {
+if (!Empty) {
+  // We only support macro replacement for "throw()".
+  if (Replacement != "noexcept")
+break;
+  Replacement = "noexcept(false)";
+}
+ReplaceEnd = Loc;
+ReplaceStart = I->getLocation();
+break;
+  }
+} else if (++I == TokensEnd) {
+  return;
+}
+CurrentLoc = I->getLocation();
+  }
+

I'd pull this to a separate function to make the `check()` method easier to 
read.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:93
@@ +92,3 @@
+  if (ReplaceStart.isValid() && ReplaceEnd.isValid()) {
+std::pair BeginInfo = SM.getDecomposedLoc(ReplaceStart);
+std::pair EndInfo = SM.getDecomposedLoc(ReplaceEnd);

`Lexer::makeFileCharRange` is a convenient way to ensure a range is a 
contiguous range in the same file.


http://reviews.llvm.org/D18575



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

Re: [PATCH] D19274: Compilation for Intel MCU (Part 2/3)

2016-05-11 Thread Bruno Cardoso Lopes via cfe-commits

bruno added a comment.

Hi,



Comment at: include/clang/Basic/DiagnosticDriverKinds.td:154
@@ -153,1 +153,3 @@
+def err_drv_cxx_not_supported : Error<
+  "C++ is not supported for target '%0'">;
 

Are you sure there's no equivalente for this already? I'm surprised!


Comment at: lib/Driver/Tools.cpp:300
@@ -299,1 +299,3 @@
+  const bool IsIAMCU = getToolChain().getTriple().isOSIAMCU();
+
   CheckPreprocessingOptions(D, Args);

Tidy up this declaration with others, no need for two newlines here.


Comment at: lib/Driver/Tools.cpp:575
@@ -569,1 +574,3 @@
+  else
+getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);
 

Use braces for the "else" and move the comment somewhere inside the braces


http://reviews.llvm.org/D19274



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

Re: [PATCH] D20170: [clang-tidy] TypeTraits - Type is not expensive to copy when it has a deleted copy constructor.

2016-05-11 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: clang-tidy/utils/TypeTraits.cpp:20
@@ -18,1 +19,3 @@
 
+using namespace ::clang::ast_matchers;
+

aaron.ballman wrote:
> I would prefer this be used locally instead of at namespace scope to avoid 
> potential name collisions.
Note, that file-level `using namespace ast_matchers` is rather common in Clang 
tools, so I wouldn't bother here. That said, I'm fine either way.


Repository:
  rL LLVM

http://reviews.llvm.org/D20170



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

Re: r269116 - Add -Wcast-calling-convention to warn when casting away calling conventions

2016-05-11 Thread Reid Kleckner via cfe-commits

On Tue, May 10, 2016 at 5:55 PM, Hans Wennborg  wrote:
>> This warning is currently off by default while we study its usefulness.
>
> Turns out this wasn't true :-) For example, it's firing here:
> https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin%28dbg%29/builds/5569/steps/compile/logs/stdio
>
> Adding DefaultIgnore in r269148.

Oops, thanks. I think I was going to run it over Chromium myself, and
then I changed my mind, and forgot to change it back.

---

Based on the two warning instances in that Mesa build, I think we
should relax this warning when casting from a non-standard convention
to a default convention. We could also consider relaxing the warning
when casting to a void function, since that's what people seem to use
to mean "generic function pointer". The code in question is doing
stuff like:

void __stdcall api_func0(int a) { ... }
void __stdcall api_func1(int a, int b) { ... }
...
typedef void (*func_ty)();
func_ty api_entries[] = {
  (func_ty) _func0,
  (func_ty) _func1,
  ...
};

Our fixit suggestions are also very silly, because the functions in
question already have explicit calling convention attributes:

..\..\third_party\mesa\src\chromium_gensrc\mesa\glapi_mapi_tmp_shared.h(12817,15):
 note: consider defining 'shared_dispatch_stub_2' with the 'cdecl'
calling convention
void APIENTRY shared_dispatch_stub_2(GLuint list)
  ^
  CDECL_NON_WVMPURE
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19804: Make clang-format cleaner remove redundant commas in list and redundant colon in constructor initializer.

2016-05-11 Thread Eric Liu via cfe-commits

ioeric added a comment.

PING


http://reviews.llvm.org/D19804



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

r269202 - Embed bitcode in object file (clang cc1 part)

2016-05-11 Thread Steven Wu via cfe-commits

Author: steven_wu
Date: Wed May 11 11:26:03 2016
New Revision: 269202

URL: http://llvm.org/viewvc/llvm-project?rev=269202=rev
Log:
Embed bitcode in object file (clang cc1 part)

Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file.  Using -fembed-bitcode-marker will only introduce a
marker in both sections.

Depends on D17390

Reviewers: rsmith

Subscribers: yaron.keren, vsk, cfe-commits

Differential Revision: http://reviews.llvm.org/D17392

Added:
cfe/trunk/test/Frontend/embed-bitcode.ll
Modified:
cfe/trunk/include/clang/CodeGen/BackendUtil.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/embed-bitcode.c

Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/BackendUtil.h?rev=269202=269201=269202=diff
==
--- cfe/trunk/include/clang/CodeGen/BackendUtil.h (original)
+++ cfe/trunk/include/clang/CodeGen/BackendUtil.h Wed May 11 11:26:03 2016
@@ -16,6 +16,7 @@
 
 namespace llvm {
   class Module;
+  class MemoryBufferRef;
 }
 
 namespace clang {
@@ -37,6 +38,9 @@ namespace clang {
  const TargetOptions , const LangOptions ,
  const llvm::DataLayout , llvm::Module *M,
  BackendAction Action, raw_pwrite_stream *OS);
+
+  void EmbedBitcode(llvm::Module *M, const CodeGenOptions ,
+llvm::MemoryBufferRef Buf);
 }
 
 #endif

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=269202=269201=269202=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed May 11 11:26:03 2016
@@ -450,11 +450,14 @@ def fno_autolink : Flag <["-"], "fno-aut
   Flags<[DriverOption, CC1Option]>,
   HelpText<"Disable generation of linker directives for automatic library 
linking">;
 
+def fembed_bitcode_EQ : Joined<["-"], "fembed-bitcode=">,
+Group, Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
+HelpText<"Embed LLVM bitcode (option: off, all, bitcode, marker)">;
 def fembed_bitcode : Flag<["-"], "fembed-bitcode">, Group,
-  Flags<[CC1Option, CC1AsOption]>,
+  Alias, AliasArgs<["all"]>,
   HelpText<"Embed LLVM IR bitcode as data">;
 def fembed_bitcode_marker : Flag<["-"], "fembed-bitcode-marker">,
-  Group, Flags<[CC1Option]>,
+  Alias, AliasArgs<["marker"]>,
   HelpText<"Embed placeholder LLVM IR data as a marker">;
 def fgnu_inline_asm : Flag<["-"], "fgnu-inline-asm">, Group, 
Flags<[DriverOption]>;
 def fno_gnu_inline_asm : Flag<["-"], "fno-gnu-inline-asm">, Group,

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=269202=269201=269202=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Wed May 11 11:26:03 2016
@@ -66,6 +66,8 @@ CODEGENOPT(EmitOpenCLArgMetadata , 1, 0)
 CODEGENOPT(EmulatedTLS   , 1, 0) ///< Set when -femulated-tls is enabled.
 /// \brief FP_CONTRACT mode (on/off/fast).
 ENUM_CODEGENOPT(FPContractMode, FPContractModeKind, 2, FPC_On)
+/// \brief Embed Bitcode mode (off/all/bitcode/marker).
+ENUM_CODEGENOPT(EmbedBitcode, EmbedBitcodeKind, 2, Embed_Off)
 CODEGENOPT(ForbidGuardVariables , 1, 0) ///< Issue errors if C++ guard 
variables
 ///< are required.
 CODEGENOPT(FunctionSections  , 1, 0) ///< Set when -ffunction-sections is 
enabled.

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.h?rev=269202=269201=269202=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.h Wed May 11 11:26:03 2016
@@ -86,6 +86,13 @@ public:
 ProfileIRInstr,// IR level PGO instrumentation in LLVM.
   };
 
+  enum EmbedBitcodeKind {
+Embed_Off,  // No embedded bitcode.
+Embed_All,  // Embed both bitcode and commandline in the output.
+Embed_Bitcode,  // Embed just the bitcode in the output.

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

2016-05-11 Thread Steven Wu via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269202: Embed bitcode in object file (clang cc1 part) 
(authored by steven_wu).

Changed prior to commit:
  http://reviews.llvm.org/D17392?vs=56371=56930#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17392

Files:
  cfe/trunk/include/clang/CodeGen/BackendUtil.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/include/clang/Frontend/CodeGenOptions.h
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/lib/CodeGen/CodeGenAction.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/embed-bitcode.c
  cfe/trunk/test/Frontend/embed-bitcode.ll

Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -634,6 +634,45 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("off", CodeGenOptions::Embed_Off)
+.Case("all", CodeGenOptions::Embed_All)
+.Case("bitcode", CodeGenOptions::Embed_Bitcode)
+.Case("marker", CodeGenOptions::Embed_Marker)
+.Default(~0U);
+if (Model == ~0U) {
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << Name;
+  Success = false;
+} else
+  Opts.setEmbedBitcode(
+  static_cast(Model));
+  }
+  // FIXME: For backend options that are not yet recorded as function
+  // attributes in the IR, keep track of them so we can embed them in a
+  // separate data section and use them when building the bitcode.
+  if (Opts.getEmbedBitcode() == CodeGenOptions::Embed_All) {
+for (const auto  : Args) {
+  // Do not encode output and input.
+  if (A->getOption().getID() == options::OPT_o ||
+  A->getOption().getID() == options::OPT_INPUT ||
+  A->getOption().getID() == options::OPT_x ||
+  A->getOption().getID() == options::OPT_fembed_bitcode ||
+  (A->getOption().getGroup().isValid() &&
+   A->getOption().getGroup().getID() == options::OPT_W_Group))
+continue;
+  ArgStringList ASL;
+  A->render(Args, ASL);
+  for (const auto  : ASL) {
+StringRef ArgStr(arg);
+Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+// using \00 to seperate each commandline options.
+Opts.CmdArgs.push_back('\0');
+  }
+}
+  }
 
   Opts.InstrumentFunctions = Args.hasArg(OPT_finstrument_functions);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
Index: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp
@@ -173,6 +173,8 @@
   return;
   }
 
+  EmbedBitcode(getModule(), CodeGenOpts, llvm::MemoryBufferRef());
+
   EmitBackendOutput(Diags, CodeGenOpts, TargetOpts, LangOpts,
 C.getTargetInfo().getDataLayout(),
 getModule(), Action, AsmOutStream);
@@ -831,9 +833,13 @@
   TheModule->setTargetTriple(TargetOpts.Triple);
 }
 
+EmbedBitcode(TheModule.get(), CI.getCodeGenOpts(),
+ MainFile->getMemBufferRef());
+
 LLVMContext  = TheModule->getContext();
 Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler,
   ());
+
 EmitBackendOutput(CI.getDiagnostics(), CI.getCodeGenOpts(), TargetOpts,
   CI.getLangOpts(), CI.getTarget().getDataLayout(),
   TheModule.get(), BA, OS);
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -16,9 +16,11 @@
 #include "clang/Frontend/Utils.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
 #include "llvm/Bitcode/BitcodeWriterPass.h"
+#include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/CodeGen/RegAllocRegistry.h"
 #include "llvm/CodeGen/SchedulerRegistry.h"
 #include "llvm/IR/DataLayout.h"
@@ -763,3 +765,91 @@
 }
   }
 }
+
+static const char* getSectionNameForBitcode(const Triple ) {
+  switch (T.getObjectFormat()) {
+  case Triple::MachO:
+return "__LLVM,__bitcode";
+  case Triple::COFF:
+  case Triple::ELF:
+  case Triple::UnknownObjectFormat:
+return ".llvmbc";
+  }
+}
+
+static const char* getSectionNameForCommandline(const Triple ) {
+  switch (T.getObjectFormat()) {
+  case Triple::MachO:
+

Re: [PATCH] D19703: [clang-tidy] Improve misc-redundant-expression and decrease false-positive

2016-05-11 Thread Alexander Kornienko via cfe-commits

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

LG.



Comment at: clang-tidy/misc/RedundantExpressionCheck.cpp:140
@@ +139,3 @@
+  const LangOptions  = Finder->getASTContext().getLangOpts();
+  std::set Names(NameRefs.begin(), NameRefs.end());
+  SourceLocation Loc = Node.getExprLoc();

Is there a way to not create a set on each call to the matcher? There also 
might be a more suitable container in llvm/ADT.


Comment at: clang-tidy/misc/RedundantExpressionCheck.cpp:189
@@ +188,3 @@
+  anyOf(
+  hasOverloadedOperatorName("-"), hasOverloadedOperatorName("/"),
+  hasOverloadedOperatorName("%"), hasOverloadedOperatorName("|"),

We should add a `hasAnyOverloadedOperatorName` matcher at some point.


http://reviews.llvm.org/D19703



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

Re: [PATCH] D16797: Update clang support on recent Haiku

2016-05-11 Thread Reid Kleckner via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269201: Update clang support on recent Haiku (authored by 
rnk).

Changed prior to commit:
  http://reviews.llvm.org/D16797?vs=53464=56929#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16797

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Frontend/InitHeaderSearch.cpp

Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -3040,6 +3040,38 @@
   return SanitizerKind::SafeStack;
 }
 
+/// Haiku - Haiku tool chain which can call as(1) and ld(1) directly.
+
+Haiku::Haiku(const Driver , const llvm::Triple& Triple, const ArgList )
+  : Generic_ELF(D, Triple, Args) {
+
+}
+
+void Haiku::AddClangCXXStdlibIncludeArgs(const ArgList ,
+  ArgStringList ) const {
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx:
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot + "/system/develop/headers/c++/v1");
+break;
+  case ToolChain::CST_Libstdcxx:
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot + "/system/develop/headers/c++");
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot + "/system/develop/headers/c++/backward");
+
+StringRef Triple = getTriple().str();
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot + "/system/develop/headers/c++/" +
+ Triple);
+break;
+  }
+}
+
 /// OpenBSD - OpenBSD tool chain which can call as(1) and ld(1) directly.
 
 OpenBSD::OpenBSD(const Driver , const llvm::Triple ,
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -2425,6 +2425,9 @@
   ToolChain * = ToolChains[Target.str()];
   if (!TC) {
 switch (Target.getOS()) {
+case llvm::Triple::Haiku:
+  TC = new toolchains::Haiku(*this, Target, Args);
+  break;
 case llvm::Triple::CloudABI:
   TC = new toolchains::CloudABI(*this, Target, Args);
   break;
Index: cfe/trunk/lib/Driver/ToolChains.h
===
--- cfe/trunk/lib/Driver/ToolChains.h
+++ cfe/trunk/lib/Driver/ToolChains.h
@@ -680,6 +680,18 @@
   void findGccLibDir();
 };
 
+class LLVM_LIBRARY_VISIBILITY Haiku : public Generic_ELF {
+public:
+  Haiku(const Driver , const llvm::Triple ,
+  const llvm::opt::ArgList );
+
+  bool isPIEDefault() const override { return getTriple().getArch() == llvm::Triple::x86_64; }
+
+  void
+  AddClangCXXStdlibIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const override;
+};
+
 class LLVM_LIBRARY_VISIBILITY OpenBSD : public Generic_ELF {
 public:
   OpenBSD(const Driver , const llvm::Triple ,
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -382,6 +382,29 @@
   : OSTargetInfo(Triple, Opts) {}
 };
 
+// Haiku Target
+template
+class HaikuTargetInfo : public OSTargetInfo {
+protected:
+  void getOSDefines(const LangOptions , const llvm::Triple ,
+MacroBuilder ) const override {
+// Haiku defines; list based off of gcc output
+Builder.defineMacro("__HAIKU__");
+Builder.defineMacro("__ELF__");
+DefineStd(Builder, "unix", Opts);
+  }
+public:
+  HaikuTargetInfo(const llvm::Triple , const TargetOptions )
+  : OSTargetInfo(Triple, Opts) {
+this->SizeType = TargetInfo::UnsignedLong;
+this->IntPtrType = TargetInfo::SignedLong;
+this->PtrDiffType = TargetInfo::SignedLong;
+this->ProcessIDType = TargetInfo::SignedLong;
+this->TLSSupported = false;
+
+  }
+};
+
 // Minix Target
 template
 class MinixTargetInfo : public OSTargetInfo {
@@ -4088,21 +4111,15 @@
 };
 
 // x86-32 Haiku target
-class HaikuX86_32TargetInfo : public X86_32TargetInfo {
+class HaikuX86_32TargetInfo : public HaikuTargetInfo {
 public:
   HaikuX86_32TargetInfo(const llvm::Triple , const TargetOptions )
-  : X86_32TargetInfo(Triple, Opts) {
-SizeType = UnsignedLong;
-IntPtrType = SignedLong;
-PtrDiffType = SignedLong;
-ProcessIDType = SignedLong;
-this->TLSSupported = false;
+: HaikuTargetInfo(Triple, Opts) {
   }
   void getTargetDefines(const LangOptions ,
 MacroBuilder ) const override {
-X86_32TargetInfo::getTargetDefines(Opts, Builder);
+

r269201 - Update clang support on recent Haiku

2016-05-11 Thread Reid Kleckner via cfe-commits

Author: rnk
Date: Wed May 11 11:19:05 2016
New Revision: 269201

URL: http://llvm.org/viewvc/llvm-project?rev=269201=rev
Log:
Update clang support on recent Haiku

[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]

clang support on Haiku is lagging a bit, and missing on x86_64.

This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.

Reviewers: rnk, rsmith

Patch by Jérôme Duval

Differential Revision: http://reviews.llvm.org/D16797

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Frontend/InitHeaderSearch.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=269201=269200=269201=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed May 11 11:19:05 2016
@@ -382,6 +382,29 @@ public:
   : OSTargetInfo(Triple, Opts) {}
 };
 
+// Haiku Target
+template
+class HaikuTargetInfo : public OSTargetInfo {
+protected:
+  void getOSDefines(const LangOptions , const llvm::Triple ,
+MacroBuilder ) const override {
+// Haiku defines; list based off of gcc output
+Builder.defineMacro("__HAIKU__");
+Builder.defineMacro("__ELF__");
+DefineStd(Builder, "unix", Opts);
+  }
+public:
+  HaikuTargetInfo(const llvm::Triple , const TargetOptions )
+  : OSTargetInfo(Triple, Opts) {
+this->SizeType = TargetInfo::UnsignedLong;
+this->IntPtrType = TargetInfo::SignedLong;
+this->PtrDiffType = TargetInfo::SignedLong;
+this->ProcessIDType = TargetInfo::SignedLong;
+this->TLSSupported = false;
+
+  }
+};
+
 // Minix Target
 template
 class MinixTargetInfo : public OSTargetInfo {
@@ -4088,21 +4111,15 @@ public:
 };
 
 // x86-32 Haiku target
-class HaikuX86_32TargetInfo : public X86_32TargetInfo {
+class HaikuX86_32TargetInfo : public HaikuTargetInfo {
 public:
   HaikuX86_32TargetInfo(const llvm::Triple , const TargetOptions )
-  : X86_32TargetInfo(Triple, Opts) {
-SizeType = UnsignedLong;
-IntPtrType = SignedLong;
-PtrDiffType = SignedLong;
-ProcessIDType = SignedLong;
-this->TLSSupported = false;
+: HaikuTargetInfo(Triple, Opts) {
   }
   void getTargetDefines(const LangOptions ,
 MacroBuilder ) const override {
-X86_32TargetInfo::getTargetDefines(Opts, Builder);
+HaikuTargetInfo::getTargetDefines(Opts, Builder);
 Builder.defineMacro("__INTEL__");
-Builder.defineMacro("__HAIKU__");
   }
 };
 
@@ -8360,6 +8377,8 @@ static TargetInfo *AllocateTarget(const
 return new MicrosoftX86_64TargetInfo(Triple, Opts);
   }
 }
+case llvm::Triple::Haiku:
+  return new HaikuTargetInfo(Triple, Opts);
 case llvm::Triple::NaCl:
   return new NaClTargetInfo(Triple, Opts);
 case llvm::Triple::PS4:

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=269201=269200=269201=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed May 11 11:19:05 2016
@@ -2425,6 +2425,9 @@ const ToolChain ::getToolChain(co
   ToolChain * = ToolChains[Target.str()];
   if (!TC) {
 switch (Target.getOS()) {
+case llvm::Triple::Haiku:
+  TC = new toolchains::Haiku(*this, Target, Args);
+  break;
 case llvm::Triple::CloudABI:
   TC = new toolchains::CloudABI(*this, Target, Args);
   break;

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=269201=269200=269201=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed May 11 11:19:05 2016
@@ -3040,6 +3040,38 @@ SanitizerMask CloudABI::getDefaultSaniti
   return SanitizerKind::SafeStack;
 }
 
+/// Haiku - Haiku tool chain which can call as(1) and ld(1) directly.
+
+Haiku::Haiku(const Driver , const llvm::Triple& Triple, const ArgList )
+  : Generic_ELF(D, Triple, Args) {
+
+}
+
+void Haiku::AddClangCXXStdlibIncludeArgs(const ArgList ,
+  ArgStringList ) const {
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx:
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot + "/system/develop/headers/c++/v1");
+break;
+  case ToolChain::CST_Libstdcxx:
+addSystemInclude(DriverArgs, CC1Args,
+ getDriver().SysRoot +

Re: [PATCH] D20168: [CodeGen] Handle structs directly in AMDGPUABIInfo

2016-05-11 Thread Matt Arsenault via cfe-commits

arsenm added a comment.

Needs tests


http://reviews.llvm.org/D20168



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

r269200 - [Hexagon] Avoid spurious failures in test/Driver/hexagon-toolchain-elf.c

2016-05-11 Thread Krzysztof Parzyszek via cfe-commits

Author: kparzysz
Date: Wed May 11 11:11:22 2016
New Revision: 269200

URL: http://llvm.org/viewvc/llvm-project?rev=269200=rev
Log:
[Hexagon] Avoid spurious failures in test/Driver/hexagon-toolchain-elf.c

Modified:
cfe/trunk/test/Driver/hexagon-toolchain-elf.c

Modified: cfe/trunk/test/Driver/hexagon-toolchain-elf.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/hexagon-toolchain-elf.c?rev=269200=269199=269200=diff
==
--- cfe/trunk/test/Driver/hexagon-toolchain-elf.c (original)
+++ cfe/trunk/test/Driver/hexagon-toolchain-elf.c Wed May 11 11:11:22 2016
@@ -63,7 +63,7 @@
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK020 %s
 // CHECK020: "-cc1" {{.*}} "-target-cpu" "hexagonv4"
-// CHECK020: "hexagon-link" 
{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v4/crt0
+// CHECK020: 
hexagon-link{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v4/crt0
 
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
@@ -71,7 +71,7 @@
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK021 %s
 // CHECK021: "-cc1" {{.*}} "-target-cpu" "hexagonv5"
-// CHECK021: "hexagon-link" 
{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v5/crt0
+// CHECK021: 
hexagon-link{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v5/crt0
 
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
@@ -79,7 +79,7 @@
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK022 %s
 // CHECK022: "-cc1" {{.*}} "-target-cpu" "hexagonv55"
-// CHECK022: "hexagon-link" 
{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v55/crt0
+// CHECK022: 
hexagon-link{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v55/crt0
 
 // RUN: %clang -### -target hexagon-unknown-elf \
 // RUN:   -ccc-install-dir %S/Inputs/hexagon_tree/Tools/bin \
@@ -87,7 +87,7 @@
 // RUN:   %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK023 %s
 // CHECK023: "-cc1" {{.*}} "-target-cpu" "hexagonv60"
-// CHECK023: "hexagon-link" 
{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0
+// CHECK023: 
hexagon-link{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/lib/v60/crt0
 
 // 
-
 // Test Linker related args


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

Re: [Clang] Convergent Attribute

2016-05-11 Thread Ettore Speziale via cfe-commits

Hello,

>> CUDA? In any case, I don't see how the restriction helps users, and the 
>> attribute at the IR level has a well-defined meaning regardless. If a user 
>> were to have a use case, they'd simply find the restriction arbitrary and 
>> frustrating.
> 
> Yes, CUDA was already considered as well. I just think that compilers should 
> help to reduce amount of erroneous or meaningless use cases. That's one of 
> the reasons to have language options for the attributes. But I don't feel 
> strongly about this particular case anyways. So let's make it language 
> independent then. ;)

Is the patch OK now or you guys want to apply some other modifications?



convergent.diff
Description: Binary data


Thanks,
Ettore Speziale

--
Ettore Speziale — Compiler Engineer
speziale.ett...@gmail.com
espezi...@apple.com
--

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

Re: [PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

2016-05-11 Thread David Majnemer via cfe-commits

majnemer added inline comments.


Comment at: lib/AST/ASTContext.cpp:8604-8606
@@ -8603,5 +8603,5 @@
 bool IsCXXMethod) const {
   // Pass through to the C++ ABI object
   if (IsCXXMethod)
 return ABI->getDefaultMethodCallConv(IsVariadic);
 

rnk wrote:
> majnemer wrote:
> > Do these flags not have an effect on methods?
> Nope:
> https://msdn.microsoft.com/en-us/library/46t77ak2.aspx
> "for all functions except C++ member functions..."
Yeah, that's what the documentation says.  But do they really have no effect? :)


http://reviews.llvm.org/D20171



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

Re: [PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

2016-05-11 Thread Reid Kleckner via cfe-commits

rnk added inline comments.


Comment at: lib/AST/ASTContext.cpp:8604-8606
@@ -8603,5 +8603,5 @@
 bool IsCXXMethod) const {
   // Pass through to the C++ ABI object
   if (IsCXXMethod)
 return ABI->getDefaultMethodCallConv(IsVariadic);
 

majnemer wrote:
> Do these flags not have an effect on methods?
Nope:
https://msdn.microsoft.com/en-us/library/46t77ak2.aspx
"for all functions except C++ member functions..."


http://reviews.llvm.org/D20171



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

Re: [PATCH] D20103: PR27132: Proper mangling for __unaligned qualifier (now with both PR27367 and PR27666 fixed)

2016-05-11 Thread David Majnemer via cfe-commits

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

LGTM, thanks!


http://reviews.llvm.org/D20103



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

Re: [PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

2016-05-11 Thread David Majnemer via cfe-commits

majnemer added a subscriber: majnemer.


Comment at: lib/AST/ASTContext.cpp:8604-8606
@@ -8603,5 +8603,5 @@
 bool IsCXXMethod) const {
   // Pass through to the C++ ABI object
   if (IsCXXMethod)
 return ABI->getDefaultMethodCallConv(IsVariadic);
 

Do these flags not have an effect on methods?


http://reviews.llvm.org/D20171



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

Re: [PATCH] D19156: [ms][dll] #27212: Generating of implicit special members should take into account MSVC compatibility version

2016-05-11 Thread Reid Kleckner via cfe-commits

rnk added inline comments.


Comment at: lib/Sema/SemaDeclCXX.cpp:4816
@@ -4815,1 +4815,3 @@
+if ((MD->isMoveAssignmentOperator() ||
+ (CXXC && CXXC->isMoveConstructor())) &&
 !getLangOpts().isCompatibleWithMSVC(LangOptions::MSVC2015))

The move constructor part of this is definitely a good fix though.


http://reviews.llvm.org/D19156



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

Re: [PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

2016-05-11 Thread Reid Kleckner via cfe-commits

rnk added inline comments.


Comment at: include/clang/Basic/LangOptions.def:220
@@ -218,3 +219,3 @@
 
 LANGOPT(MRTD , 1, 0, "-mrtd calling convention")
 BENIGN_LANGOPT(DelayedTemplateParsing , 1, 0, "delayed template parsing")

Let's get rid of this and have it use a single DefaultCallingConv LangOpt.


Comment at: include/clang/Driver/CC1Options.td:613
@@ -612,1 +612,3 @@
   HelpText<"Allow function arguments and returns of type half">;
+def fms_ms_default_calling_conv_EQ : Joined<["-"], 
"fms-default-calling-conv=">,
+  HelpText<"Set default MS calling convention">;

Let's unify the -cc1 layer with -mrtd, and just have a single 
-fdefault-calling-convention=stdcall/etc flag.


Comment at: lib/AST/ASTContext.cpp:8610
@@ -8609,2 +8609,3 @@
 
-  return Target->getDefaultCallingConv(TargetInfo::CCMT_Unknown);
+  if (LangOpts.MSVCCompat) {
+switch (LangOpts.getDefaultMSCallingConv()) {

I don't think we need to guard this on MSVCCompat, it'll be unset usually. It 
will also help us avoid a special path for MRTD.


Comment at: lib/AST/ASTContext.cpp:8616-8619
@@ +8615,6 @@
+  return CC_C;
+case LangOptions::DCC_FastCall:
+  return CC_X86FastCall;
+case LangOptions::DCC_StdCall:
+  return CC_X86StdCall;
+case LangOptions::DCC_VectorCall:

Neither fastcall nor stdcall can be applied to variadic functions.


http://reviews.llvm.org/D20171



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

[clang-tools-extra] r269194 - [include-fixer] Also output the location where we found an unknown identifier.

2016-05-11 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Wed May 11 10:33:28 2016
New Revision: 269194

URL: http://llvm.org/viewvc/llvm-project?rev=269194=rev
Log:
[include-fixer] Also output the location where we found an unknown identifier.

For debugging only, makes it a bit easier when there are queries coming
out of headers.

Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp?rev=269194=269193=269194=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp Wed May 11 10:33:28 
2016
@@ -95,7 +95,7 @@ public:
   bool MaybeDiagnoseMissingCompleteType(clang::SourceLocation Loc,
 clang::QualType T) override {
 clang::ASTContext  = getCompilerInstance().getASTContext();
-query(T.getUnqualifiedType().getAsString(context.getPrintingPolicy()));
+query(T.getUnqualifiedType().getAsString(context.getPrintingPolicy()), 
Loc);
 return false;
   }
 
@@ -141,7 +141,7 @@ public:
   QueryString = Typo.getAsString();
 }
 
-return query(QueryString);
+return query(QueryString, Typo.getLoc());
   }
 
   StringRef filename() const { return Filename; }
@@ -226,14 +226,16 @@ public:
 
 private:
   /// Query the database for a given identifier.
-  clang::TypoCorrection query(StringRef Query) {
+  clang::TypoCorrection query(StringRef Query, SourceLocation Loc) {
 assert(!Query.empty() && "Empty query!");
 
 // Save database lookups by not looking up identifiers multiple times.
 if (!SeenQueries.insert(Query).second)
   return clang::TypoCorrection();
 
-DEBUG(llvm::dbgs() << "Looking up " << Query << " ... ");
+DEBUG(llvm::dbgs() << "Looking up '" << Query << "' at ");
+DEBUG(Loc.print(llvm::dbgs(), getCompilerInstance().getSourceManager()));
+DEBUG(llvm::dbgs() << " ...");
 
 std::string error_text;
 auto SearchReply = XrefsDBMgr.search(Query);


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

Re: [PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

2016-05-11 Thread Adrian McCarthy via cfe-commits

amccarth added inline comments.


Comment at: lib/Driver/MSVCToolChain.cpp:478
@@ +477,3 @@
+
+  const DWORD VersionSize = ::GetFileVersionInfoSizeW(ClExeWide.c_str(),
+  nullptr);

thakis wrote:
> amccarth wrote:
> > amccarth wrote:
> > > thakis wrote:
> > > > amccarth wrote:
> > > > > Yes, it looks in the executable (which I tried to emphasize with the 
> > > > > method name).
> > > > > 
> > > > > I don't think this is very expensive given that Explorer often makes 
> > > > > zillions of such calls, but I'm open to other suggestions.
> > > > > 
> > > > > I know that you can't use a library that's newer than the compiler 
> > > > > (because it may use new language features), but I don't know if that 
> > > > > applies in the other direction or how we would safely and reliably 
> > > > > map directory names to library versions and therefore to compiler 
> > > > > versions.
> > > > I agree that figuring out the right value for fmsc-version 
> > > > automatically somehow is definitely something we should do.
> > > > 
> > > > I forgot that `getVisualStudioBinariesFolder` already works by looking 
> > > > for cl.exe in PATH, so cl.exe's metadata is already warmed up in the 
> > > > disk cache. However, GetFileVersionInfoW() probably opens cl.exe itself 
> > > > and does some PE parsing to get at the version, and that probably is in 
> > > > cold cache territory. 
> > > > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003(v=vs.85).aspx
> > > >  suggests that this function might open several files).
> > > > 
> > > > `getVisualStudioBinariesFolder` checks:
> > > > 
> > > > 1. getenv("VCINSTALLDIR")
> > > > 2. cl.exe in getenv("PATH")
> > > > 3. registry (via getVisualStudioInstallDir)
> > > > 
> > > > The common cases are 1 and 3. For 1, for default installs, the version 
> > > > number is part of the directory name (for default installs, what most 
> > > > people have). For 3, the version number is in the registry key we 
> > > > query. So in most cases we shouldn't have to look at cl.exe itself. And 
> > > > for the cases where we would have to look, maybe it's ok to require an 
> > > > explicit fmsc-version flag.
> > > The version number in the directory name and the registry is the version 
> > > number of Visual Studio not of the compiler.  Yes, we could do a mapping 
> > > (VS 14 comes bundled with CL 19), assuming Microsoft continues to keep VS 
> > > releases and compiler releases in sync, and it means this code will 
> > > forever need updates to the mapping data.
> > > 
> > > The mapping would give just the major version number, which might be all 
> > > that matters now, but if there's ever a CL 19.1 that has different 
> > > compatibility requirements (and is maybe released out-of-band with Visual 
> > > Studio), we'd be stuck.
> > > 
> > > Getting the actual version from the compiler seems the most accurate and 
> > > future-proof way to check.  If that's too expensive, then maybe we should 
> > > abandon the idea of detecting the default for compatibility.
> > I'll do some research to figure out the actual costs.  I suspect that 
> > walking the PATH for the executable may be far more expensive, but I'll get 
> > some numbers and report back.
> Compilers being released independently of VC versions and fractional compat 
> numbers sounds like things we can worry about when they happen (probably not 
> soon, right?).
> 
> We already walk PATH, so that wouldn't be an additional cost.
> 
> Be sure to measure cold disk cache perf impact (which is tricky on Windows 
> since there's as far as I know no way to tell the OS to drop its caches). As 
> far as I know file metadata is stored with the directory node on NTFS, so 
> stating files doesn't warm up file content accesses.
> Compilers being released independently of VC versions and fractional compat 
> numbers sounds like things we can worry about when they happen (probably not 
> soon, right?).

It already happens.  Herb Sutter talks about it in one of his blogs:  "Soon 
after VC++11 ships we have announced we will do out-of-band releases for 
additional C++11 conformance which will naturally also include more C11 
features that are in the C subset of C++11."  In this case, it's just the build 
number (of major.minor.build) that's updating, but it's for increasing 
conformance, which is exactly a compatibility issue.

> We already walk PATH, so that wouldn't be an additional cost.

I suspect we may be walking it more than once, which can be expensive even if 
the cache is all warmed up.  This is one of the things I'm checking.  If it's a 
problem, I'll propose a patch to cache the result from the first walk.

> stating files doesn't warm up file content accesses.

That is correct.


http://reviews.llvm.org/D20136



___
cfe-commits mailing list
cfe-commits@lists.llvm.org

Re: [PATCH] D19547: [clang-tidy] Add FixIt for swapping arguments in string-constructor-checker.

2016-05-11 Thread Etienne Bergeron via cfe-commits

etienneb updated this revision to Diff 56919.
etienneb marked an inline comment as done.
etienneb added a comment.

use new API. code simplification


http://reviews.llvm.org/D19547

Files:
  clang-tidy/misc/StringConstructorCheck.cpp
  test/clang-tidy/misc-string-constructor.cpp

Index: test/clang-tidy/misc-string-constructor.cpp
===
--- test/clang-tidy/misc-string-constructor.cpp
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -21,9 +21,11 @@
 
 void Test() {
   std::string str('x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are 
probably swapped [misc-string-constructor]
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: string constructor parameters 
are probably swapped; expecting string(count, character) 
[misc-string-constructor]
+  // CHECK-FIXES: std::string str(4, 'x');  
   std::wstring wstr(L'x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are 
probably swapped
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: string constructor parameters 
are probably swapped
+  // CHECK-FIXES: std::wstring wstr(4, L'x');
   std::string s0(0, 'x');
   // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty 
string
   std::string s1(-4, 'x');
Index: clang-tidy/misc/StringConstructorCheck.cpp
===
--- clang-tidy/misc/StringConstructorCheck.cpp
+++ clang-tidy/misc/StringConstructorCheck.cpp
@@ -10,6 +10,7 @@
 #include "StringConstructorCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
 
 using namespace clang::ast_matchers;
 
@@ -54,7 +55,7 @@
   isDefinition(),
   hasType(pointerType(pointee(isAnyCharacter(), isConstQualified(,
   hasInitializer(ignoringParenImpCasts(BoundStringLiteral)));
-  auto ConstStrLiteral = expr(ignoringParenImpCasts(anyOf(
+  const auto ConstStrLiteral = expr(ignoringParenImpCasts(anyOf(
   BoundStringLiteral, declRefExpr(hasDeclaration(anyOf(
   ConstPtrStrLiteralDecl, 
ConstStrLiteralDecl));
 
@@ -88,7 +89,7 @@
   // Detect the expression: string("...", 0);
   hasArgument(1, ZeroExpr.bind("empty-string")),
   // Detect the expression: string("...", -4);
-  hasArgument(1, NegativeExpr.bind("negative-length")),
  
+  hasArgument(1, NegativeExpr.bind("negative-length")),
   // Detect the expression: string("lit", 0x1234567);
   hasArgument(1, LargeLengthExpr.bind("large-length")),
   // Detect the expression: string("lit", 5)
@@ -100,11 +101,18 @@
 }
 
 void StringConstructorCheck::check(const MatchFinder::MatchResult ) {
-  const auto *E = Result.Nodes.getNodeAs("constructor");
+  const ASTContext  = *Result.Context;
+  const auto *E = Result.Nodes.getNodeAs("constructor");
+  assert(E && "missing constructor expression");
   SourceLocation Loc = E->getLocStart();
 
   if (Result.Nodes.getNodeAs("swapped-parameter")) {
-diag(Loc, "constructor parameters are probably swapped");
+const Expr* P0 = E->getArg(0);
+const Expr* P1 = E->getArg(1);
+diag(Loc, "string constructor parameters are probably swapped;"
+  " expecting string(count, character)")
+<< tooling::fixit::createReplacement(*P0, *P1, Ctx)
+<< tooling::fixit::createReplacement(*P1, *P0, Ctx);
   } else if (Result.Nodes.getNodeAs("empty-string")) {
 diag(Loc, "constructor creating an empty string");
   } else if (Result.Nodes.getNodeAs("negative-length")) {


Index: test/clang-tidy/misc-string-constructor.cpp
===
--- test/clang-tidy/misc-string-constructor.cpp
+++ test/clang-tidy/misc-string-constructor.cpp
@@ -21,9 +21,11 @@
 
 void Test() {
   std::string str('x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor parameters are probably swapped [misc-string-constructor]
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: string constructor parameters are probably swapped; expecting string(count, character) [misc-string-constructor]
+  // CHECK-FIXES: std::string str(4, 'x');  
   std::wstring wstr(L'x', 4);
-  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: constructor parameters are probably swapped
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: string constructor parameters are probably swapped
+  // CHECK-FIXES: std::wstring wstr(4, L'x');
   std::string s0(0, 'x');
   // CHECK-MESSAGES: [[@LINE-1]]:15: warning: constructor creating an empty string
   std::string s1(-4, 'x');
Index: clang-tidy/misc/StringConstructorCheck.cpp
===
--- clang-tidy/misc/StringConstructorCheck.cpp
+++ clang-tidy/misc/StringConstructorCheck.cpp
@@ -10,6 +10,7 @@
 #include "StringConstructorCheck.h"
 #include "clang/AST/ASTContext.h"

[PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

2016-05-11 Thread Alexander Makarov via cfe-commits

a.makarov created this revision.
a.makarov added a reviewer: rnk.
a.makarov added a subscriber: cfe-commits.

Patch for bug #27711

http://reviews.llvm.org/D20171

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/LangOptions.h
  include/clang/Driver/CC1Options.td
  include/clang/Driver/CLCompatOptions.td
  lib/AST/ASTContext.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGenCXX/default_calling_conv.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -6140,6 +6140,15 @@
   CmdArgs.push_back("-fms-memptr-rep=virtual");
   }
 
+  if (Args.getLastArg(options::OPT__SLASH_Gd))
+ CmdArgs.push_back("-fms-default-calling-conv=cdecl");
+  else if (Args.getLastArg(options::OPT__SLASH_Gr))
+ CmdArgs.push_back("-fms-default-calling-conv=fastcall");
+  else if (Args.getLastArg(options::OPT__SLASH_Gz))
+ CmdArgs.push_back("-fms-default-calling-conv=stdcall");
+  else if (Args.getLastArg(options::OPT__SLASH_Gv))
+ CmdArgs.push_back("-fms-default-calling-conv=vectorcall");
+
   if (Arg *A = Args.getLastArg(options::OPT_vtordisp_mode_EQ))
 A->render(Args, CmdArgs);
 
Index: lib/AST/ASTContext.cpp
===
--- lib/AST/ASTContext.cpp
+++ lib/AST/ASTContext.cpp
@@ -8607,7 +8607,25 @@
 
   if (LangOpts.MRTD && !IsVariadic) return CC_X86StdCall;
 
-  return Target->getDefaultCallingConv(TargetInfo::CCMT_Unknown);
+  if (LangOpts.MSVCCompat) {
+switch (LangOpts.getDefaultMSCallingConv()) {
+case LangOptions::DCC_None:
+  return Target->getDefaultCallingConv(TargetInfo::CCMT_Unknown);
+case LangOptions::DCC_CDecl:
+  return CC_C;
+case LangOptions::DCC_FastCall:
+  return CC_X86FastCall;
+case LangOptions::DCC_StdCall:
+  return CC_X86StdCall;
+case LangOptions::DCC_VectorCall:
+  // __vectorcall cannot be applied to variadic functions.
+  if (!IsVariadic)
+return CC_X86VectorCall;
+  else
+return Target->getDefaultCallingConv(TargetInfo::CCMT_Unknown);
+}
+  } else
+return Target->getDefaultCallingConv(TargetInfo::CCMT_Unknown);
 }
 
 bool ASTContext::isNearlyEmpty(const CXXRecordDecl *RD) const {
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -3895,11 +3895,12 @@
 
 // This convention is not valid for the target. Use the default function or
 // method calling convention.
-TargetInfo::CallingConvMethodType MT = TargetInfo::CCMT_Unknown;
-if (FD)
-  MT = FD->isCXXInstanceMember() ? TargetInfo::CCMT_Member : 
-TargetInfo::CCMT_NonMember;
-CC = TI.getDefaultCallingConv(MT);
+bool isCXXMethod = false, isVariadic = false;
+if (FD) {
+  isCXXMethod = FD->isCXXInstanceMember();
+  isVariadic = FD->isVariadic();
+}
+CC = Context.getDefaultCallingConvention(isVariadic, isCXXMethod);
   }
 
   attr.setProcessingCache((unsigned) CC);
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1849,6 +1849,34 @@
 Opts.setMSPointerToMemberRepresentationMethod(InheritanceModel);
   }
 
+  // Check for MS default calling conventions being specified.
+  if (Arg *A = Args.getLastArg(OPT_fms_ms_default_calling_conv_EQ)) {
+LangOptions::DefaultMSCallingConvention DefaultCC =
+llvm::StringSwitch(
+A->getValue())
+.Case("cdecl", LangOptions::DCC_CDecl)
+.Case("fastcall", LangOptions::DCC_FastCall)
+.Case("stdcall", LangOptions::DCC_StdCall)
+.Case("vectorcall", LangOptions::DCC_VectorCall)
+.Default(LangOptions::DCC_None);
+if (DefaultCC == LangOptions::DCC_None)
+  Diags.Report(diag::err_drv_invalid_value)
+  << "-fms-default-calling-conv" << A->getValue();
+
+llvm::Triple T(TargetOpts.Triple);
+llvm::Triple::ArchType Arch = T.getArch();
+bool emitError = (DefaultCC == LangOptions::DCC_FastCall ||
+  DefaultCC == LangOptions::DCC_StdCall) &&
+ Arch != llvm::Triple::x86;
+emitError |= DefaultCC == LangOptions::DCC_VectorCall &&
+ !(Arch == llvm::Triple::x86 || Arch == llvm::Triple::x86_64);
+if (emitError)
+  Diags.Report(diag::err_drv_argument_not_allowed_with)
+  << A->getSpelling() << T.getTriple();
+else
+  Opts.setDefaultMSCallingConv(DefaultCC);
+  }
+
   // Check if -fopenmp is specified.
   Opts.OpenMP = Args.hasArg(options::OPT_fopenmp);
   Opts.OpenMPUseTLS =
Index: include/clang/Driver/CC1Options.td
===
---

Re: [PATCH] D18745: [clang-tidy] Adds modernize-use-bool-literals check.

2016-05-11 Thread Piotr Padlewski via cfe-commits

Prazek closed this revision.
Prazek added a comment.

gg for your first check :)


http://reviews.llvm.org/D18745



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

[clang-tools-extra] r269195 - [include-fixer] Always ignore SFINAE contexts.

2016-05-11 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Wed May 11 10:33:30 2016
New Revision: 269195

URL: http://llvm.org/viewvc/llvm-project?rev=269195=rev
Log:
[include-fixer] Always ignore SFINAE contexts.

This could lead to spurious includes being added for identifiers that
are supposed to be not available.

Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp?rev=269195=269194=269195=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp Wed May 11 10:33:30 
2016
@@ -94,6 +94,10 @@ public:
   /// have the fully qualified name ready. Just query that.
   bool MaybeDiagnoseMissingCompleteType(clang::SourceLocation Loc,
 clang::QualType T) override {
+// Ignore spurious callbacks from SFINAE contexts.
+if (getCompilerInstance().getSema().isSFINAEContext())
+  return false;
+
 clang::ASTContext  = getCompilerInstance().getASTContext();
 query(T.getUnqualifiedType().getAsString(context.getPrintingPolicy()), 
Loc);
 return false;
@@ -107,6 +111,10 @@ public:
 DeclContext *MemberContext,
 bool EnteringContext,
 const ObjCObjectPointerType *OPT) override 
{
+// Ignore spurious callbacks from SFINAE contexts.
+if (getCompilerInstance().getSema().isSFINAEContext())
+  return clang::TypoCorrection();
+
 /// If we have a scope specification, use that to get more precise results.
 std::string QueryString;
 if (SS && SS->getRange().isValid()) {


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

Re: [PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

2016-05-11 Thread Nico Weber via cfe-commits

thakis added inline comments.


Comment at: lib/Driver/MSVCToolChain.cpp:478
@@ +477,3 @@
+
+  const DWORD VersionSize = ::GetFileVersionInfoSizeW(ClExeWide.c_str(),
+  nullptr);

amccarth wrote:
> amccarth wrote:
> > thakis wrote:
> > > amccarth wrote:
> > > > Yes, it looks in the executable (which I tried to emphasize with the 
> > > > method name).
> > > > 
> > > > I don't think this is very expensive given that Explorer often makes 
> > > > zillions of such calls, but I'm open to other suggestions.
> > > > 
> > > > I know that you can't use a library that's newer than the compiler 
> > > > (because it may use new language features), but I don't know if that 
> > > > applies in the other direction or how we would safely and reliably map 
> > > > directory names to library versions and therefore to compiler versions.
> > > I agree that figuring out the right value for fmsc-version automatically 
> > > somehow is definitely something we should do.
> > > 
> > > I forgot that `getVisualStudioBinariesFolder` already works by looking 
> > > for cl.exe in PATH, so cl.exe's metadata is already warmed up in the disk 
> > > cache. However, GetFileVersionInfoW() probably opens cl.exe itself and 
> > > does some PE parsing to get at the version, and that probably is in cold 
> > > cache territory. 
> > > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003(v=vs.85).aspx
> > >  suggests that this function might open several files).
> > > 
> > > `getVisualStudioBinariesFolder` checks:
> > > 
> > > 1. getenv("VCINSTALLDIR")
> > > 2. cl.exe in getenv("PATH")
> > > 3. registry (via getVisualStudioInstallDir)
> > > 
> > > The common cases are 1 and 3. For 1, for default installs, the version 
> > > number is part of the directory name (for default installs, what most 
> > > people have). For 3, the version number is in the registry key we query. 
> > > So in most cases we shouldn't have to look at cl.exe itself. And for the 
> > > cases where we would have to look, maybe it's ok to require an explicit 
> > > fmsc-version flag.
> > The version number in the directory name and the registry is the version 
> > number of Visual Studio not of the compiler.  Yes, we could do a mapping 
> > (VS 14 comes bundled with CL 19), assuming Microsoft continues to keep VS 
> > releases and compiler releases in sync, and it means this code will forever 
> > need updates to the mapping data.
> > 
> > The mapping would give just the major version number, which might be all 
> > that matters now, but if there's ever a CL 19.1 that has different 
> > compatibility requirements (and is maybe released out-of-band with Visual 
> > Studio), we'd be stuck.
> > 
> > Getting the actual version from the compiler seems the most accurate and 
> > future-proof way to check.  If that's too expensive, then maybe we should 
> > abandon the idea of detecting the default for compatibility.
> I'll do some research to figure out the actual costs.  I suspect that walking 
> the PATH for the executable may be far more expensive, but I'll get some 
> numbers and report back.
Compilers being released independently of VC versions and fractional compat 
numbers sounds like things we can worry about when they happen (probably not 
soon, right?).

We already walk PATH, so that wouldn't be an additional cost.

Be sure to measure cold disk cache perf impact (which is tricky on Windows 
since there's as far as I know no way to tell the OS to drop its caches). As 
far as I know file metadata is stored with the directory node on NTFS, so 
stating files doesn't warm up file content accesses.


http://reviews.llvm.org/D20136



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

Re: [PATCH] D20125: [libclang] Added clang_getRealSpellingLocation to compensate for clang_getSpellingLocation returning the expansion location

2016-05-11 Thread Cameron via cfe-commits

cameron314 updated this revision to Diff 56917.

http://reviews.llvm.org/D20125

Files:
  include/clang-c/Index.h
  tools/libclang/CXSourceLocation.cpp
  unittests/libclang/LibclangTest.cpp

Index: unittests/libclang/LibclangTest.cpp
===
--- unittests/libclang/LibclangTest.cpp
+++ unittests/libclang/LibclangTest.cpp
@@ -15,6 +15,9 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
+#include 
+#include 
 #define DEBUG_TYPE "libclang-test"
 
 TEST(libclang, clang_parseTranslationUnit2_InvalidArgs) {
@@ -349,21 +352,25 @@
   clang_ModuleMapDescriptor_dispose(MMD);
 }
 
-class LibclangReparseTest : public ::testing::Test {
+class LibclangParseTest : public ::testing::Test {
   std::set Files;
+  typedef std::unique_ptr fixed_addr_string;
+  std::map UnsavedFileContents;
 public:
   std::string TestDir;
   CXIndex Index;
   CXTranslationUnit ClangTU;
   unsigned TUFlags;
+  std::vector UnsavedFiles;
 
   void SetUp() override {
 llvm::SmallString<256> Dir;
 ASSERT_FALSE(llvm::sys::fs::createUniqueDirectory("libclang-test", Dir));
 TestDir = Dir.str();
 TUFlags = CXTranslationUnit_DetailedPreprocessingRecord |
-  clang_defaultEditingTranslationUnitOptions();
+  clang_defaultEditingTranslationUnitOptions();
 Index = clang_createIndex(0, 0);
+ClangTU = nullptr;
   }
   void TearDown() override {
 clang_disposeTranslationUnit(ClangTU);
@@ -384,6 +391,64 @@
 OS << Contents;
 assert(OS.good());
   }
+  void MapUnsavedFile(const char* name, const std::string ) {
+auto it = UnsavedFileContents.emplace(
+fixed_addr_string(new std::string(name)),
+fixed_addr_string(new std::string(contents)));
+UnsavedFiles.push_back({
+it.first->first->c_str(),   // filename
+it.first->second->c_str(),  // contents
+it.first->second->size()// length
+});
+  }
+  template
+  void Traverse(const F ) {
+CXCursor TuCursor = clang_getTranslationUnitCursor(ClangTU);
+std::reference_wrapper FunctorRef = std::cref(TraversalFunctor);
+clang_visitChildren(TuCursor,
+,
+);
+  }
+
+private:
+  template
+  static CXChildVisitResult TraverseStateless(CXCursor cx, CXCursor parent,
+  CXClientData data) {
+TState *State = static_cast(data);
+return State->get()(cx, parent);
+  }
+};
+
+TEST_F(LibclangParseTest, SpellingLocation) {
+  MapUnsavedFile("main.cpp",
+"#define BANANAS 4011\n"
+"int plu = BANANAS;");
+
+  ClangTU = clang_parseTranslationUnit(Index, "main.cpp", nullptr, 0,
+UnsavedFiles.data(), UnsavedFiles.size(), TUFlags);
+
+  bool sawInt = false;
+  Traverse([&](CXCursor cx, CXCursor) {
+if (cx.kind == CXCursor_IntegerLiteral) {
+  sawInt = true;
+  auto cxl = clang_getCursorLocation(cx);
+  CXFile expansionFile, spellingFile;
+  unsigned line, column, offset;
+  clang_getSpellingLocation(cxl, , , nullptr, nullptr);
+  EXPECT_EQ(2, line);  // getSpellingLocation returns expansion location
+  clang_getRealSpellingLocation(cxl, , , , );
+  EXPECT_TRUE(clang_File_isEqual(expansionFile, spellingFile));
+  EXPECT_EQ(1, line);
+  EXPECT_EQ(17, column);
+  EXPECT_EQ(16, offset);
+}
+return CXChildVisit_Recurse;
+  });
+  EXPECT_TRUE(sawInt);
+}
+
+class LibclangReparseTest : public LibclangParseTest {
+public:
   void DisplayDiagnostics() {
 unsigned NumDiagnostics = clang_getNumDiagnostics(ClangTU);
 for (unsigned i = 0; i < NumDiagnostics; ++i) {
Index: tools/libclang/CXSourceLocation.cpp
===
--- tools/libclang/CXSourceLocation.cpp
+++ tools/libclang/CXSourceLocation.cpp
@@ -346,6 +346,42 @@
 *offset = FileOffset;
 }
 
+void clang_getRealSpellingLocation(CXSourceLocation location,
+   CXFile *file,
+   unsigned *line,
+   unsigned *column,
+   unsigned *offset) {
+
+  if (!isASTUnitSourceLocation(location)) {
+CXLoadedDiagnostic::decodeLocation(location, file, line, column, offset);
+return;
+  }
+
+  SourceLocation Loc = SourceLocation::getFromRawEncoding(location.int_data);
+
+  if (!location.ptr_data[0] || Loc.isInvalid())
+return createNullLocation(file, line, column, offset);
+
+  const SourceManager  =
+  *static_cast(location.ptr_data[0]);
+  SourceLocation SpellLoc = SM.getSpellingLoc(Loc);
+  std::pair LocInfo = SM.getDecomposedLoc(SpellLoc);
+  FileID FID = LocInfo.first;
+  unsigned FileOffset = LocInfo.second;
+
+  if (FID.isInvalid())
+return createNullLocation(file, line, column, offset);
+
+  if (file)
+*file = const_cast(SM.getFileEntryForID(FID));
+  if (line)
+*line = SM.getLineNumber(FID, FileOffset);
+  if (column)
+*column

1 2 >

1 - 100 of 164 matches

Mail list logo