r246375 - Update for several APIs in LLVM that now use StringRefs rather than

2015-08-30 Thread Chandler Carruth via cfe-commits
Author: chandlerc
Date: Sun Aug 30 02:51:18 2015
New Revision: 246375

URL: http://llvm.org/viewvc/llvm-project?rev=246375&view=rev
Log:
Update for several APIs in LLVM that now use StringRefs rather than
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=246375&r1=246374&r2=246375&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Sun Aug 30 02:51:18 2015
@@ -4241,18 +4241,15 @@ class ARMTargetInfo : public TargetInfo
   }
 
   StringRef getDefaultCPU(StringRef ArchName) const {
-const char *DefaultCPU = llvm::ARM::getDefaultCPU(ArchName);
-return DefaultCPU ? DefaultCPU : "";
+return llvm::ARM::getDefaultCPU(ArchName);
   }
 
   StringRef getCPUAttr() const {
-const char *CPUAttr;
 // For most sub-arches, the build attribute CPU name is enough.
 // For Cortex variants, it's slightly different.
 switch(ArchKind) {
 default:
-  CPUAttr = llvm::ARM::getCPUAttr(ArchKind);
-  return CPUAttr ? CPUAttr : "";
+  return llvm::ARM::getCPUAttr(ArchKind);
 case llvm::ARM::AK_ARMV6M:
 case llvm::ARM::AK_ARMV6SM:
 case llvm::ARM::AK_ARMV6HL:

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=246375&r1=246374&r2=246375&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Sun Aug 30 02:51:18 2015
@@ -310,9 +310,10 @@ std::string ToolChain::ComputeLLVMTriple
   MCPU = A->getValue();
 if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
   MArch = A->getValue();
-std::string CPU = Triple.isOSBinFormatMachO()
-  ? tools::arm::getARMCPUForMArch(MArch, Triple)
-  : tools::arm::getARMTargetCPU(MCPU, MArch, Triple);
+std::string CPU =
+Triple.isOSBinFormatMachO()
+? tools::arm::getARMCPUForMArch(MArch, Triple).str()
+: tools::arm::getARMTargetCPU(MCPU, MArch, Triple);
 StringRef Suffix =
   tools::arm::getLLVMArchSuffixForARM(CPU,
   tools::arm::getARMArch(MArch, 
Triple));

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=246375&r1=246374&r2=246375&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Aug 30 02:51:18 2015
@@ -559,7 +559,7 @@ static void checkARMCPUName(const Driver
 const llvm::Triple &Triple) {
   std::string CPU = arm::getARMTargetCPU(CPUName, ArchName, Triple);
   std::string Arch = arm::getARMArch(ArchName, Triple);
-  if (strcmp(arm::getLLVMArchSuffixForARM(CPU, Arch), "") == 0)
+  if (arm::getLLVMArchSuffixForARM(CPU, Arch).empty())
 D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
 }
 
@@ -6018,33 +6018,30 @@ const std::string arm::getARMArch(String
 std::string CPU = llvm::sys::getHostCPUName();
 if (CPU != "generic") {
   // Translate the native cpu into the architecture suffix for that CPU.
-  const char *Suffix = arm::getLLVMArchSuffixForARM(CPU, MArch);
+  StringRef Suffix = arm::getLLVMArchSuffixForARM(CPU, MArch);
   // If there is no valid architecture suffix for this CPU we don't know 
how
   // to handle it, so return no architecture.
-  if (strcmp(Suffix, "") == 0)
+  if (Suffix.empty())
 MArch = "";
   else
-MArch = std::string("arm") + Suffix;
+MArch = std::string("arm") + Suffix.str();
 }
   }
 
   return MArch;
 }
+
 /// Get the (LLVM) name of the minimum ARM CPU for the arch we are targeting.
-const char *arm::getARMCPUForMArch(StringRef Arch, const llvm::Triple &Triple) 
{
+StringRef arm::getARMCPUForMArch(StringRef Arch, const llvm::Triple &Triple) {
   std::string MArch = getARMArch(Arch, Triple);
   // getARMCPUForArch defaults to the triple if MArch is empty, but empty MArch
   // here means an -march=native that we can't handle, so instead return no 
CPU.
   if (MArch.empty())
-return "";
+return StringRef();
 
   // We need to return an empty string here on invalid MArch values as the
   // various places that call this function can't cope with a null result.
-  const char *result = Triple.getARMCPUForArch(MArch);
-  if (result)
-return result;
-  else
-return "";
+  return Triple.getARMCPUForArch(MArch);
 }
 
 /// g

Re: r246375 - Update for several APIs in LLVM that now use StringRefs rather than

2015-08-30 Thread Renato Golin via cfe-commits
On 30 August 2015 at 08:51, Chandler Carruth via cfe-commits
 wrote:
> Author: chandlerc
> Date: Sun Aug 30 02:51:18 2015
> New Revision: 246375
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246375&view=rev
> Log:
> Update for several APIs in LLVM that now use StringRefs rather than
> const char pointers. In turn, push this through Clang APIs as well,
> simplifying a number of bits of code that was handling the oddities of
> nullptrs.

Thanks! I meant to clean that up at one point, but got lost in the noise. :)

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


Re: [PATCH] D12471: Correct documentation for numSelectorArgs matcher

2015-08-30 Thread Manuel Klimek via cfe-commits
klimek added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:2140-2153
@@ -2139,16 +2139,16 @@
 
 /// \brief Matches when the selector has the specified number of arguments
 ///
-///  matcher = objCMessageExpr(numSelectorArgs(1));
+///  matcher = objCMessageExpr(numSelectorArgs(0));
 ///  matches self.bodyView in the code below
 ///
 ///  matcher = objCMessageExpr(numSelectorArgs(2));
 ///  matches the invocation of "loadHTMLString:baseURL:" but not that
 ///  of self.bodyView
 /// \code
 /// [self.bodyView loadHTMLString:html baseURL:NULL];
 /// \endcode
 AST_MATCHER_P(ObjCMessageExpr, numSelectorArgs, unsigned, N) {
   return Node.getSelector().getNumArgs() == N;
 }


It seems like numSelectorArgs is missing unit tests - it might be good to add 
one, so we're sure the documented version now works and is tested :)


http://reviews.llvm.org/D12471



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


Re: [PATCH] D12462: [PATCH] [clang-tidy] Add inconsistent declaration parameter name check

2015-08-30 Thread Piotr Dziwinski via cfe-commits
piotrdz removed rL LLVM as the repository for this revision.
piotrdz updated this revision to Diff 33527.
piotrdz added a comment.

I noticed a few things I should have done better:

- use std::set instead of std::unordered_set (it doesn't seem to be used 
elsewhere)
- move checking set of reported functions to just before emitting diagnostic
- improved documentation
- changed diff directory to inside clang-tools-extra repository


http://reviews.llvm.org/D12462

Files:
  clang-tidy/readability/CMakeLists.txt
  clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp
  clang-tidy/readability/InconsistentDeclarationParameterNameCheck.h
  clang-tidy/readability/ReadabilityTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
  test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp

Index: test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
===
--- test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
+++ test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
@@ -0,0 +1,20 @@
+// RUN: %python %S/check_clang_tidy.py %s readability-inconsistent-declaration-parameter-name %t
+
+void consistentFunction(int a, int b, int c);
+void consistentFunction(int a, int b, int c);
+void consistentFunction(int a, int b, int /*c*/);
+void consistentFunction(int /*c*/, int /*c*/, int /*c*/);
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'inconsistentFunction' has other declaration with different parameter name(s) [readability-inconsistent-declaration-parameter-name]
+void inconsistentFunction(int a, int b, int c);
+void inconsistentFunction(int d, int e, int f);
+void inconsistentFunction(int x, int y, int z);
+
+struct SomeStruct
+{
+// CHECK-MESSAGES: :[[@LINE+1]]:10: warning:  function 'SomeStruct::inconsistentFunction' has other declaration with different parameter name(s) [readability-inconsistent-declaration-parameter-name]
+void inconsistentFunction(int a);
+};
+
+void SomeStruct::inconsistentFunction(int b)
+{}
Index: docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
===
--- docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
+++ docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
@@ -0,0 +1,29 @@
+readability-inconsistent-declaration-parameter-name
+===
+
+
+Find function declarations which differ in parameter names.
+
+Example:
+
+.. code:: c++
+
+  // in foo.hpp:
+  void foo(int a, int b, int c);
+
+  // in foo.cpp:
+  void foo(int d, int e, int f); // warning
+
+This check should help to enforce consistency in large projects, where it often happens
+that a definition of function is refactored, changing the parameter names, but its declaration
+in header file is not updated. With this check, we can easily find and correct such inconsistencies,
+keeping declaration and definition always in sync.
+
+Unnamed parameters are allowed and are not taken into account when comparing function declarations, for example:
+
+.. code:: c++
+
+   void foo(int a);
+   void foo(int); // no warning
+
+If there are multiple declarations of same function, only one warning will be generated.
\ No newline at end of file
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -47,6 +47,7 @@
readability-else-after-return
readability-function-size
readability-identifier-naming
+   readability-inconsistent-declaration-parameter-name
readability-named-parameter
readability-redundant-smartptr-get
readability-redundant-string-cstr
Index: clang-tidy/readability/ReadabilityTidyModule.cpp
===
--- clang-tidy/readability/ReadabilityTidyModule.cpp
+++ clang-tidy/readability/ReadabilityTidyModule.cpp
@@ -15,6 +15,7 @@
 #include "ElseAfterReturnCheck.h"
 #include "FunctionSizeCheck.h"
 #include "IdentifierNamingCheck.h"
+#include "InconsistentDeclarationParameterNameCheck.h"
 #include "NamedParameterCheck.h"
 #include "RedundantSmartptrGetCheck.h"
 #include "RedundantStringCStrCheck.h"
@@ -38,6 +39,8 @@
 "readability-function-size");
 CheckFactories.registerCheck(
 "readability-identifier-naming");
+CheckFactories.registerCheck(
+"readability-inconsistent-declaration-parameter-name");
 CheckFactories.registerCheck(
 "readability-named-parameter");
 CheckFactories.registerCheck(
Index: clang-tidy/readability/InconsistentDeclarationParameterNameCheck.h
===
--- clang-tidy/readability/InconsistentDeclarationParam

r246384 - [OpenMP] Make the filetered clause iterator a real iterator and type safe.

2015-08-30 Thread Benjamin Kramer via cfe-commits
Author: d0k
Date: Sun Aug 30 10:12:28 2015
New Revision: 246384

URL: http://llvm.org/viewvc/llvm-project?rev=246384&view=rev
Log:
[OpenMP] Make the filetered clause iterator a real iterator and type safe.

This replaces the filtered generic iterator with a type-specfic one based
on dyn_cast instead of comparing the kind enum. This allows us to use
range-based for loops and eliminates casts. No functionality change
intended.

Modified:
cfe/trunk/include/clang/AST/StmtOpenMP.h
cfe/trunk/lib/AST/Stmt.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/include/clang/AST/StmtOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/StmtOpenMP.h?rev=246384&r1=246383&r2=246384&view=diff
==
--- cfe/trunk/include/clang/AST/StmtOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/StmtOpenMP.h Sun Aug 30 10:12:28 2015
@@ -92,65 +92,91 @@ public:
   /// \brief Iterates over a filtered subrange of clauses applied to a
   /// directive.
   ///
-  /// This iterator visits only those declarations that meet some run-time
-  /// criteria.
-  template  class filtered_clause_iterator {
-  protected:
+  /// This iterator visits only clauses of type SpecificClause.
+  template 
+  class specific_clause_iterator
+  : public std::iterator {
 ArrayRef::const_iterator Current;
 ArrayRef::const_iterator End;
-FilterPredicate Pred;
+
 void SkipToNextClause() {
-  while (Current != End && !Pred(*Current))
+  while (Current != End && !isa(*Current))
 ++Current;
 }
 
   public:
-typedef const OMPClause *value_type;
-filtered_clause_iterator() : Current(), End() {}
-filtered_clause_iterator(ArrayRef Arr, FilterPredicate Pred)
-: Current(Arr.begin()), End(Arr.end()), Pred(std::move(Pred)) {
+explicit specific_clause_iterator(ArrayRef Clauses)
+: Current(Clauses.begin()), End(Clauses.end()) {
   SkipToNextClause();
 }
-value_type operator*() const { return *Current; }
-value_type operator->() const { return *Current; }
-filtered_clause_iterator &operator++() {
+
+const SpecificClause *operator*() const {
+  return cast(*Current);
+}
+const SpecificClause *operator->() const {
+  return cast(*Current);
+}
+
+specific_clause_iterator &operator++() {
   ++Current;
   SkipToNextClause();
   return *this;
 }
-
-filtered_clause_iterator operator++(int) {
-  filtered_clause_iterator tmp(*this);
+specific_clause_iterator operator++(int) {
+  specific_clause_iterator tmp(*this);
   ++(*this);
   return tmp;
 }
 
-bool operator!() { return Current == End; }
-explicit operator bool() { return Current != End; }
-bool empty() const { return Current == End; }
+bool operator==(const specific_clause_iterator &RHS) const {
+  assert(End == RHS.End && "Comparing iterators of different directives!");
+  return Current == RHS.Current;
+}
+bool operator!=(const specific_clause_iterator &RHS) const {
+  return !(*this == RHS);
+}
   };
 
-  template 
-  filtered_clause_iterator getFilteredClauses(Fn &&fn) const {
-return filtered_clause_iterator(clauses(), std::move(fn));
+  template 
+  static llvm::iterator_range>
+  getClausesOfKind(ArrayRef Clauses) {
+return {specific_clause_iterator(Clauses),
+specific_clause_iterator(
+llvm::makeArrayRef(Clauses.end(), 0))};
   }
-  struct ClauseKindFilter {
-OpenMPClauseKind Kind;
-bool operator()(const OMPClause *clause) const {
-  return clause->getClauseKind() == Kind;
-}
-  };
-  filtered_clause_iterator
-  getClausesOfKind(OpenMPClauseKind Kind) const {
-return getFilteredClauses(ClauseKindFilter{Kind});
+
+  template 
+  llvm::iterator_range>
+  getClausesOfKind() const {
+return getClausesOfKind(clauses());
   }
 
-  /// \brief Gets a single clause of the specified kind \a K associated with 
the
+  /// Gets a single clause of the specified kind associated with the
   /// current directive iff there is only one clause of this kind (and 
assertion
   /// is fired if there is more than one clause is associated with the
-  /// directive). Returns nullptr if no clause of kind \a K is associated with
+  /// directive). Returns nullptr if no clause of this kind is associated with
   /// the directive.
-  const OMPClause *getSingleClause(OpenMPClauseKind K) const;
+  template 
+  const SpecificClause *getSingleClause() const {
+auto Clauses = getClausesOfKind();
+
+if (Clauses.begin() != Clauses.end()) {
+  assert(std::next(Clauses.begin()) == Clauses.end() &&
+ "There are at least 2 clauses of the specified kind");
+  return *Clauses.begin();
+}
+return nullptr;
+  }
+
+  /// Returns true if the current directive has one or more clauses of a
+  /// specific kind.
+  tem

[PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Piotr Dziwinski via cfe-commits
piotrdz created this revision.
piotrdz added a subscriber: cfe-commits.

This is another patch from my tool colobot-lint.

This adds a new check misc-old-style-function, which checks for instances of 
functions written in legacy C style.

As before, I hope I did everything according to LLVM style, including testcases 
and documentation.

If time allows, I will post another patch to extend this check with FixIt hints 
to localize variable declarations.

http://reviews.llvm.org/D12473

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/OldStyleFunctionCheck.cpp
  clang-tidy/misc/OldStyleFunctionCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-old-style-function.rst
  test/clang-tidy/misc-old-style-function.cpp

Index: test/clang-tidy/misc-old-style-function.cpp
===
--- test/clang-tidy/misc-old-style-function.cpp
+++ test/clang-tidy/misc-old-style-function.cpp
@@ -0,0 +1,86 @@
+// RUN: %python %S/check_clang_tidy.py %s misc-old-style-function %t -config="{CheckOptions: [{key: misc-old-style-function.DeclarationAndFirstUseDistanceThreshold, value: 4}]}" --
+
+int fooInt();
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'oldStyleFunctionOneIntVariable' seems to be written in legacy C style: it has an uninitialized POD type variable declared far from its point of use: 'x' [misc-old-style-function]
+void oldStyleFunctionOneIntVariable() {
+  int x;
+  //
+  //
+  //
+  x = fooInt();
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'oldStyleFunctionTwoIntVariables' seems to be written in legacy C style: it has 2 uninitialized POD type variables declared far from their point of use: 'x', 'y' [misc-old-style-function]
+void oldStyleFunctionTwoIntVariables() {
+  int x, y;
+  //
+  //
+  //
+  x = fooInt();
+  y = x + 2;
+}
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'oldStyleFunctionManyIntVariables' seems to be written in legacy C style: it has 7 uninitialized POD type variables declared far from their point of use: 'a', 'b', 'c', 'd', 'e'... [misc-old-style-function]
+void oldStyleFunctionManyIntVariables() {
+  int a, b, c, d, e, f, g;
+  //
+  //
+  //
+  a = b = c = d = e = f = g = fooInt();
+}
+
+struct Pod {
+  int a;
+};
+
+Pod fooPod();
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'oldStyleFunctionWithUserDefinedPodTypeVariable' seems to be written in legacy C style: it has an uninitialized POD type variable declared far from its point of use: 'x' [misc-old-style-function]
+void oldStyleFunctionWithUserDefinedPodTypeVariable() {
+  Pod x;
+  //
+  //
+  //
+  x = fooPod();
+}
+
+void functionWithDeclarationAndFirstUseBelowThreshold() {
+  int x;
+  //
+  //
+  x = fooInt();
+}
+
+void functionWithInitializedVariables() {
+  int x = 0, y = 0;
+  //
+  //
+  //
+  x = fooInt();
+  y = x + 2;
+}
+
+struct NonPod {
+  int a = 0;
+};
+
+NonPod fooNonPod();
+
+void functionWithNonPodTypeVariables() {
+  NonPod x, y;
+  //
+  //
+  //
+  x = fooNonPod();
+  y = fooNonPod();
+}
+
+void ignoreFunctionParameters(int& x, int &y) {
+  //
+  //
+  //
+  x = fooInt();
+  y = x + 2;
+}
+
Index: docs/clang-tidy/checks/misc-old-style-function.rst
===
--- docs/clang-tidy/checks/misc-old-style-function.rst
+++ docs/clang-tidy/checks/misc-old-style-function.rst
@@ -0,0 +1,24 @@
+misc-old-style-function
+===
+
+
+This check finds instances of functions, which use legacy C style of declaring
+all variables in a function at the beginning of function scope.
+
+Example:
+
+.. code:: c++
+
+  void foo() {
+int a, x;
+// after many lines in between, first use of variables:
+a = bar();
+for (i = 0; i < 10; i++) { /*...*/ }
+  }
+
+A given variable is considered written in legacy style if:
+ - it is a local variable of POD type
+ - its declaration does not have initialization
+ - its declaration and first use in function are separated by more than
+   a certain number of lines of code; this number is configured by
+   parameter `DeclarationAndFirstUseDistanceThreshold` with default vaule of 3
\ No newline at end of file
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -31,6 +31,7 @@
misc-macro-repeated-side-effects
misc-move-constructor-init
misc-noexcept-move-constructor
+   misc-old-style-function
misc-static-assert
misc-swapped-arguments
misc-undelegated-constructor
Index: clang-tidy/misc/OldStyleFunctionCheck.h
===
--- clang-tidy/misc/OldStyleFunctionCheck.h
+++ clang-tidy/misc/OldStyleFunctionCheck.h
@@ -0,0 +1,63 @@
+//===--- OldStyleFunctionCheck.h - clang-tidy*- C++ -*-===//
+//
+// The LLVM Compiler Inf

r246385 - Make test resistant to false matches of numbered (unnamed) labels inside other numbers.

2015-08-30 Thread Yaron Keren via cfe-commits
Author: yrnkrn
Date: Sun Aug 30 10:24:46 2015
New Revision: 246385

URL: http://llvm.org/viewvc/llvm-project?rev=246385&view=rev
Log:
Make test resistant to false matches of numbered (unnamed) labels inside other 
numbers.

In release builds labels are numbers. Matching just the number may result
in false matches where the label is contained in other numbers, such as
14 inside [114 x i8]. A stricter match requiring start of line or > character
before the label avoids these false matches.


Modified:
cfe/trunk/test/CodeGen/sanitize-trap.c

Modified: cfe/trunk/test/CodeGen/sanitize-trap.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sanitize-trap.c?rev=246385&r1=246384&r2=246385&view=diff
==
--- cfe/trunk/test/CodeGen/sanitize-trap.c (original)
+++ cfe/trunk/test/CodeGen/sanitize-trap.c Sun Aug 30 10:24:46 2015
@@ -7,19 +7,24 @@ int f(int x, int y) {
   // CHECK: %[[B4:.*]] = or i1 %[[B2]], %[[B3]]
   // CHECK: br i1 %[[B1]], label %[[L1:[0-9a-z_.]*]], label %[[L2:[0-9a-z_.]*]]
 
-  // CHECK: [[L2]]
+  // {{^|>}} used to match both Debug form of the captured label
+  // cont:
+  // and Release form
+  // ; 14
+  // But avoids false matches inside other numbers such as [114 x i8].
+  // CHECK: {{^|>}}[[L2]]
   // CHECK-NEXT: call void @llvm.trap()
   // CHECK-NEXT: unreachable
 
-  // CHECK: [[L1]]
+  // CHECK: {{^|>}}[[L1]]
   // CHECK-NEXT: br i1 %[[B4]], label %[[L3:[0-9a-z_.]*]], label 
%[[L4:[0-9a-z_.]*]]
 
-  // CHECK: [[L4]]
+  // CHECK: {{^|>}}[[L4]]
   // CHECK-NEXT: zext
   // CHECK-NEXT: zext
   // CHECK-NEXT: __ubsan_handle_divrem_overflow
 
-  // CHECK: [[L3]]
+  // CHECK: {{^|>}}[[L3]]
   // CHECK-NEXT: sdiv i32 %[[N]], %[[D]]
   return x / y;
 }


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


[PATCH] D12482: Analyzer: Teach analyzer how to handle TypeTraitExpr

2015-08-30 Thread Ismail Pazarbasi via cfe-commits
ismailp created this revision.
ismailp added reviewers: zaks.anna, dcoughlin, krememek.
ismailp added a subscriber: cfe-commits.

`TypeTraitExpr`s are not supported by the ExprEngine today. Analyzer
creates a sink, and aborts the block. Therefore, certain bugs that
involve type traits intrinsics cannot be detected (see PR24710).

This patch creates boolean `SVal`s for `TypeTraitExpr`s, which are
evaluated by the compiler.

Test within the patch is a summary of PR24710.

http://reviews.llvm.org/D12482

Files:
  lib/StaticAnalyzer/Core/Environment.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/SValBuilder.cpp
  test/Analysis/dtor.cpp

Index: test/Analysis/dtor.cpp
===
--- test/Analysis/dtor.cpp
+++ test/Analysis/dtor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection -analyzer-config c++-inlining=destructors,cfg-temporary-dtors=true -Wno-null-dereference -Wno-inaccessible-base -verify %s
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection,cplusplus -analyzer-config c++-inlining=destructors,cfg-temporary-dtors=true -Wno-null-dereference -Wno-inaccessible-base -verify %s
 
 void clang_analyzer_eval(bool);
 void clang_analyzer_checkInlined(bool);
@@ -505,3 +505,36 @@
   class Foo; // expected-note{{forward declaration}}
   void f(Foo *foo) { delete foo; } // expected-warning{{deleting pointer to incomplete type}}
 }
+
+namespace TypeTraitExpr {
+template 
+struct copier {
+  static void do_copy(T *dest, const T *src, unsigned count);
+};
+template 
+void do_copy(T *dest, const U *src, unsigned count) {
+  const bool IsSimple = __is_trivial(T) && __is_same(T, U);
+  copier::do_copy(dest, src, count);
+}
+struct NonTrivial {
+  int *p;
+  NonTrivial() : p(new int[1]) { p[0] = 0; }
+  NonTrivial(const NonTrivial &other) {
+p = new int[1];
+do_copy(p, other.p, 1);
+  }
+  NonTrivial &operator=(const NonTrivial &other) {
+p = other.p;
+return *this;
+  }
+  ~NonTrivial() {
+delete[] p; // expected-warning {{free released memory}}
+  }
+};
+
+void f() {
+  NonTrivial nt1;
+  NonTrivial nt2(nt1);
+  nt1 = nt2;
+}
+}
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -259,6 +259,11 @@
   case Stmt::CXXBoolLiteralExprClass:
 return makeBoolVal(cast(E));
 
+  case Stmt::TypeTraitExprClass: {
+const TypeTraitExpr *TE = cast(E);
+return makeTruthVal(TE->getValue(), TE->getType());;
+  }
+
   case Stmt::IntegerLiteralClass:
 return makeIntVal(cast(E));
 
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -756,7 +756,6 @@
 case Stmt::MSPropertyRefExprClass:
 case Stmt::CXXUnresolvedConstructExprClass:
 case Stmt::DependentScopeDeclRefExprClass:
-case Stmt::TypeTraitExprClass:
 case Stmt::ArrayTypeTraitExprClass:
 case Stmt::ExpressionTraitExprClass:
 case Stmt::UnresolvedLookupExprClass:
@@ -775,7 +774,7 @@
   Engine.addAbortedBlock(node, currBldrCtx->getBlock());
   break;
 }
-
+
 case Stmt::ParenExprClass:
   llvm_unreachable("ParenExprs already handled.");
 case Stmt::GenericSelectionExprClass:
@@ -902,6 +901,7 @@
 case Stmt::ObjCStringLiteralClass:
 case Stmt::CXXPseudoDestructorExprClass:
 case Stmt::SubstNonTypeTemplateParmExprClass:
+case Stmt::TypeTraitExprClass:
 case Stmt::CXXNullPtrLiteralExprClass: {
   Bldr.takeNodes(Pred);
   ExplodedNodeSet preVisit;
Index: lib/StaticAnalyzer/Core/Environment.cpp
===
--- lib/StaticAnalyzer/Core/Environment.cpp
+++ lib/StaticAnalyzer/Core/Environment.cpp
@@ -90,6 +90,7 @@
   case Stmt::CXXNullPtrLiteralExprClass:
   case Stmt::ObjCStringLiteralClass:
   case Stmt::StringLiteralClass:
+  case Stmt::TypeTraitExprClass:
 // Known constants; defer to SValBuilder.
 return svalBuilder.getConstantVal(cast(S)).getValue();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r246391 - Fix test for Release builds, the label form is :14, not 14.

2015-08-30 Thread Yaron Keren via cfe-commits
Author: yrnkrn
Date: Sun Aug 30 12:46:43 2015
New Revision: 246391

URL: http://llvm.org/viewvc/llvm-project?rev=246391&view=rev
Log:
Fix test for Release builds, the label form is :14, not 14.


Modified:
cfe/trunk/test/CodeGen/sanitize-trap.c

Modified: cfe/trunk/test/CodeGen/sanitize-trap.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sanitize-trap.c?rev=246391&r1=246390&r2=246391&view=diff
==
--- cfe/trunk/test/CodeGen/sanitize-trap.c (original)
+++ cfe/trunk/test/CodeGen/sanitize-trap.c Sun Aug 30 12:46:43 2015
@@ -7,24 +7,24 @@ int f(int x, int y) {
   // CHECK: %[[B4:.*]] = or i1 %[[B2]], %[[B3]]
   // CHECK: br i1 %[[B1]], label %[[L1:[0-9a-z_.]*]], label %[[L2:[0-9a-z_.]*]]
 
-  // {{^|>}} used to match both Debug form of the captured label
+  // {{^|:}} used to match both Debug form of the captured label
   // cont:
   // and Release form
-  // ; 14
+  // ; :14
   // But avoids false matches inside other numbers such as [114 x i8].
-  // CHECK: {{^|>}}[[L2]]
+  // CHECK: {{^|:}}[[L2]]
   // CHECK-NEXT: call void @llvm.trap()
   // CHECK-NEXT: unreachable
 
-  // CHECK: {{^|>}}[[L1]]
+  // CHECK: {{^|:}}[[L1]]
   // CHECK-NEXT: br i1 %[[B4]], label %[[L3:[0-9a-z_.]*]], label 
%[[L4:[0-9a-z_.]*]]
 
-  // CHECK: {{^|>}}[[L4]]
+  // CHECK: {{^|:}}[[L4]]
   // CHECK-NEXT: zext
   // CHECK-NEXT: zext
   // CHECK-NEXT: __ubsan_handle_divrem_overflow
 
-  // CHECK: {{^|>}}[[L3]]
+  // CHECK: {{^|:}}[[L3]]
   // CHECK-NEXT: sdiv i32 %[[N]], %[[D]]
   return x / y;
 }


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


[libcxx] r246392 - Remove task to get C++03 tests passing from TODO.txt

2015-08-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Sun Aug 30 12:58:50 2015
New Revision: 246392

URL: http://llvm.org/viewvc/llvm-project?rev=246392&view=rev
Log:
Remove task to get C++03 tests passing from TODO.txt

Modified:
libcxx/trunk/TODO.TXT
libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp

Modified: libcxx/trunk/TODO.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/TODO.TXT?rev=246392&r1=246391&r2=246392&view=diff
==
--- libcxx/trunk/TODO.TXT (original)
+++ libcxx/trunk/TODO.TXT Sun Aug 30 12:58:50 2015
@@ -39,7 +39,6 @@ Atomic Related Tasks
 
 Test Suite Tasks
 
-* Get test suite passing in C++03.
 * Move all libc++ specific tests from test/std into test/libcxx.
 * Improve how LIT handles compiler warnings.
 * Improve the quality and portability of the locale test data.

Modified: libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp?rev=246392&r1=246391&r2=246392&view=diff
==
--- libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp (original)
+++ libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp Sun Aug 30 
12:58:50 2015
@@ -41,7 +41,7 @@ extern "C" void LLVMFuzzerTestOneInput(c
 
 void fuzz_tests()  // patterns that the fuzzer has found
 {
-// Raw string literals are a C++11
+// Raw string literals are a C++11 feature.
 #if TEST_STD_VER >= 11
 
LLVMFuzzerTestOneInput(R"XX(Õ)_%()()((\8'_%()_%()_%()_%(()_%()_%()_%(.t;)()¥f()_%()(.)_%;)()!¥f)()XX");
 #endif


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


r246393 - [OpenCL] Improve diagnostics detecting implicit vector conversion.

2015-08-30 Thread Alexey Bader via cfe-commits
Author: bader
Date: Sun Aug 30 13:06:39 2015
New Revision: 246393

URL: http://llvm.org/viewvc/llvm-project?rev=246393&view=rev
Log:
[OpenCL] Improve diagnostics detecting implicit vector conversion.

Reviewers: pekka.jaaskelainen

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


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/SemaOpenCL/cond.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=246393&r1=246392&r2=246393&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Sun Aug 30 13:06:39 
2015
@@ -7445,6 +7445,8 @@ def err_opencl_return_value_with_address
   "return value cannot be qualified with address space">;
 def err_opencl_constant_no_init : Error<
   "variable in constant address space must be initialized">;
+def err_opencl_implicit_vector_conversion : Error<
+  "implicit conversions between vector types (%0 and %1) are not permitted">;
 } // end of sema category
 
 let CategoryName = "OpenMP Issue" in {

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=246393&r1=246392&r2=246393&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Sun Aug 30 13:06:39 2015
@@ -7534,6 +7534,18 @@ QualType Sema::CheckVectorOperands(ExprR
 return QualType();
   }
 
+  // OpenCL V1.1 6.2.6.p1:
+  // If the operands are of more than one vector type, then an error shall
+  // occur. Implicit conversions between vector types are not permitted, per
+  // section 6.2.1.
+  if (getLangOpts().OpenCL &&
+  RHSVecType && isa(RHSVecType) &&
+  LHSVecType && isa(LHSVecType)) {
+Diag(Loc, diag::err_opencl_implicit_vector_conversion) << LHSType
+   << RHSType;
+return QualType();
+  }
+
   // Otherwise, use the generic diagnostic.
   Diag(Loc, diag::err_typecheck_vector_not_convertable)
 << LHSType << RHSType

Modified: cfe/trunk/test/SemaOpenCL/cond.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/cond.cl?rev=246393&r1=246392&r2=246393&view=diff
==
--- cfe/trunk/test/SemaOpenCL/cond.cl (original)
+++ cfe/trunk/test/SemaOpenCL/cond.cl Sun Aug 30 13:06:39 2015
@@ -84,7 +84,7 @@ uchar2 ntest03(int2 C, uchar X, uchar Y)
 
 float2 ntest04(int2 C, int2 X, float2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values 
of different size ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 
'float' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector 
types ('int2' (vector of 2 'int' values) and 'float2' (vector of 2 'float' 
values)) are not permitted}}
 }
 
 float2 ntest05(int2 C, int2 X, float Y)
@@ -115,7 +115,7 @@ int2 ntest09(int2 C, global int *X, glob
 
 char3 ntest10(char C, char3 X, char2 Y)
 {
-  return C ? X : Y; // expected-error {{cannot convert between vector values 
of different size ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 
'char' values))}}
+  return C ? X : Y; // expected-error {{implicit conversions between vector 
types ('char3' (vector of 3 'char' values) and 'char2' (vector of 2 'char' 
values)) are not permitted}}
 }
 
 char3 ntest11(char2 C, char3 X, char Y)


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


Re: [PATCH] D12378: [OpenCL] Improve diagnostics detecting implicit vector conversion.

2015-08-30 Thread Alexey Bader via cfe-commits
bader closed this revision.
bader added a comment.

Thanks! Committed at rev. 246393.


http://reviews.llvm.org/D12378



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


Re: [PATCH] D11963: Create a __config_site file to capture configuration decisions.

2015-08-30 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

In http://reviews.llvm.org/D11963#235148, @jroelofs wrote:

> In http://reviews.llvm.org/D11963#234789, @EricWF wrote:
>
> > Copy the headers to the build directory during every build instead of just 
> > during CMake configuration.
>
>
> Sounds like this would cause every build to effectively be a full build. I 
> don't think we want that...
>
> If that's the case, then I think we should use the same trick that TableGen 
> uses: write the new file to a temporary, and overwrite it iff they differ.


So that's not what happens but that's because libc++ builds using the headers 
in the source directory. During the build all of the macros in the 
__config_site file are manually defined on the command line so that we don't 
need to use the generated headers. NOTE: The tests still use the generated 
headers though.


http://reviews.llvm.org/D11963



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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Eugene Zelenko via cfe-commits
Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

I think extern "C" functions should be kept with (void).

I may be mistaken, but looks like code doesn't check for in C++ mode.


http://reviews.llvm.org/D12473



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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Eugene Zelenko via cfe-commits
Eugene.Zelenko added a comment.

Just for reference:

- Previous attempt: http://reviews.llvm.org/D7639.

- Bugzilla request .


http://reviews.llvm.org/D12473



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


Re: [PATCH] D11976: [libclang] Return deduced type for auto type, not the one written in the source.

2015-08-30 Thread Manuel Klimek via cfe-commits
klimek added a subscriber: klimek.
klimek accepted this revision.
klimek added a reviewer: klimek.
klimek added a comment.
This revision is now accepted and ready to land.

As this doesn't break any old tests, and fixes a significant number of issues, 
LG.
Do you need me to submit?


http://reviews.llvm.org/D11976



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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Piotr Dziwinski via cfe-commits
piotrdz added a comment.

@Eugene: I don't understand, what does declaring function with "void" argument 
have in common with this review? I only check here variable declarations inside 
functions.

Maybe you meant my other review for inconsistent declaration parameter names? 
If so, this is how it behaves currently:

  $ cat test.c
  void allright();
  void allright(void);
  
  void notallright(int a);
  void notallright(int b);
  
  $ clang-tidy -checks='-*,readability-inconsistent-declaration-parameter-name' 
test.c -- -std=c11
  1 warning generated.
  /work/clang-trunk/test.c:4:6: warning: function 'notallright' has other 
declaration with different parameter name(s) 
[readability-inconsistent-declaration-parameter-name]
  void notallright(int a);
   ^
  /work/clang-trunk/test.c:5:6: note: other declaration seen here
  void notallright(int b);

So I see no reason to add specific checks for functions with "void" parameter, 
unless you see something wrong with this behavior?


http://reviews.llvm.org/D12473



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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Aaron Ballman via cfe-commits
On Sun, Aug 30, 2015 at 4:39 PM, Piotr Dziwinski via cfe-commits
 wrote:
> piotrdz added a comment.
>
> @Eugene: I don't understand, what does declaring function with "void" 
> argument have in common with this review? I only check here variable 
> declarations inside functions.
>
> Maybe you meant my other review for inconsistent declaration parameter names? 
> If so, this is how it behaves currently:
>
>   $ cat test.c
>   void allright();
>   void allright(void);
>
>   void notallright(int a);
>   void notallright(int b);
>
>   $ clang-tidy 
> -checks='-*,readability-inconsistent-declaration-parameter-name' test.c -- 
> -std=c11
>   1 warning generated.
>   /work/clang-trunk/test.c:4:6: warning: function 'notallright' has other 
> declaration with different parameter name(s) 
> [readability-inconsistent-declaration-parameter-name]
>   void notallright(int a);
>^
>   /work/clang-trunk/test.c:5:6: note: other declaration seen here
>   void notallright(int b);
>
> So I see no reason to add specific checks for functions with "void" 
> parameter, unless you see something wrong with this behavior?

In C, void allright(); is a function accepting a variable number of
arguments, and void alright(void); is a function accepting no
arguments. In C++, they are both functions accepting no arguments.

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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Piotr Dziwinski via cfe-commits
@Aaron: Yes, I'm aware of that. I wanted to show that my check does not 
take this into account.


In C++ this code is equivalent, so I think nothing should be reported, 
unless we really want to get rid of that void, but I suppose this other 
check does it already.


And when it comes to C, in well-formed C code, we should never see those 
two definitions of allright() and allright(void), as they are 
declarations of different functions. If I try to add empty bodies {} to 
define them, this example won't even compile.


So anyway, I still don't understand the problem here, unless somebody 
explains it in clearer terms.


Best regards,
Piotr Dziwinski

On 2015-08-30 22:43, Aaron Ballman wrote:

On Sun, Aug 30, 2015 at 4:39 PM, Piotr Dziwinski via cfe-commits
 wrote:

piotrdz added a comment.

@Eugene: I don't understand, what does declaring function with "void" argument 
have in common with this review? I only check here variable declarations inside functions.

Maybe you meant my other review for inconsistent declaration parameter names? 
If so, this is how it behaves currently:

   $ cat test.c
   void allright();
   void allright(void);

   void notallright(int a);
   void notallright(int b);

   $ clang-tidy 
-checks='-*,readability-inconsistent-declaration-parameter-name' test.c -- 
-std=c11
   1 warning generated.
   /work/clang-trunk/test.c:4:6: warning: function 'notallright' has other 
declaration with different parameter name(s) 
[readability-inconsistent-declaration-parameter-name]
   void notallright(int a);
^
   /work/clang-trunk/test.c:5:6: note: other declaration seen here
   void notallright(int b);

So I see no reason to add specific checks for functions with "void" parameter, 
unless you see something wrong with this behavior?

In C, void allright(); is a function accepting a variable number of
arguments, and void alright(void); is a function accepting no
arguments. In C++, they are both functions accepting no arguments.

~Aaron


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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Aaron Ballman via cfe-commits
On Sun, Aug 30, 2015 at 4:53 PM, Piotr Dziwinski  wrote:
> @Aaron: Yes, I'm aware of that. I wanted to show that my check does not take
> this into account.
>
> In C++ this code is equivalent, so I think nothing should be reported,
> unless we really want to get rid of that void, but I suppose this other
> check does it already.

I think that in C++, it would make sense for this to be reported as a
consistency issue. For instance, the declaration without void could be
in a header while the definition is in a source file.

> And when it comes to C, in well-formed C code, we should never see those two
> definitions of allright() and allright(void), as they are declarations of
> different functions. If I try to add empty bodies {} to define them, this
> example won't even compile.

Correct, but it also strikes me as weird that your test case is a .c
file and there are no diagnostics triggered helping the user to
understand that these are declaring different things. It's not until
you add the definition that you get a diagnostic. This shouldn't be a
clang-tidy diagnostic, but a frontend diagnostic. I'm not suggesting
you have to do that work, either. Merely commenting that 1) they're
different in C, 2) C++ programmer may be unaware of those differences,
3) this can cause real bugs, and 4) we currently fail to help the user
in a meaningful way.

http://coliru.stacked-crooked.com/a/59ba90b4d3ec5828

~Aaron

>
> So anyway, I still don't understand the problem here, unless somebody
> explains it in clearer terms.
>
> Best regards,
> Piotr Dziwinski
>
>
> On 2015-08-30 22:43, Aaron Ballman wrote:
>>
>> On Sun, Aug 30, 2015 at 4:39 PM, Piotr Dziwinski via cfe-commits
>>  wrote:
>>>
>>> piotrdz added a comment.
>>>
>>> @Eugene: I don't understand, what does declaring function with "void"
>>> argument have in common with this review? I only check here variable
>>> declarations inside functions.
>>>
>>> Maybe you meant my other review for inconsistent declaration parameter
>>> names? If so, this is how it behaves currently:
>>>
>>>$ cat test.c
>>>void allright();
>>>void allright(void);
>>>
>>>void notallright(int a);
>>>void notallright(int b);
>>>
>>>$ clang-tidy
>>> -checks='-*,readability-inconsistent-declaration-parameter-name' test.c --
>>> -std=c11
>>>1 warning generated.
>>>/work/clang-trunk/test.c:4:6: warning: function 'notallright' has
>>> other declaration with different parameter name(s)
>>> [readability-inconsistent-declaration-parameter-name]
>>>void notallright(int a);
>>> ^
>>>/work/clang-trunk/test.c:5:6: note: other declaration seen here
>>>void notallright(int b);
>>>
>>> So I see no reason to add specific checks for functions with "void"
>>> parameter, unless you see something wrong with this behavior?
>>
>> In C, void allright(); is a function accepting a variable number of
>> arguments, and void alright(void); is a function accepting no
>> arguments. In C++, they are both functions accepting no arguments.
>>
>> ~Aaron
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] r246399 - Suppress clang warnings in some tests

2015-08-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Sun Aug 30 17:04:20 2015
New Revision: 246399

URL: http://llvm.org/viewvc/llvm-project?rev=246399&view=rev
Log:
Suppress clang warnings in some tests

Modified:
libcxx/trunk/test/libcxx/double_include.sh.cpp
libcxx/trunk/test/libcxx/test/config.py

libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/const_T.pass.cpp

libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/in_place_t.pass.cpp

libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/rvalue_T.pass.cpp

libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.ops/assign_t.pass.cpp
libcxx/trunk/test/std/language.support/support.types/nullptr_t.pass.cpp

libcxx/trunk/test/std/utilities/memory/default.allocator/allocator.members/construct.pass.cpp

libcxx/trunk/test/std/utilities/meta/meta.rel/is_convertible_fallback.pass.cpp

Modified: libcxx/trunk/test/libcxx/double_include.sh.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/double_include.sh.cpp?rev=246399&r1=246398&r2=246399&view=diff
==
--- libcxx/trunk/test/libcxx/double_include.sh.cpp (original)
+++ libcxx/trunk/test/libcxx/double_include.sh.cpp Sun Aug 30 17:04:20 2015
@@ -15,6 +15,12 @@
 // RUN: %cxx -o %t.exe %t.first.o %t.second.o %flags %link_flags
 // RUN: %run
 
+
+// Prevent  from generating deprecated warnings for this test.
+#if defined(__DEPRECATED)
+#undef __DEPRECATED
+#endif
+
 #include 
 #include 
 #include 
@@ -50,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: libcxx/trunk/test/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/config.py?rev=246399&r1=246398&r2=246399&view=diff
==
--- libcxx/trunk/test/libcxx/test/config.py (original)
+++ libcxx/trunk/test/libcxx/test/config.py Sun Aug 30 17:04:20 2015
@@ -578,6 +578,10 @@ class Configuration(object):
 self.cxx.addWarningFlagIfSupported('-Wno-pessimizing-move')
 self.cxx.addWarningFlagIfSupported('-Wno-c++11-extensions')
 self.cxx.addWarningFlagIfSupported('-Wno-user-defined-literals')
+# TODO(EricWF) Remove the unused warnings once the test suite
+# compiles clean with them.
+self.cxx.addWarningFlagIfSupported('-Wno-unused-local-typedef')
+self.cxx.addWarningFlagIfSupported('-Wno-unused-variable')
 std = self.get_lit_conf('std', None)
 if std in ['c++98', 'c++03']:
 # The '#define static_assert' provided by libc++ in C++03 mode

Modified: 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/const_T.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/const_T.pass.cpp?rev=246399&r1=246398&r2=246399&view=diff
==
--- 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/const_T.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/const_T.pass.cpp
 Sun Aug 30 17:04:20 2015
@@ -6,6 +6,8 @@
 // Source Licenses. See LICENSE.TXT for details.
 //
 
//===--===//
+//
+// UNSUPPORTED: c++98, c++03, c++11
 
 // 
 
@@ -15,8 +17,6 @@
 #include 
 #include 
 
-#if _LIBCPP_STD_VER > 11
-
 using std::experimental::optional;
 
 class X
@@ -39,18 +39,14 @@ public:
 
 class Z
 {
-int i_;
 public:
-Z(int i) : i_(i) {}
+Z(int)  {}
 Z(const Z&) {throw 6;}
 };
 
 
-#endif  // _LIBCPP_STD_VER > 11
-
 int main()
 {
-#if _LIBCPP_STD_VER > 11
 {
 typedef int T;
 constexpr T t(5);
@@ -113,5 +109,4 @@ int main()
 assert(i == 6);
 }
 }
-#endif  // _LIBCPP_STD_VER > 11
 }

Modified: 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/in_place_t.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/in_place_t.pass.cpp?rev=246399&r1=246398&r2=246399&view=diff
==
--- 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/in_place_t.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/experimental/optional/optional.object/optional.object.ctor/in_place_t.pass.cpp
 Sun Aug 30 17:04:20 2015
@@ -6,6 +6,8 @@
 // Source Licenses. See LICENSE.TXT for details.
 //
 
//===--===//
+//
+// UNSUPPORTED: c++98, c++03, c++11
 
 // 
 
@@ -16,7 +18,6 @@
 #include 
 #include 

Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread don hinton via cfe-commits
gcc has -Wstrict-prototypes which will catch this, but clang doesn't
implement it.

however, both gcc and clang have -Wmissing-prototypes which should catch
these if users enable it.


On Sun, Aug 30, 2015 at 5:32 PM, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Sun, Aug 30, 2015 at 4:53 PM, Piotr Dziwinski 
> wrote:
> > @Aaron: Yes, I'm aware of that. I wanted to show that my check does not
> take
> > this into account.
> >
> > In C++ this code is equivalent, so I think nothing should be reported,
> > unless we really want to get rid of that void, but I suppose this other
> > check does it already.
>
> I think that in C++, it would make sense for this to be reported as a
> consistency issue. For instance, the declaration without void could be
> in a header while the definition is in a source file.
>
> > And when it comes to C, in well-formed C code, we should never see those
> two
> > definitions of allright() and allright(void), as they are declarations of
> > different functions. If I try to add empty bodies {} to define them, this
> > example won't even compile.
>
> Correct, but it also strikes me as weird that your test case is a .c
> file and there are no diagnostics triggered helping the user to
> understand that these are declaring different things. It's not until
> you add the definition that you get a diagnostic. This shouldn't be a
> clang-tidy diagnostic, but a frontend diagnostic. I'm not suggesting
> you have to do that work, either. Merely commenting that 1) they're
> different in C, 2) C++ programmer may be unaware of those differences,
> 3) this can cause real bugs, and 4) we currently fail to help the user
> in a meaningful way.
>
> http://coliru.stacked-crooked.com/a/59ba90b4d3ec5828
>
> ~Aaron
>
> >
> > So anyway, I still don't understand the problem here, unless somebody
> > explains it in clearer terms.
> >
> > Best regards,
> > Piotr Dziwinski
> >
> >
> > On 2015-08-30 22:43, Aaron Ballman wrote:
> >>
> >> On Sun, Aug 30, 2015 at 4:39 PM, Piotr Dziwinski via cfe-commits
> >>  wrote:
> >>>
> >>> piotrdz added a comment.
> >>>
> >>> @Eugene: I don't understand, what does declaring function with "void"
> >>> argument have in common with this review? I only check here variable
> >>> declarations inside functions.
> >>>
> >>> Maybe you meant my other review for inconsistent declaration parameter
> >>> names? If so, this is how it behaves currently:
> >>>
> >>>$ cat test.c
> >>>void allright();
> >>>void allright(void);
> >>>
> >>>void notallright(int a);
> >>>void notallright(int b);
> >>>
> >>>$ clang-tidy
> >>> -checks='-*,readability-inconsistent-declaration-parameter-name'
> test.c --
> >>> -std=c11
> >>>1 warning generated.
> >>>/work/clang-trunk/test.c:4:6: warning: function 'notallright' has
> >>> other declaration with different parameter name(s)
> >>> [readability-inconsistent-declaration-parameter-name]
> >>>void notallright(int a);
> >>> ^
> >>>/work/clang-trunk/test.c:5:6: note: other declaration seen here
> >>>void notallright(int b);
> >>>
> >>> So I see no reason to add specific checks for functions with "void"
> >>> parameter, unless you see something wrong with this behavior?
> >>
> >> In C, void allright(); is a function accepting a variable number of
> >> arguments, and void alright(void); is a function accepting no
> >> arguments. In C++, they are both functions accepting no arguments.
> >>
> >> ~Aaron
> >
> >
> ___
> 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] D12462: [PATCH] [clang-tidy] Add inconsistent declaration parameter name check

2015-08-30 Thread Alexander Kornienko via cfe-commits
alexfh added a comment.

Thanks for contributing the new check!

This check seems pretty similar to the  check implemented in 
clang-tidy/readability/NamedParameterCheck.h/.cpp. Having both doesn't make 
much sense, so one of them will have to die (probably, the other one). Nothing 
should be done to this effect now, we'll figure out after this check is 
polished enough.

See a few other comments inline.



Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:23
@@ +22,3 @@
+
+struct CheckResult {
+  CheckResult(bool HasInconsistentParams,

Maybe use `llvm::Optional`? Or, if you don't need to store 
invalid locations, just use `SourceLocation` and use `SourceLocation()` as a 
magic value?


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:33
@@ +32,3 @@
+
+struct InconsistentParamChecker {
+  static CheckResult checkForInconsitentDeclarationParameters(const 
FunctionDecl* FunctionDeclaration);

Why do you need a struct? It's not Java, free functions are totally fine.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:43
@@ +42,3 @@
+  unless(anyOf(
+isExpansionInSystemHeader(),
+isImplicit(

Clang-tidy takes care of filtering out non-user code, so there's no need to do 
this in the check. There's even a special mode for running clang-tidy on system 
libraries (for library developers), which this condition will interfere with.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:53
@@ +52,3 @@
+
+  auto CheckResult = 
InconsistentParamChecker::checkForInconsitentDeclarationParameters(FunctionDeclaration);
+  if (CheckResult.HasInconsistentParams) {

We use `auto` when the type is obvious from the RHS (e.g. line 49 above) or 
when the specific type is complex and not particularly helpful (e.g. when 
iterating over std::map<>, or for iterators in general). In almost all other 
cases the specific type is preferred.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:54
@@ +53,3 @@
+  auto CheckResult = 
InconsistentParamChecker::checkForInconsitentDeclarationParameters(FunctionDeclaration);
+  if (CheckResult.HasInconsistentParams) {
+auto QualName = FunctionDeclaration->getQualifiedNameAsString();

nit: I'd prefer to use early return here:

if (!CheckResult.HasInconsistentParams)
  return;


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:56
@@ +55,3 @@
+auto QualName = FunctionDeclaration->getQualifiedNameAsString();
+if (ReportedFunctions.count(QualName) > 0)
+  return; // avoid multiple warnings

This could be stored more effectively as a set of pointers to canonical 
declarations (llvm::DenseSet).


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:59
@@ +58,3 @@
+
+diag(FunctionDeclaration->getLocation(), "function '%0' has other 
declaration with different parameter name(s)")
+  << QualName;

The message could be more helpful, if it contained the differing names of the 
parameters.

A significant improvement would be to propose a fix when it's more or less 
clear what the correct name of each parameter should be (e.g. 2 of 3 
declarations have the same parameter names, and the third one has different 
names, or we could consider parameter names used in the definition correct). 
Without a fix, the value of the check will be much lower. In my experience, 
developers are reluctant to fix readability warnings manually.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:81
@@ +80,3 @@
+
+  if (!MyParamName.empty() &&
+!OtherParamName.empty() &&

Code formatting is sub-optimal here. Could you clang-format the code?


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.h:22
@@ +21,3 @@
+
+/// \brief Checks for declarations of functions which differ in parameter names
+///

It seems that the documentation here is different from the one in the .rst 
file. I'd remove the documentation from here (after syncing the recent changes 
to .rst, if needed) and just leave a one-sentence summary and the URL where the 
.rst document is going to be published 
(http://clang.llvm.org/extra/clang-tidy/checks/.html).


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.h:64
@@ +63,3 @@
+private:
+std::set ReportedFunctions;
+};

If you don't need these to be sorted, you can use `llvm::StringSet<>` which 
should be more effective.


Comment at: 
test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp:1
@@ +1,2

Re: [PATCH] D8178: [libcxx] Fix PR22806 - Tuple incorrectly selects copy/move constructor when storing nested tuple-like types.

2015-08-30 Thread Eric Fiselier via cfe-commits
EricWF added a comment.

I think this patch is actually pretty close to correct but thinking about tuple 
hurts my brain.

@mclow.lists can you start reviewing this when you have time.


http://reviews.llvm.org/D8178



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


Re: [PATCH] D12473: [clang-tidy] Add old style function check

2015-08-30 Thread Eugene Zelenko via cfe-commits
Eugene.Zelenko added a comment.

Sorry, I was mislead by check name.


http://reviews.llvm.org/D12473



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


[libcxx] r246408 - Move __lazy_* metafunctions to type traits and add tests

2015-08-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Sun Aug 30 22:50:31 2015
New Revision: 246408

URL: http://llvm.org/viewvc/llvm-project?rev=246408&view=rev
Log:
Move __lazy_* metafunctions to type traits and add tests

Added:
libcxx/trunk/test/libcxx/type_traits/lazy_metafunctions.pass.cpp
Modified:
libcxx/trunk/include/__tuple
libcxx/trunk/include/type_traits
libcxx/trunk/test/libcxx/type_traits/convert_to_integral.pass.cpp

Modified: libcxx/trunk/include/__tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tuple?rev=246408&r1=246407&r2=246408&view=diff
==
--- libcxx/trunk/include/__tuple (original)
+++ libcxx/trunk/include/__tuple Sun Aug 30 22:50:31 2015
@@ -136,31 +136,6 @@ get(array<_Tp, _Size>&&) _NOEXCEPT;
 
 #if !defined(_LIBCPP_HAS_NO_VARIADICS)
 
-// __lazy_and
-
-template 
-struct __lazy_and_impl;
-
-template 
-struct __lazy_and_impl : false_type {};
-
-template <>
-struct __lazy_and_impl : true_type {};
-
-template 
-struct __lazy_and_impl : integral_constant {};
-
-template 
-struct __lazy_and_impl : __lazy_and_impl<_Hp::type::value, 
_Tp...> {};
-
-template 
-struct __lazy_and : __lazy_and_impl<_P1::type::value, _Pr...> {};
-
-// __lazy_not
-
-template 
-struct __lazy_not : integral_constant {};
-
 // __make_tuple_indices
 
 template  struct __tuple_indices {};

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=246408&r1=246407&r2=246408&view=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Sun Aug 30 22:50:31 2015
@@ -277,6 +277,53 @@ using bool_constant = integral_constant<
 typedef _LIBCPP_BOOL_CONSTANT(true)  true_type;
 typedef _LIBCPP_BOOL_CONSTANT(false) false_type;
 
+#if !defined(_LIBCPP_HAS_NO_VARIADICS)
+
+// __lazy_and
+
+template 
+struct __lazy_and_impl;
+
+template 
+struct __lazy_and_impl : false_type {};
+
+template <>
+struct __lazy_and_impl : true_type {};
+
+template 
+struct __lazy_and_impl : integral_constant {};
+
+template 
+struct __lazy_and_impl : __lazy_and_impl<_Hp::type::value, 
_Tp...> {};
+
+template 
+struct __lazy_and : __lazy_and_impl<_P1::type::value, _Pr...> {};
+
+// __lazy_or
+
+template 
+struct __lazy_or_impl;
+
+template 
+struct __lazy_or_impl : true_type {};
+
+template <>
+struct __lazy_or_impl : false_type {};
+
+template 
+struct __lazy_or_impl
+: __lazy_or_impl<_Hp::type::value, _Tp...> {};
+
+template 
+struct __lazy_or : __lazy_or_impl<_P1::type::value, _Pr...> {};
+
+// __lazy_not
+
+template 
+struct __lazy_not : integral_constant {};
+
+#endif // !defined(_LIBCPP_HAS_NO_VARIADICS)
+
 // is_const
 
 template  struct _LIBCPP_TYPE_VIS_ONLY is_const: public 
false_type {};

Modified: libcxx/trunk/test/libcxx/type_traits/convert_to_integral.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/type_traits/convert_to_integral.pass.cpp?rev=246408&r1=246407&r2=246408&view=diff
==
--- libcxx/trunk/test/libcxx/type_traits/convert_to_integral.pass.cpp (original)
+++ libcxx/trunk/test/libcxx/type_traits/convert_to_integral.pass.cpp Sun Aug 
30 22:50:31 2015
@@ -1,7 +1,22 @@
-
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+//
 // TODO: Make this test pass for all standards.
 // XFAIL: c++98, c++03
 
+// 
+
+// __convert_to_integral(Tp)
+
+// Test that the __convert_to_integral functions properly converts Tp to the
+// correct type and value for integral, enum and user defined types.
+
 #include 
 #include 
 #include 

Added: libcxx/trunk/test/libcxx/type_traits/lazy_metafunctions.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/type_traits/lazy_metafunctions.pass.cpp?rev=246408&view=auto
==
--- libcxx/trunk/test/libcxx/type_traits/lazy_metafunctions.pass.cpp (added)
+++ libcxx/trunk/test/libcxx/type_traits/lazy_metafunctions.pass.cpp Sun Aug 30 
22:50:31 2015
@@ -0,0 +1,137 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// UNSUPPORTED: c++98, c++03
+
+// 
+
+// __lazy_enable_if, __lazy_not, __lazy_and and __lazy_or
+
+// Test the libc+