r278650 - cxx_status: update features implemented in clang 3.9 from "svn" to "Clang 3.9" now that svn trunk is 4.0.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Sun Aug 14 21:47:23 2016
New Revision: 278650

URL: http://llvm.org/viewvc/llvm-project?rev=278650=rev
Log:
cxx_status: update features implemented in clang 3.9 from "svn" to "Clang 3.9" 
now that svn trunk is 4.0.

Modified:
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/www/cxx_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?rev=278650=278649=278650=diff
==
--- cfe/trunk/www/cxx_status.html (original)
+++ cfe/trunk/www/cxx_status.html Sun Aug 14 21:47:23 2016
@@ -578,7 +578,7 @@ as the draft C++1z standard evolves.
 

 http://wg21.link/p0036r0;>P0036R0
-SVN
+Clang 3.9
   
 
   u8 character literals
@@ -624,28 +624,28 @@ as the draft C++1z standard evolves.
 
   New specification for inheriting constructors (DR1941 et al)
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html;>P0136R1
-  SVN (9)
+  Clang 3.9 (9)
 
 
 
   [[fallthrough]] attribute
   http://wg21.link/p0188r1;>P0188R1
-  SVN
+  Clang 3.9
 
 
   [[nodiscard]] attribute
   http://wg21.link/p0189r1;>P0189R1
-  SVN
+  Clang 3.9
 
 
   [[maybe_unused]] attribute
   http://wg21.link/p0212r1;>P0212R1
-  SVN
+  Clang 3.9
 
 
   Aggregate initialization of classes with base classes
   http://wg21.link/p0017r1;>P0017R1
-  SVN
+  Clang 3.9
 
 
   constexpr lambda expressions
@@ -655,17 +655,17 @@ as the draft C++1z standard evolves.
 
   Differing begin and end types in range-based 
for
   http://wg21.link/p0184r0;>P0184R0
-  SVN
+  Clang 3.9
 
 
   Lambda capture of *this
   http://wg21.link/p0018r3;>P0018R3
-  SVN
+  Clang 3.9
 
 
   Direct-list-initialization of enums
   http://wg21.link/p0138r2;>P0138R2
-  SVN
+  Clang 3.9
 
 
   Hexadecimal floating-point literals
@@ -676,7 +676,7 @@ as the draft C++1z standard evolves.
 
   Using attribute namespaces without repetition
   http://wg21.link/p0028r4;>P0028R4
-  SVN
+  Clang 3.9
 
 
   Dynamic memory allocation for over-aligned data
@@ -714,12 +714,12 @@ as the draft C++1z standard evolves.
 
   constexpr if-statements
   http://wg21.link/p0292r2;>P0292R2
-  SVN
+  Clang 3.9
 
 
   Inline variables
   http://wg21.link/p0386r2;>P0386R2
-  SVN
+  Clang 3.9
 
 
   Structured bindings
@@ -729,7 +729,7 @@ as the draft C++1z standard evolves.
 
   Separate variable and condition for if and 
switch
   http://wg21.link/p0305r1;>P0305R1
-  SVN
+  Clang 3.9
 
 
 


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

r278649 - cxx_status: mark decomposition declarations as "partial": the implementation is

[Richard Smith via cfe-commits]

Author: rsmith
Date: Sun Aug 14 21:37:43 2016
New Revision: 278649

URL: http://llvm.org/viewvc/llvm-project?rev=278649=rev
Log:
cxx_status: mark decomposition declarations as "partial": the implementation is
essentially complete, other than parts where design questions have been raised
(lambda capture, decomposition of arrays by copy).

Modified:
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/www/cxx_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?rev=278649=278648=278649=diff
==
--- cfe/trunk/www/cxx_status.html (original)
+++ cfe/trunk/www/cxx_status.html Sun Aug 14 21:37:43 2016
@@ -724,7 +724,7 @@ as the draft C++1z standard evolves.
 
   Structured bindings
   http://wg21.link/p0217r3;>P0217R3
-  No
+  Partial
 
 
   Separate variable and condition for if and 
switch


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

r278648 - Disable lambda-capture of decomposition declaration bindings for now, until CWG

[Richard Smith via cfe-commits]

Author: rsmith
Date: Sun Aug 14 21:34:23 2016
New Revision: 278648

URL: http://llvm.org/viewvc/llvm-project?rev=278648=rev
Log:
Disable lambda-capture of decomposition declaration bindings for now, until CWG
agrees on how they're supposed to work.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/SemaCXX/cxx1z-decomposition.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=278648=278647=278648=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Sun Aug 14 21:34:23 
2016
@@ -7046,14 +7046,9 @@ def ext_ms_anonymous_record : ExtWarn<
   InGroup;
 
 // C++ local classes
-def err_reference_to_local_var_in_enclosing_function : Error<
-  "reference to local variable %0 declared in enclosing function %1">;
-def err_reference_to_local_var_in_enclosing_block : Error<
-  "reference to local variable %0 declared in enclosing block literal">;
-def err_reference_to_local_var_in_enclosing_lambda : Error<
-  "reference to local variable %0 declared in enclosing lambda expression">;
-def err_reference_to_local_var_in_enclosing_context : Error<
-  "reference to local variable %0 declared in enclosing context">;
+def err_reference_to_local_in_enclosing_context : Error<
+  "reference to local %select{variable|binding}1 %0 declared in enclosing "
+  "%select{%3|block literal|lambda expression|context}2">;
 
 def err_static_data_member_not_allowed_in_local_class : Error<
   "static data member %0 not allowed in local class %1">; 

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=278648=278647=278648=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Sun Aug 14 21:34:23 2016
@@ -2838,6 +2838,10 @@ ExprResult Sema::BuildDeclarationNameExp
   return ULE;
 }
 
+static void
+diagnoseUncapturableValueReference(Sema , SourceLocation loc,
+   ValueDecl *var, DeclContext *DC);
+
 /// \brief Complete semantic analysis for a reference to the given declaration.
 ExprResult Sema::BuildDeclarationNameExpr(
 const CXXScopeSpec , const DeclarationNameInfo , NamedDecl *D,
@@ -2981,7 +2985,12 @@ ExprResult Sema::BuildDeclarationNameExp
   // These are always lvalues.
   valueKind = VK_LValue;
   type = type.getNonReferenceType();
-  // FIXME: Adjust cv-qualifiers for capture.
+  // FIXME: Support lambda-capture of BindingDecls, once CWG actually
+  // decides how that's supposed to work.
+  auto *BD = cast(VD);
+  if (BD->getDeclContext()->isFunctionOrMethod() &&
+  BD->getDeclContext() != CurContext)
+diagnoseUncapturableValueReference(*this, Loc, BD, CurContext);
   break;
 }
 
@@ -13214,7 +13223,7 @@ void Sema::MarkFunctionReferenced(Source
 
 static void
 diagnoseUncapturableValueReference(Sema , SourceLocation loc,
-   VarDecl *var, DeclContext *DC) {
+   ValueDecl *var, DeclContext *DC) {
   DeclContext *VarDC = var->getDeclContext();
 
   //  If the parameter still belongs to the translation unit, then
@@ -13234,25 +13243,21 @@ diagnoseUncapturableValueReference(Sema
   if (!S.getLangOpts().CPlusPlus && !S.CurContext->isFunctionOrMethod())
 return;
 
+  unsigned ValueKind = isa(var) ? 1 : 0;
+  unsigned ContextKind = 3; // unknown
   if (isa(VarDC) &&
   cast(VarDC->getParent())->isLambda()) {
-S.Diag(loc, diag::err_reference_to_local_var_in_enclosing_lambda)
-  << var->getIdentifier();
-  } else if (FunctionDecl *fn = dyn_cast(VarDC)) {
-S.Diag(loc, diag::err_reference_to_local_var_in_enclosing_function)
-  << var->getIdentifier() << fn->getDeclName();
+ContextKind = 2;
+  } else if (isa(VarDC)) {
+ContextKind = 0;
   } else if (isa(VarDC)) {
-S.Diag(loc, diag::err_reference_to_local_var_in_enclosing_block)
-  << var->getIdentifier();
-  } else {
-// FIXME: Is there any other context where a local variable can be
-// declared?
-S.Diag(loc, diag::err_reference_to_local_var_in_enclosing_context)
-  << var->getIdentifier();
+ContextKind = 1;
   }
 
+  S.Diag(loc, diag::err_reference_to_local_in_enclosing_context)
+<< var << ValueKind << ContextKind << VarDC;
   S.Diag(var->getLocation(), diag::note_entity_declared_at)
-  << var->getIdentifier();
+  << var;
 
   // FIXME: Add additional diagnostic info about class etc. which prevents
   // capture.

Modified: cfe/trunk/test/SemaCXX/cxx1z-decomposition.cpp
URL: 

r278647 - Add a triple to this test to make buildbots happier.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Sun Aug 14 21:24:00 2016
New Revision: 278647

URL: http://llvm.org/viewvc/llvm-project?rev=278647=rev
Log:
Add a triple to this test to make buildbots happier.

Modified:
cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp

Modified: cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp?rev=278647=278646=278647=diff
==
--- cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp Sun Aug 14 21:24:00 2016
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++1z -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++1z -triple x86_64-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
 
 namespace std {
   using size_t = decltype(sizeof(0));


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

[libcxx] r278643 - Check in SFINAE base class for use in optional/variant

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Sun Aug 14 20:51:54 2016
New Revision: 278643

URL: http://llvm.org/viewvc/llvm-project?rev=278643=rev
Log:
Check in SFINAE base class for use in optional/variant

Modified:
libcxx/trunk/include/__tuple

Modified: libcxx/trunk/include/__tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tuple?rev=278643=278642=278643=diff
==
--- libcxx/trunk/include/__tuple (original)
+++ libcxx/trunk/include/__tuple Sun Aug 14 20:51:54 2016
@@ -479,6 +479,63 @@ struct _LIBCPP_TYPE_VIS __check_tuple_co
 };
 #endif
 
+#if _LIBCPP_STD_VER > 14
+
+template 
+struct __sfinae_ctor_base {};
+template <>
+struct __sfinae_ctor_base {
+  __sfinae_ctor_base() = default;
+  __sfinae_ctor_base(__sfinae_ctor_base const&) = delete;
+  __sfinae_ctor_base(__sfinae_ctor_base &&) = delete;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base const&) = default;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base&&) = default;
+};
+template <>
+struct __sfinae_ctor_base {
+  __sfinae_ctor_base() = default;
+  __sfinae_ctor_base(__sfinae_ctor_base const&) = default;
+  __sfinae_ctor_base(__sfinae_ctor_base &&) = delete;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base const&) = default;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base&&) = default;
+};
+template <>
+struct __sfinae_ctor_base {
+  __sfinae_ctor_base() = default;
+  __sfinae_ctor_base(__sfinae_ctor_base const&) = delete;
+  __sfinae_ctor_base(__sfinae_ctor_base &&) = default;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base const&) = default;
+  __sfinae_ctor_base& operator=(__sfinae_ctor_base&&) = default;
+};
+
+template 
+struct __sfinae_assign_base {};
+template <>
+struct __sfinae_assign_base {
+  __sfinae_assign_base() = default;
+  __sfinae_assign_base(__sfinae_assign_base const&) = default;
+  __sfinae_assign_base(__sfinae_assign_base &&) = default;
+  __sfinae_assign_base& operator=(__sfinae_assign_base const&) = delete;
+  __sfinae_assign_base& operator=(__sfinae_assign_base&&) = delete;
+};
+template <>
+struct __sfinae_assign_base {
+  __sfinae_assign_base() = default;
+  __sfinae_assign_base(__sfinae_assign_base const&) = default;
+  __sfinae_assign_base(__sfinae_assign_base &&) = default;
+  __sfinae_assign_base& operator=(__sfinae_assign_base const&) = default;
+  __sfinae_assign_base& operator=(__sfinae_assign_base&&) = delete;
+};
+template <>
+struct __sfinae_assign_base {
+  __sfinae_assign_base() = default;
+  __sfinae_assign_base(__sfinae_assign_base const&) = default;
+  __sfinae_assign_base(__sfinae_assign_base &&) = default;
+  __sfinae_assign_base& operator=(__sfinae_assign_base const&) = delete;
+  __sfinae_assign_base& operator=(__sfinae_assign_base&&) = default;
+};
+#endif // _LIBCPP_STD_VER > 14
+
 _LIBCPP_END_NAMESPACE_STD
 
 #endif  // _LIBCPP___TUPLE


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

r278642 - P0217R3: code generation support for decomposition declarations.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Sun Aug 14 20:33:41 2016
New Revision: 278642

URL: http://llvm.org/viewvc/llvm-project?rev=278642=rev
Log:
P0217R3: code generation support for decomposition declarations.

Added:
cfe/trunk/test/CodeGenCXX/cxx1z-decomposition.cpp
Modified:
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/SemaCXX/cxx1z-decomposition.cpp

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=278642=278641=278642=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Sun Aug 14 20:33:41 2016
@@ -8721,6 +8721,14 @@ bool ASTContext::DeclMustBeEmitted(const
   !VD->evaluateValue())
 return true;
 
+  // Likewise, variables with tuple-like bindings are required if their
+  // bindings have side-effects.
+  if (auto *DD = dyn_cast(VD))
+for (auto *BD : DD->bindings())
+  if (auto *BindingVD = BD->getHoldingVar())
+if (DeclMustBeEmitted(BindingVD))
+  return true;
+
   return false;
 }
 

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=278642=278641=278642=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Sun Aug 14 20:33:41 2016
@@ -1195,18 +1195,21 @@ void CXXNameMangler::mangleUnqualifiedNa
   case DeclarationName::Identifier: {
 const IdentifierInfo *II = Name.getAsIdentifierInfo();
 
-// We mangle decomposition declarations as the name of their first binding.
+// We mangle decomposition declarations as the names of their bindings.
 if (auto *DD = dyn_cast(ND)) {
-  auto B = DD->bindings();
-  if (B.begin() == B.end()) {
-// FIXME: This is ill-formed but we accept it as an extension.
-DiagnosticsEngine  = Context.getDiags();
-unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
-"cannot mangle global empty decomposition decl");
-Diags.Report(DD->getLocation(), DiagID);
-break;
-  }
-  II = (*B.begin())->getIdentifier();
+  // FIXME: Non-standard mangling for decomposition declarations:
+  //
+  //   ::= DC * E
+  //
+  // These can never be referenced across translation units, so we do
+  // not need a cross-vendor mangling for anything other than demanglers.
+  // Proposed on cxx-abi-dev on 2016-08-12
+  Out << "DC";
+  for (auto *BD : DD->bindings())
+mangleSourceName(BD->getDeclName().getAsIdentifierInfo());
+  Out << 'E';
+  writeAbiTags(ND, AdditionalAbiTags);
+  break;
 }
 
 if (II) {

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=278642=278641=278642=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Sun Aug 14 20:33:41 2016
@@ -394,7 +394,8 @@ bool MicrosoftMangleContextImpl::shouldM
   if (!getASTContext().getLangOpts().CPlusPlus)
 return false;
 
-  if (const VarDecl *VD = dyn_cast(D)) {
+  const VarDecl *VD = dyn_cast(D);
+  if (VD && !isa(D)) {
 // C variables are not mangled.
 if (VD->isExternC())
   return false;
@@ -780,6 +781,21 @@ void MicrosoftCXXNameMangler::mangleUnqu
 }
   }
 
+  if (const DecompositionDecl *DD = dyn_cast(ND)) {
+// FIXME: Invented mangling for decomposition declarations:
+//   [X,Y,Z]
+// where X,Y,Z are the names of the bindings.
+llvm::SmallString<128> Name("[");
+for (auto *BD : DD->bindings()) {
+  if (Name.size() > 1)
+Name += ',';
+  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
+}
+Name += ']';
+mangleSourceName(Name);
+break;
+  }
+
   if (const VarDecl *VD = dyn_cast(ND)) {
 // We must have an anonymous union or struct declaration.
 const CXXRecordDecl *RD = VD->getType()->getAsCXXRecordDecl();

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=278642=278641=278642=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Sun Aug 14 20:33:41 2016
@@ -87,6 +87,7 @@ void CodeGenFunction::EmitDecl(const Dec
   case Decl::UsingShadow:
   case Decl::ConstructorUsingShadow:
   case 

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

[Hal Finkel via cfe-commits]

hfinkel updated this revision to Diff 67992.
hfinkel added a comment.

Updated to use scheme suggested by Marshall.


https://reviews.llvm.org/D18639

Files:
  include/cmath
  include/complex

Index: include/complex
===
--- include/complex
+++ include/complex
@@ -602,39 +602,39 @@
 _Tp __bc = __b * __c;
 _Tp __x = __ac - __bd;
 _Tp __y = __ad + __bc;
-if (isnan(__x) && isnan(__y))
+if (__libcpp_isnan(__x) && __libcpp_isnan(__y))
 {
 bool __recalc = false;
-if (isinf(__a) || isinf(__b))
+if (__libcpp_isinf(__a) || __libcpp_isinf(__b))
 {
-__a = copysign(isinf(__a) ? _Tp(1) : _Tp(0), __a);
-__b = copysign(isinf(__b) ? _Tp(1) : _Tp(0), __b);
-if (isnan(__c))
+__a = copysign(__libcpp_isinf(__a) ? _Tp(1) : _Tp(0), __a);
+__b = copysign(__libcpp_isinf(__b) ? _Tp(1) : _Tp(0), __b);
+if (__libcpp_isnan(__c))
 __c = copysign(_Tp(0), __c);
-if (isnan(__d))
+if (__libcpp_isnan(__d))
 __d = copysign(_Tp(0), __d);
 __recalc = true;
 }
-if (isinf(__c) || isinf(__d))
+if (__libcpp_isinf(__c) || __libcpp_isinf(__d))
 {
-__c = copysign(isinf(__c) ? _Tp(1) : _Tp(0), __c);
-__d = copysign(isinf(__d) ? _Tp(1) : _Tp(0), __d);
-if (isnan(__a))
+__c = copysign(__libcpp_isinf(__c) ? _Tp(1) : _Tp(0), __c);
+__d = copysign(__libcpp_isinf(__d) ? _Tp(1) : _Tp(0), __d);
+if (__libcpp_isnan(__a))
 __a = copysign(_Tp(0), __a);
-if (isnan(__b))
+if (__libcpp_isnan(__b))
 __b = copysign(_Tp(0), __b);
 __recalc = true;
 }
-if (!__recalc && (isinf(__ac) || isinf(__bd) ||
-  isinf(__ad) || isinf(__bc)))
+if (!__recalc && (__libcpp_isinf(__ac) || __libcpp_isinf(__bd) ||
+  __libcpp_isinf(__ad) || __libcpp_isinf(__bc)))
 {
-if (isnan(__a))
+if (__libcpp_isnan(__a))
 __a = copysign(_Tp(0), __a);
-if (isnan(__b))
+if (__libcpp_isnan(__b))
 __b = copysign(_Tp(0), __b);
-if (isnan(__c))
+if (__libcpp_isnan(__c))
 __c = copysign(_Tp(0), __c);
-if (isnan(__d))
+if (__libcpp_isnan(__d))
 __d = copysign(_Tp(0), __d);
 __recalc = true;
 }
@@ -677,33 +677,33 @@
 _Tp __c = __w.real();
 _Tp __d = __w.imag();
 _Tp __logbw = logb(fmax(fabs(__c), fabs(__d)));
-if (isfinite(__logbw))
+if (__libcpp_isfinite(__logbw))
 {
 __ilogbw = static_cast(__logbw);
 __c = scalbn(__c, -__ilogbw);
 __d = scalbn(__d, -__ilogbw);
 }
 _Tp __denom = __c * __c + __d * __d;
 _Tp __x = scalbn((__a * __c + __b * __d) / __denom, -__ilogbw);
 _Tp __y = scalbn((__b * __c - __a * __d) / __denom, -__ilogbw);
-if (isnan(__x) && isnan(__y))
+if (__libcpp_isnan(__x) && __libcpp_isnan(__y))
 {
-if ((__denom == _Tp(0)) && (!isnan(__a) || !isnan(__b)))
+if ((__denom == _Tp(0)) && (!__libcpp_isnan(__a) || !__libcpp_isnan(__b)))
 {
 __x = copysign(_Tp(INFINITY), __c) * __a;
 __y = copysign(_Tp(INFINITY), __c) * __b;
 }
-else if ((isinf(__a) || isinf(__b)) && isfinite(__c) && isfinite(__d))
+else if ((__libcpp_isinf(__a) || __libcpp_isinf(__b)) && __libcpp_isfinite(__c) && __libcpp_isfinite(__d))
 {
-__a = copysign(isinf(__a) ? _Tp(1) : _Tp(0), __a);
-__b = copysign(isinf(__b) ? _Tp(1) : _Tp(0), __b);
+__a = copysign(__libcpp_isinf(__a) ? _Tp(1) : _Tp(0), __a);
+__b = copysign(__libcpp_isinf(__b) ? _Tp(1) : _Tp(0), __b);
 __x = _Tp(INFINITY) * (__a * __c + __b * __d);
 __y = _Tp(INFINITY) * (__b * __c - __a * __d);
 }
-else if (isinf(__logbw) && __logbw > _Tp(0) && isfinite(__a) && isfinite(__b))
+else if (__libcpp_isinf(__logbw) && __logbw > _Tp(0) && __libcpp_isfinite(__a) && __libcpp_isfinite(__b))
 {
-__c = copysign(isinf(__c) ? _Tp(1) : _Tp(0), __c);
-__d = copysign(isinf(__d) ? _Tp(1) : _Tp(0), __d);
+__c = copysign(__libcpp_isinf(__c) ? _Tp(1) : _Tp(0), __c);
+__d = copysign(__libcpp_isinf(__d) ? _Tp(1) : _Tp(0), __d);
 __x = _Tp(0) * (__a * __c + __b * __d);
 __y = _Tp(0) * (__b * __c - __a * __d);
 }
@@ -913,9 +913,9 @@
 _Tp
 norm(const complex<_Tp>& __c)
 {
-if (isinf(__c.real()))
+if (__libcpp_isinf(__c.real()))
 return abs(__c.real());
-if (isinf(__c.imag()))
+if (__libcpp_isinf(__c.imag()))
 return abs(__c.imag());
 return __c.real() 

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D18639#491232, @mclow.lists wrote:

> And is there any reason why `__libcpp_isinf` can't just return `false` for 
> non-fp types?


For custom numeric types that have an isinf, etc. found by ADL, they should 
continue to work.


https://reviews.llvm.org/D18639



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

[libcxx] r278638 - Add private option to change build dialect from C++11

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Sun Aug 14 17:51:54 2016
New Revision: 278638

URL: http://llvm.org/viewvc/llvm-project?rev=278638=rev
Log:
Add private option to change build dialect from C++11

Although libc++ only requires C++11 to build, there are other
reasons to turn on a newer dialect in the build. For example
IDE's may not highlight any C++14/C++17 in the headers when
configured for C++11. This patch add's a private option for
changing this.




Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=278638=278637=278638=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Sun Aug 14 17:51:54 2016
@@ -301,9 +301,11 @@ remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
 remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
 # Required flags ==
-add_compile_flags_if_supported(-std=c++11)
-if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
-  message(FATAL_ERROR "C++11 is required but the compiler does not support 
-std=c++11")
+set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build 
dialect")
+add_compile_flags_if_supported(-std=${LIBCXX_STANDARD_VER})
+mangle_name("LIBCXX_SUPPORTS_STD_EQ_${LIBCXX_STANDARD_VER}_FLAG" 
SUPPORTS_DIALECT_NAME)
+if (NOT MSVC AND NOT ${SUPPORTS_DIALECT_NAME})
+  message(FATAL_ERROR "C++11 or greater is required but the compiler does not 
support ${LIBCXX_STANDARD_VER}")
 endif()
 
 # On all systems the system c++ standard library headers need to be excluded.


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

[PATCH] D23493: Fix PR28366: Teach the const-expression evaluator to be more fault tolerant with non-const enclosing local variables, or otherwise fold them if const.

[Faisal Vali via cfe-commits]

faisalv created this revision.
faisalv added reviewers: rsmith, hans.
faisalv added a subscriber: cfe-commits.
faisalv set the repository for this revision to rL LLVM.

Fix the following Bug:
https://llvm.org/bugs/show_bug.cgi?id=28366

This patch teaches the constant expression evaluator to search the frame stack 
for a local variable (instead of assuming a local variable is on the current 
frame).  

This has the following benefits:
  - if the local variable from an enclosing scope was an error during 
parsing/instantiation - it remains an error (instead of a compiler crash) 
during constant expression evaluation
  - a local variable that is a constant expression from an enclosing scope is 
now evaluatable

Additionally, fix SemaTemplateInstantiateDecl so that when it instantiates the 
enable_if attribute it uses the instantiated declaration (instead of the 
template) when evaluating the condition (so that the instantiated param's decl 
context is correctly found).  This was done to fix the following regression:

template  T templatedBar(T m) __attribute__((enable_if(m > 0, ""))) 
{ return T(); }


  
 

Repository:
  rL LLVM

https://reviews.llvm.org/D23493

Files:
  lib/AST/ExprConstant.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/SemaCXX/constant-expression-cxx11.cpp

Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2066,3 +2066,33 @@
   constexpr Z z(1);
   static_assert(z.w == 1 && z.x == 2 && z.y == 3 && z.z == 4, "");
 }
+
+
+namespace PR28366 {
+namespace ns1 {
+
+void f(char c) { //expected-note2{{declared here}}
+  struct X {
+static constexpr char f() { //expected-error{{never produces a constant 
expression}}
+  return c; //expected-error{{reference to local}} 
expected-note{{non-const variable}}
+}
+  };
+  int I = X::f();
+}
+
+void g() {
+  const int c = 'c';
+  static const int d = 'd';
+  struct X {
+static constexpr int f() {
+  return c + d;
+}
+  };
+  constexpr int CD = X::f();
+}
+
+
+} // end ns1
+
+} //end ns PR28366
+
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -187,7 +187,7 @@
 
   SmallVector Diags;
   if (A->getCond()->isValueDependent() && !Cond->isValueDependent() &&
-  !Expr::isPotentialConstantExprUnevaluated(Cond, cast(Tmpl),
+  !Expr::isPotentialConstantExprUnevaluated(Cond, cast(New),
 Diags)) {
 S.Diag(A->getLocation(), diag::err_enable_if_never_constant_expr);
 for (int I = 0, N = Diags.size(); I != N; ++I)
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -4788,10 +4788,24 @@
   return Error(E);
 }
 
+CallStackFrame *getNearestContainingCallFrame(CallStackFrame *CurFrame,
+  const VarDecl *VD) {
+  if (auto *FD =
+dyn_cast(VD->getDeclContext()->getRedeclContext())) {
+FD = FD->getFirstDecl();
+for (CallStackFrame *It = CurFrame; It; It = It->Caller) {
+  if (It->Callee && FD == It->Callee->getFirstDecl())
+return It;
+}
+  }
+  return nullptr;
+}
+
 bool LValueExprEvaluator::VisitVarDecl(const Expr *E, const VarDecl *VD) {
   CallStackFrame *Frame = nullptr;
-  if (VD->hasLocalStorage() && Info.CurrentCall->Index > 1)
-Frame = Info.CurrentCall;
+  if (VD->hasLocalStorage() && Info.CurrentCall->Index > 1) {
+Frame = getNearestContainingCallFrame(Info.CurrentCall, VD);
+  }
 
   if (!VD->getType()->isReferenceType()) {
 if (Frame) {


Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2066,3 +2066,33 @@
   constexpr Z z(1);
   static_assert(z.w == 1 && z.x == 2 && z.y == 3 && z.z == 4, "");
 }
+
+
+namespace PR28366 {
+namespace ns1 {
+
+void f(char c) { //expected-note2{{declared here}}
+  struct X {
+static constexpr char f() { //expected-error{{never produces a constant expression}}
+  return c; //expected-error{{reference to local}} expected-note{{non-const variable}}
+}
+  };
+  int I = X::f();
+}
+
+void g() {
+  const int c = 'c';
+  static const int d = 'd';
+  struct X {
+static constexpr int f() {
+  return c + d;
+}
+  };
+  constexpr int CD = X::f();
+}
+
+
+} // end ns1
+
+} //end ns PR28366
+
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -187,7 +187,7 @@
 
   

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:22-23
@@ +21,4 @@
+  Finder->addMatcher(
+  declRefExpr(hasDeclaration(functionDecl(namedDecl(hasName("::rand")),
+  parameterCountIs(0
+  .bind("randomGenerator"),

Prazek wrote:
> aaron.ballman wrote:
> > Prazek wrote:
> > > aaron.ballman wrote:
> > > > This should be looking at a callExpr() rather than a declRefExpr(), 
> > > > should it not?
> > > I was also thinking about this, but this is actually better, because it 
> > > will also match with binding rand with function pointer.
> > True, but a DeclRefExpr doesn't mean it's a function call. Binding the 
> > function is not contrary to the CERT rule, just calling it. For instance, 
> > the following pathological case will be caught by this check:
> > ```
> > if (std::rand) {}
> > ```
> > The behavior of this check should be consistent with cert-env33-c, which 
> > only looks at calls. (If we really care about bound functions, we'd need 
> > flow control analysis, and I think that's overkill for both of those 
> > checks, but wouldn't be opposed to someone writing the flow analysis if 
> > they really wanted to.)
> It would indeed fire on this pathological case, but I don't think we should 
> care about cases like this, because no one is writing code like this (and if 
> he would then it would probably be a bug).
> I don't think that there is much code that binds pointer to std::rand either, 
> but I think it would be good to display warning for this, because even if the 
> function would be never called, then it means that this is a bug, and if it 
> would be called then it would be nice to tell user that rand might be used 
> here.
> 
> Anyway I don't oppose for changing it to callExpr, but I think it is better 
> this way.
> It would indeed fire on this pathological case, but I don't think we should 
> care about cases like this, because no one is writing code like this (and if 
> he would then it would probably be a bug).

It would be a known false-positive for a check designed to conform to a 
particular coding standard. When deviations have come up in the past for 
various coding standards, we've added an option to enable the additional 
functionality, which I don't think would be reasonable in this case. 
Alternatively, the CERT guideline could be modified, but that is unlikely to 
occur because binding the function pointer is not a security concern (only 
calling the function).


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Benedek Kiss via cfe-commits]

falho added a comment.

Hi! Thanks for the reviews! I will be off for a few days so I will start 
working on it when Im back. Greetz! Benedek


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D23397: [clang-rename] cleanup `auto` usages

[Kirill Bobyrev via cfe-commits]

omtcyfz updated this revision to Diff 67989.
omtcyfz marked 3 inline comments as done.
omtcyfz added a comment.

Address comments.


https://reviews.llvm.org/D23397

Files:
  clang-rename/RenamingAction.cpp
  clang-rename/USRFinder.cpp
  clang-rename/USRFindingAction.cpp
  clang-rename/USRLocFinder.cpp

Index: clang-rename/USRLocFinder.cpp
===
--- clang-rename/USRLocFinder.cpp
+++ clang-rename/USRLocFinder.cpp
@@ -67,7 +67,7 @@
   // Expression visitors:
 
   bool VisitDeclRefExpr(const DeclRefExpr *Expr) {
-const auto *Decl = Expr->getFoundDecl();
+const NamedDecl *Decl = Expr->getFoundDecl();
 
 if (USRSet.find(getUSRForDecl(Decl)) != USRSet.end()) {
   const SourceManager  = Decl->getASTContext().getSourceManager();
@@ -79,7 +79,7 @@
   }
 
   bool VisitMemberExpr(const MemberExpr *Expr) {
-const auto *Decl = Expr->getFoundDecl().getDecl();
+const NamedDecl *Decl = Expr->getFoundDecl().getDecl();
 if (USRSet.find(getUSRForDecl(Decl)) != USRSet.end()) {
   const SourceManager  = Decl->getASTContext().getSourceManager();
   SourceLocation Location = Manager.getSpellingLoc(Expr->getMemberLoc());
@@ -116,7 +116,8 @@
   // Namespace traversal:
   void handleNestedNameSpecifierLoc(NestedNameSpecifierLoc NameLoc) {
 while (NameLoc) {
-  const auto *Decl = NameLoc.getNestedNameSpecifier()->getAsNamespace();
+  const NamespaceDecl *Decl =
+  NameLoc.getNestedNameSpecifier()->getAsNamespace();
   if (Decl && USRSet.find(getUSRForDecl(Decl)) != USRSet.end()) {
 checkAndAddLocation(NameLoc.getLocalBeginLoc());
   }
@@ -126,9 +127,10 @@
 
 private:
   void checkAndAddLocation(SourceLocation Loc) {
-const auto BeginLoc = Loc;
-const auto EndLoc = Lexer::getLocForEndOfToken(
-BeginLoc, 0, Context.getSourceManager(), Context.getLangOpts());
+const SourceLocation BeginLoc = Loc;
+const SourceLocation EndLoc = Lexer::getLocForEndOfToken(
+ BeginLoc, 0, Context.getSourceManager(),
+ Context.getLangOpts());
 StringRef TokenName =
 Lexer::getSourceText(CharSourceRange::getTokenRange(BeginLoc, EndLoc),
  Context.getSourceManager(), Context.getLangOpts());
Index: clang-rename/USRFindingAction.cpp
===
--- clang-rename/USRFindingAction.cpp
+++ clang-rename/USRFindingAction.cpp
@@ -116,14 +116,14 @@
 
   void addUSRsOfOverridenFunctions(const CXXMethodDecl *MethodDecl) {
 USRSet.insert(getUSRForDecl(MethodDecl));
-for (auto  : MethodDecl->overridden_methods()) {
+for (const auto  : MethodDecl->overridden_methods()) {
   // Recursively visit each OverridenMethod.
   addUSRsOfOverridenFunctions(OverriddenMethod);
 }
   }
 
   bool checkIfOverriddenFunctionAscends(const CXXMethodDecl *MethodDecl) {
-for (auto  : MethodDecl->overridden_methods()) {
+for (const auto  : MethodDecl->overridden_methods()) {
   if (USRSet.find(getUSRForDecl(OverriddenMethod)) != USRSet.end()) {
 return true;
   }
@@ -143,10 +143,11 @@
 
 struct NamedDeclFindingConsumer : public ASTConsumer {
   void HandleTranslationUnit(ASTContext ) override {
-const auto  = Context.getSourceManager();
+const SourceManager  = Context.getSourceManager();
 // The file we look for the USR in will always be the main source file.
-const auto Point = SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID())
-   .getLocWithOffset(SymbolOffset);
+const SourceLocation Point =
+SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID())
+.getLocWithOffset(SymbolOffset);
 if (!Point.isValid())
   return;
 const NamedDecl *FoundDecl = nullptr;
Index: clang-rename/USRFinder.cpp
===
--- clang-rename/USRFinder.cpp
+++ clang-rename/USRFinder.cpp
@@ -60,23 +60,24 @@
   // Expression visitors:
 
   bool VisitDeclRefExpr(const DeclRefExpr *Expr) {
-const auto *Decl = Expr->getFoundDecl();
+const NamedDecl *Decl = Expr->getFoundDecl();
 return setResult(Decl, Expr->getLocation(),
  Decl->getNameAsString().length());
   }
 
   bool VisitMemberExpr(const MemberExpr *Expr) {
-const auto *Decl = Expr->getFoundDecl().getDecl();
+const NamedDecl *Decl = Expr->getFoundDecl().getDecl();
 return setResult(Decl, Expr->getMemberLoc(),
  Decl->getNameAsString().length());
   }
 
   // Other visitors:
 
   bool VisitTypeLoc(const TypeLoc Loc) {
-const auto TypeBeginLoc = Loc.getBeginLoc();
-const auto TypeEndLoc = Lexer::getLocForEndOfToken(
-TypeBeginLoc, 0, Context.getSourceManager(), Context.getLangOpts());
+const SourceLocation TypeBeginLoc = Loc.getBeginLoc();
+const SourceLocation TypeEndLoc = 

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Piotr Padlewski via cfe-commits]

Prazek added inline comments.


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:22-23
@@ +21,4 @@
+  Finder->addMatcher(
+  declRefExpr(hasDeclaration(functionDecl(namedDecl(hasName("::rand")),
+  parameterCountIs(0
+  .bind("randomGenerator"),

aaron.ballman wrote:
> Prazek wrote:
> > aaron.ballman wrote:
> > > This should be looking at a callExpr() rather than a declRefExpr(), 
> > > should it not?
> > I was also thinking about this, but this is actually better, because it 
> > will also match with binding rand with function pointer.
> True, but a DeclRefExpr doesn't mean it's a function call. Binding the 
> function is not contrary to the CERT rule, just calling it. For instance, the 
> following pathological case will be caught by this check:
> ```
> if (std::rand) {}
> ```
> The behavior of this check should be consistent with cert-env33-c, which only 
> looks at calls. (If we really care about bound functions, we'd need flow 
> control analysis, and I think that's overkill for both of those checks, but 
> wouldn't be opposed to someone writing the flow analysis if they really 
> wanted to.)
It would indeed fire on this pathological case, but I don't think we should 
care about cases like this, because no one is writing code like this (and if he 
would then it would probably be a bug).
I don't think that there is much code that binds pointer to std::rand either, 
but I think it would be good to display warning for this, because even if the 
function would be never called, then it means that this is a bug, and if it 
would be called then it would be nice to tell user that rand might be used here.

Anyway I don't oppose for changing it to callExpr, but I think it is better 
this way.


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

[PATCH] D23492: Make function local tags visible.

[Vassil Vassilev via cfe-commits]

v.g.vassilev created this revision.
v.g.vassilev added a reviewer: rsmith.
v.g.vassilev added a subscriber: cfe-commits.
v.g.vassilev set the repository for this revision to rL LLVM.

Upon instantiating function decls, we should mark visible any tag decl in the 
function's body.

Repository:
  rL LLVM

https://reviews.llvm.org/D23492

Files:
  lib/Sema/SemaLookup.cpp
  test/Modules/Inputs/PR28794/LibAHeader.h
  test/Modules/Inputs/PR28794/Subdir/Empty.h
  test/Modules/Inputs/PR28794/Subdir/LibBHeader.h
  test/Modules/Inputs/PR28794/module.modulemap
  test/Modules/pr28794.cpp

Index: test/Modules/pr28794.cpp
===
--- /dev/null
+++ test/Modules/pr28794.cpp
@@ -0,0 +1,17 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++11 -I%S/Inputs/PR28794 -verify %s
+// RUN: %clang_cc1 -std=c++11 -fmodules 
-fmodule-map-file=%S/Inputs/PR28794/module.modulemap -fmodules-cache-path=%t 
-I%S/Inputs/PR28794/ -verify %s
+
+#include "Subdir/Empty.h"
+#include "LibAHeader.h"
+
+BumpPtrAllocatorImpl<> ();
+class B {
+  struct ModuleMacroInfo {
+ModuleMacroInfo *getModuleInfo() {
+  return new (getPreprocessorAllocator()) ModuleMacroInfo();
+}
+  };
+};
+
+// expected-no-diagnostics
Index: test/Modules/Inputs/PR28794/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/module.modulemap
@@ -0,0 +1,3 @@
+module M {
+  umbrella "Subdir" module * {export *}
+}
Index: test/Modules/Inputs/PR28794/Subdir/LibBHeader.h
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/Subdir/LibBHeader.h
@@ -0,0 +1,12 @@
+#ifndef LIB_B_HEADER
+#define LIB_B_HEADER
+
+#include "LibAHeader.h"
+
+template 
+void *operator new(size_t, BumpPtrAllocatorImpl &) 
{
+  struct S {};
+  return (void*)0xdead;
+}
+
+#endif // LIB_B_HEADER
Index: test/Modules/Inputs/PR28794/Subdir/Empty.h
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/Subdir/Empty.h
@@ -0,0 +1 @@
+
Index: test/Modules/Inputs/PR28794/LibAHeader.h
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/LibAHeader.h
@@ -0,0 +1,12 @@
+#ifndef LIB_A_HEADER
+#define LIB_A_HEADER
+
+typedef __SIZE_TYPE__ size_t;
+
+template 
+class BumpPtrAllocatorImpl;
+
+template 
+void * operator new(size_t, BumpPtrAllocatorImpl 
&);
+
+#endif // LIB_A_HEADER
Index: lib/Sema/SemaLookup.cpp
===
--- lib/Sema/SemaLookup.cpp
+++ lib/Sema/SemaLookup.cpp
@@ -1535,9 +1535,13 @@
   return true;
   }
 
+  DeclContext *DC = D->getLexicalDeclContext();
+  // If this declaration is a tag in a function decl it should be visible.
+  if (isa(D) && DC && DC->isFunctionOrMethod())
+return true;
+
   // If this declaration is not at namespace scope nor module-private,
   // then it is visible if its lexical parent has a visible definition.
-  DeclContext *DC = D->getLexicalDeclContext();
   if (!D->isModulePrivate() &&
   DC && !DC->isFileContext() && !isa(DC)) {
 // For a parameter, check whether our current template declaration's


Index: test/Modules/pr28794.cpp
===
--- /dev/null
+++ test/Modules/pr28794.cpp
@@ -0,0 +1,17 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++11 -I%S/Inputs/PR28794 -verify %s
+// RUN: %clang_cc1 -std=c++11 -fmodules -fmodule-map-file=%S/Inputs/PR28794/module.modulemap -fmodules-cache-path=%t -I%S/Inputs/PR28794/ -verify %s
+
+#include "Subdir/Empty.h"
+#include "LibAHeader.h"
+
+BumpPtrAllocatorImpl<> ();
+class B {
+  struct ModuleMacroInfo {
+ModuleMacroInfo *getModuleInfo() {
+  return new (getPreprocessorAllocator()) ModuleMacroInfo();
+}
+  };
+};
+
+// expected-no-diagnostics
Index: test/Modules/Inputs/PR28794/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/module.modulemap
@@ -0,0 +1,3 @@
+module M {
+  umbrella "Subdir" module * {export *}
+}
Index: test/Modules/Inputs/PR28794/Subdir/LibBHeader.h
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/Subdir/LibBHeader.h
@@ -0,0 +1,12 @@
+#ifndef LIB_B_HEADER
+#define LIB_B_HEADER
+
+#include "LibAHeader.h"
+
+template 
+void *operator new(size_t, BumpPtrAllocatorImpl &) {
+  struct S {};
+  return (void*)0xdead;
+}
+
+#endif // LIB_B_HEADER
Index: test/Modules/Inputs/PR28794/Subdir/Empty.h
===
--- /dev/null
+++ test/Modules/Inputs/PR28794/Subdir/Empty.h
@@ -0,0 +1 @@
+
Index: test/Modules/Inputs/PR28794/LibAHeader.h

Re: [PATCH] D23385: Implement __attribute__((require_constant_initialization)) for safe static initialization.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 67987.
EricWF added a comment.

Fix missing semicolon.


https://reviews.llvm.org/D23385

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/SemaCXX/attr-require-constant-initialization.cpp

Index: test/SemaCXX/attr-require-constant-initialization.cpp
===
--- /dev/null
+++ test/SemaCXX/attr-require-constant-initialization.cpp
@@ -0,0 +1,263 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++03 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_TWO \
+// RUN: -Wglobal-constructors -std=c++14 %s
+
+#if !__has_feature(cxx_static_assert)
+# define CONCAT_(X_, Y_) CONCAT1_(X_, Y_)
+# define CONCAT1_(X_, Y_) X_ ## Y_
+
+// This emulation can be used multiple times on one line (and thus in
+// a macro), except at class scope
+# define static_assert(b_, m_) \
+  typedef int CONCAT_(sa_, __LINE__)[b_ ? 1 : -1]
+#endif
+
+#define ATTR __attribute__((require_constant_initialization))
+
+// Test diagnostics when attribute is applied to non-static declarations.
+void test_func_local(ATTR int param) { // expected-error {{only applies to variables with static or thread-local}}
+ATTR int x = 42; // expected-error {{only applies to variables with static or thread-local}}
+ATTR extern int y;
+}
+struct ATTR class_mem { // expected-error {{only applies to variables with static or thread-local}}
+  ATTR int x; // expected-error {{only applies to variables with static or thread-local}}
+};
+
+int ReturnInt();
+
+struct PODType {
+int value;
+int value2;
+};
+#if __cplusplus >= 201103L
+struct LitType {
+constexpr LitType() : value(0) {}
+constexpr LitType(int x) : value(x) {}
+LitType(void*) : value(-1) {}
+int value;
+};
+#endif
+
+struct NonLit {
+#if __cplusplus >= 201402L
+constexpr NonLit() : value(0) {}
+constexpr NonLit(int x ) : value(x) {}
+#else
+NonLit() : value(0) {}
+NonLit(int x) : value(x) {}
+#endif
+NonLit(void*) : value(-1) {}
+~NonLit() {}
+int value;
+};
+
+struct StoresNonLit {
+#if __cplusplus >= 201402L
+constexpr StoresNonLit() : obj() {}
+constexpr StoresNonLit(int x) : obj(x) {}
+#else
+StoresNonLit() : obj() {}
+StoresNonLit(int x) : obj(x) {}
+#endif
+StoresNonLit(void* p) : obj(p) {}
+NonLit obj;
+};
+
+const bool NonLitHasConstInit =
+#if __cplusplus >= 201402L
+true;
+#else
+false;
+#endif
+
+#if defined(TEST_ONE) // Test semantics of attribute
+
+// [basic.start.static]p2.1
+// if each full-expression (including implicit conversions) that appears in
+// the initializer of a reference with static or thread storage duration is
+// a constant expression (5.20) and the reference is bound to a glvalue
+// designating an object with static storage duration, to a temporary object
+// (see 12.2) or subobject thereof, or to a function;
+
+// Test binding to a static glvalue
+const int glvalue_int = 42;
+const int glvalue_int2 = ReturnInt();
+ATTR const int& glvalue_ref ATTR = glvalue_int;
+ATTR const int& glvalue_ref2 ATTR = glvalue_int2;
+ATTR __thread const int& glvalue_ref_tl = glvalue_int;
+
+void test_basic_start_static_2_1() {
+const int non_global = 42;
+ATTR static const int& local_init = non_global; // expected-error {{variable does not have a constant initializer}}
+ATTR static const int& global_init = glvalue_int;
+ATTR static const int& temp_init = 42;
+#if 0
+/// FIXME: Why is this failing?
+__thread const int& tl_init = 42;
+static_assert(__has_constant_initializer(tl_init), "");
+#endif
+}
+
+ATTR const int& temp_ref = 42;
+ATTR const int& temp_ref2 = ReturnInt(); // expected-error {{variable does not have a constant initializer}}
+ATTR const NonLit& nl_temp_ref = 42; // expected-error {{variable does not have a constant initializer}}
+
+#if __cplusplus >= 201103L
+ATTR const LitType& lit_temp_ref = 42;
+ATTR const int& subobj_ref = LitType{}.value;
+#endif
+
+ATTR const int& nl_subobj_ref = NonLit().value;  // expected-error {{variable does not have a constant initializer}}
+
+struct TT1 {
+  ATTR static const int& no_init;
+  ATTR static const int& glvalue_init;
+  ATTR static const int& temp_init;
+  ATTR static const int& subobj_init;
+#if __cplusplus >= 201103L
+  ATTR static thread_local const int& tl_glvalue_init;
+  ATTR static thread_local const int& tl_temp_init;
+#endif
+};
+const int& TT1::glvalue_init = glvalue_int;
+const int& TT1::temp_init = 42;
+const int& TT1::subobj_init = PODType().value;
+#if __cplusplus >= 201103L
+thread_local const int& TT1::tl_glvalue_init = glvalue_int;

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:22-23
@@ +21,4 @@
+  Finder->addMatcher(
+  declRefExpr(hasDeclaration(functionDecl(namedDecl(hasName("::rand")),
+  parameterCountIs(0
+  .bind("randomGenerator"),

Prazek wrote:
> aaron.ballman wrote:
> > This should be looking at a callExpr() rather than a declRefExpr(), should 
> > it not?
> I was also thinking about this, but this is actually better, because it will 
> also match with binding rand with function pointer.
True, but a DeclRefExpr doesn't mean it's a function call. Binding the function 
is not contrary to the CERT rule, just calling it. For instance, the following 
pathological case will be caught by this check:
```
if (std::rand) {}
```
The behavior of this check should be consistent with cert-env33-c, which only 
looks at calls. (If we really care about bound functions, we'd need flow 
control analysis, and I think that's overkill for both of those checks, but 
wouldn't be opposed to someone writing the flow analysis if they really wanted 
to.)


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D23385: Implement __attribute__((require_constant_initialization)) for safe static initialization.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 67986.
EricWF marked an inline comment as done.
EricWF added a comment.

Get all tests passing regarding duplicate warnings between 
`__attribute__((requires_constant_initialization))` and 
`-Wglobal-constructors`. The warning will not emit a duplicate warning about 
global constructors, but it will still warn if the variable has a global 
destructor, which make sense to me.

I believe this is ready to go and I have addressed all concerns.


https://reviews.llvm.org/D23385

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/SemaCXX/attr-require-constant-initialization.cpp

Index: test/SemaCXX/attr-require-constant-initialization.cpp
===
--- /dev/null
+++ test/SemaCXX/attr-require-constant-initialization.cpp
@@ -0,0 +1,258 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++03 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_TWO \
+// RUN: -Wglobal-constructors -std=c++14 %s
+
+#if !__has_feature(cxx_static_assert)
+# define CONCAT_(X_, Y_) CONCAT1_(X_, Y_)
+# define CONCAT1_(X_, Y_) X_ ## Y_
+
+// This emulation can be used multiple times on one line (and thus in
+// a macro), except at class scope
+# define static_assert(b_, m_) \
+  typedef int CONCAT_(sa_, __LINE__)[b_ ? 1 : -1]
+#endif
+
+#define ATTR __attribute__((require_constant_initialization))
+
+// Test diagnostics when attribute is applied to non-static declarations.
+void test_func_local(ATTR int param) { // expected-error {{only applies to variables with static or thread-local}}
+ATTR int x = 42; // expected-error {{only applies to variables with static or thread-local}}
+ATTR extern int y;
+}
+struct ATTR class_mem { // expected-error {{only applies to variables with static or thread-local}}
+  ATTR int x; // expected-error {{only applies to variables with static or thread-local}}
+};
+
+int ReturnInt();
+
+struct PODType {
+int value;
+int value2;
+};
+#if __cplusplus >= 201103L
+struct LitType {
+constexpr LitType() : value(0) {}
+constexpr LitType(int x) : value(x) {}
+LitType(void*) : value(-1) {}
+int value;
+};
+#endif
+
+struct NonLit {
+#if __cplusplus >= 201402L
+constexpr NonLit() : value(0) {}
+constexpr NonLit(int x ) : value(x) {}
+#else
+NonLit() : value(0) {}
+NonLit(int x) : value(x) {}
+#endif
+NonLit(void*) : value(-1) {}
+~NonLit() {}
+int value;
+};
+
+struct StoresNonLit {
+#if __cplusplus >= 201402L
+constexpr StoresNonLit() : obj() {}
+constexpr StoresNonLit(int x) : obj(x) {}
+#else
+StoresNonLit() : obj() {}
+StoresNonLit(int x) : obj(x) {}
+#endif
+StoresNonLit(void* p) : obj(p) {}
+NonLit obj;
+};
+
+const bool NonLitHasConstInit =
+#if __cplusplus >= 201402L
+true;
+#else
+false;
+#endif
+
+#if defined(TEST_ONE) // Test semantics of attribute
+
+// [basic.start.static]p2.1
+// if each full-expression (including implicit conversions) that appears in
+// the initializer of a reference with static or thread storage duration is
+// a constant expression (5.20) and the reference is bound to a glvalue
+// designating an object with static storage duration, to a temporary object
+// (see 12.2) or subobject thereof, or to a function;
+
+// Test binding to a static glvalue
+const int glvalue_int = 42;
+const int glvalue_int2 = ReturnInt();
+ATTR const int& glvalue_ref ATTR = glvalue_int;
+ATTR const int& glvalue_ref2 ATTR = glvalue_int2;
+ATTR __thread const int& glvalue_ref_tl = glvalue_int;
+
+void test_basic_start_static_2_1() {
+const int non_global = 42;
+ATTR static const int& local_init = non_global; // expected-error {{variable does not have a constant initializer}}
+ATTR static const int& global_init = glvalue_int;
+ATTR static const int& temp_init = 42;
+#if 0
+/// FIXME: Why is this failing?
+__thread const int& tl_init = 42;
+static_assert(__has_constant_initializer(tl_init), "");
+#endif
+}
+
+ATTR const int& temp_ref = 42;
+ATTR const int& temp_ref2 = ReturnInt(); // expected-error {{variable does not have a constant initializer}}
+ATTR const NonLit& nl_temp_ref = 42; // expected-error {{variable does not have a constant initializer}}
+
+#if __cplusplus >= 201103L
+ATTR const LitType& lit_temp_ref = 42;
+ATTR const int& subobj_ref = LitType{}.value;
+#endif
+
+ATTR const int& nl_subobj_ref = NonLit().value;  // expected-error {{variable does not have a constant initializer}}
+
+struct TT1 {
+  ATTR static const int& no_init;
+  ATTR static const int& glvalue_init;
+  ATTR static const int& temp_init;
+  ATTR static const 

Re: [PATCH] D23385: Implement __attribute__((require_constant_initialization)) for safe static initialization.

[Eric Fiselier via cfe-commits]

EricWF marked an inline comment as done.


Comment at: lib/Sema/SemaDecl.cpp:10528
@@ +10527,3 @@
+var->getLocation())) {
+  // Warn about globals which don't have a constant initializer.  Don't
+  // warn about globals with a non-trivial destructor because we already

EricWF wrote:
> I can't figure out where the diagnostic is this comment is coming from. 
> Hopefully I'm just missing something simple.
Nevermind, I kept reading "global destructor" as "global constructor" and was 
looking for the wrong thing.


https://reviews.llvm.org/D23385



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

Re: [PATCH] D23385: Implement __attribute__((require_constant_initialization)) for safe static initialization.

[Eric Fiselier via cfe-commits]

EricWF added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:10484-10485
@@ -10478,1 +10483,4 @@
 
+  if (var->hasAttr() && !Init)
+ Diag(var->getLocation(), diag::err_require_constant_init_failed);
+

rsmith wrote:
> I think this check is incorrect: we perform constant initialization (to zero) 
> for globals with no initializer.
Agreed. Technically not "constant initialization" but every bit as safe.


Comment at: lib/Sema/SemaDecl.cpp:10485
@@ +10484,3 @@
+  if (var->hasAttr() && !Init)
+ Diag(var->getLocation(), diag::err_require_constant_init_failed);
+

majnemer wrote:
> Any reason not to use the already existing `err_init_element_not_constant`?
> Any reason not to use the already existing err_init_element_not_constant?

I hadn't considered it, but the error text seems misleading, since it may 
select a constructor that's not a valid constant expression even when every 
element in the initializer is.


Comment at: lib/Sema/SemaDecl.cpp:10500
@@ +10499,3 @@
+if (!*HasConstInit)
+  Diag(var->getLocation(), diag::warn_global_constructor)
+<< Init->getSourceRange();

rsmith wrote:
> Instead of diagnosing the condition separately (and getting both a warning 
> and an error for the same situation), it would seem preferable to change this 
> to produce either `diag::warn_global_constructor` or your new error depending 
> on whether the attribute is present. This would also remove the duplicate 
> error messages if the attribute is specified on an object that is also marked 
> `constexpr`.
Already I think I've dealt with the duplicate diagnostics.


Comment at: lib/Sema/SemaDecl.cpp:10528
@@ +10527,3 @@
+var->getLocation())) {
+  // Warn about globals which don't have a constant initializer.  Don't
+  // warn about globals with a non-trivial destructor because we already

I can't figure out where the diagnostic is this comment is coming from. 
Hopefully I'm just missing something simple.


https://reviews.llvm.org/D23385



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

Re: [PATCH] D23385: Implement __attribute__((require_constant_initialization)) for safe static initialization.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 67983.
EricWF marked 2 inline comments as done.
EricWF added a comment.

Attempt to address Richards concerns about duplicate diagnostics and add tests 
for those cases.

Unfortunately the tests are failing, because there is a duplicate 
-Wglobal-constructors diagnostic, but I can't find where it's being emitted.


https://reviews.llvm.org/D23385

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/SemaCXX/attr-require-constant-initialization.cpp

Index: test/SemaCXX/attr-require-constant-initialization.cpp
===
--- /dev/null
+++ test/SemaCXX/attr-require-constant-initialization.cpp
@@ -0,0 +1,254 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++03 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_ONE -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fcxx-exceptions -DTEST_TWO \
+// RUN: -Wglobal-constructors -std=c++14 %s
+
+#if !__has_feature(cxx_static_assert)
+# define CONCAT_(X_, Y_) CONCAT1_(X_, Y_)
+# define CONCAT1_(X_, Y_) X_ ## Y_
+
+// This emulation can be used multiple times on one line (and thus in
+// a macro), except at class scope
+# define static_assert(b_, m_) \
+  typedef int CONCAT_(sa_, __LINE__)[b_ ? 1 : -1]
+#endif
+
+#define ATTR __attribute__((require_constant_initialization))
+
+// Test diagnostics when attribute is applied to non-static declarations.
+void test_func_local(ATTR int param) { // expected-error {{only applies to variables with static or thread-local}}
+ATTR int x = 42; // expected-error {{only applies to variables with static or thread-local}}
+ATTR extern int y;
+}
+struct ATTR class_mem { // expected-error {{only applies to variables with static or thread-local}}
+  ATTR int x; // expected-error {{only applies to variables with static or thread-local}}
+};
+
+int ReturnInt();
+
+struct PODType {
+int value;
+int value2;
+};
+#if __cplusplus >= 201103L
+struct LitType {
+constexpr LitType() : value(0) {}
+constexpr LitType(int x) : value(x) {}
+LitType(void*) : value(-1) {}
+int value;
+};
+#endif
+
+struct NonLit {
+#if __cplusplus >= 201402L
+constexpr NonLit() : value(0) {}
+constexpr NonLit(int x ) : value(x) {}
+#else
+NonLit() : value(0) {}
+NonLit(int x) : value(x) {}
+#endif
+NonLit(void*) : value(-1) {}
+~NonLit() {}
+int value;
+};
+
+struct StoresNonLit {
+#if __cplusplus >= 201402L
+constexpr StoresNonLit() : obj() {}
+constexpr StoresNonLit(int x) : obj(x) {}
+#else
+StoresNonLit() : obj() {}
+StoresNonLit(int x) : obj(x) {}
+#endif
+StoresNonLit(void* p) : obj(p) {}
+NonLit obj;
+};
+
+const bool NonLitHasConstInit =
+#if __cplusplus >= 201402L
+true;
+#else
+false;
+#endif
+
+#if defined(TEST_ONE) // Test semantics of attribute
+
+// [basic.start.static]p2.1
+// if each full-expression (including implicit conversions) that appears in
+// the initializer of a reference with static or thread storage duration is
+// a constant expression (5.20) and the reference is bound to a glvalue
+// designating an object with static storage duration, to a temporary object
+// (see 12.2) or subobject thereof, or to a function;
+
+// Test binding to a static glvalue
+const int glvalue_int = 42;
+const int glvalue_int2 = ReturnInt();
+ATTR const int& glvalue_ref ATTR = glvalue_int;
+ATTR const int& glvalue_ref2 ATTR = glvalue_int2;
+ATTR __thread const int& glvalue_ref_tl = glvalue_int;
+
+void test_basic_start_static_2_1() {
+const int non_global = 42;
+ATTR static const int& local_init = non_global; // expected-error {{variable does not have a constant initializer}}
+ATTR static const int& global_init = glvalue_int;
+ATTR static const int& temp_init = 42;
+#if 0
+/// FIXME: Why is this failing?
+__thread const int& tl_init = 42;
+static_assert(__has_constant_initializer(tl_init), "");
+#endif
+}
+
+ATTR const int& temp_ref = 42;
+ATTR const int& temp_ref2 = ReturnInt(); // expected-error {{variable does not have a constant initializer}}
+ATTR const NonLit& nl_temp_ref = 42; // expected-error {{variable does not have a constant initializer}}
+
+#if __cplusplus >= 201103L
+ATTR const LitType& lit_temp_ref = 42;
+ATTR const int& subobj_ref = LitType{}.value;
+#endif
+
+ATTR const int& nl_subobj_ref = NonLit().value;  // expected-error {{variable does not have a constant initializer}}
+
+struct TT1 {
+  ATTR static const int& no_init;
+  ATTR static const int& glvalue_init;
+  ATTR static const int& temp_init;
+  ATTR static const int& subobj_init;
+#if __cplusplus >= 201103L
+  ATTR static thread_local const int& tl_glvalue_init;
+  ATTR static 

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Piotr Padlewski via cfe-commits]

Prazek added inline comments.


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:22-23
@@ +21,4 @@
+  Finder->addMatcher(
+  declRefExpr(hasDeclaration(functionDecl(namedDecl(hasName("::rand")),
+  parameterCountIs(0
+  .bind("randomGenerator"),

aaron.ballman wrote:
> This should be looking at a callExpr() rather than a declRefExpr(), should it 
> not?
I was also thinking about this, but this is actually better, because it will 
also match with binding rand with function pointer.


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D21959: [X86] Add xgetbv xsetbv intrinsics

[Craig Topper via cfe-commits]

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

LGTM


https://reviews.llvm.org/D21959



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

Re: [PATCH] D23455: [Tooling] Parse compilation database command lines properly on Windows

[Zachary Turner via cfe-commits]

It occurred to me that eol detection won't work reliably. Especially for
tests, someone will write a compilation database by hand and check it in.
Maybe they have git set to convert newlines for them, and we don't want a
test to behave differently based on your source control settings.

The target triple seems correct to me, but I'll see what others have to say
On Sun, Aug 14, 2016 at 1:52 AM Manuel Klimek  wrote:

>
>
> On Sun, Aug 14, 2016, 9:52 AM Zachary Turner  wrote:
>
>> I'll try and figure out who that was on Monday and loop them in. I'm not
>> sure what problems the previous person ran into, but the test suite passes,
>> i can run it on a large codebase, and all the results look fine and as if
>> the tool is working. Hopefully the previous person has more insight into
>> what I should be looking for.
>>
>> It's not that it's time critical, I'm just a little surprised that it
>> seems so important to support a use case that I'm not sure anyone has ever
>> tried to do or would ever want to do.
>>
>
> my concern is not copying files around.
> My main concern is making the code more complex with a solution that only
> half works in the end and confusing users even more in the end vs having a
> solution that is well thought out and works reliably.
> If we're sure enough eol detection will work reliably, I'm fine. So far
> all attempts I've seen had some problems.
>
>
>> The idea of copying a compilation database around across machines, is
>> this really something we need to go out of our way to support?
>> On Sat, Aug 13, 2016 at 11:34 PM Manuel Klimek  wrote:
>>
>>> For years nobody worked on Windows support, so I'm somewhat surprised
>>> this is suddenly time critical.
>>> Usually the way this works is that we add the feature to upstream cmake,
>>> and then make a recent enough cmake a requirement for tooling. There's no
>>> need to make it a requirement for anything else. That has worked well for
>>> the initial version, too.
>>>
>>> My main problem is that I'm surprised you say you got a working version
>>> at all, given all the differences. I'm on vacation, but afterwards I'm
>>> happy to look up who previously worked on this and loop them into this
>>> thread. Or you can figure out who that was (they added the arguments
>>> support iirc) and make sure they're signing of on this.
>>>
>>>
>>>
>>> On Sun, Aug 14, 2016, 8:52 AM Zachary Turner  wrote:
>>>
 According to the existing spec [
 http://clang.llvm.org/docs/JSONCompilationDatabase.html], the command
 field "must be a valid command to rerun the exact compilation step for the
 translation unit in the environment the build system uses.".

 So copying compilation databases across environments with incompatible
 command line syntaxes is already against spec.

 That said, this does make me think that perhaps we should be checking
 the target triple instead of the host compilation environment, because if
 you were to cross compile clang-tidy for Windows from linux then try to use
 that clang-tidy on Windows, it would expect unix paths.

 How does that sound?
 On Sat, Aug 13, 2016 at 10:31 PM Zachary Turner 
 wrote:

> Also, compilation database support with CMake works correctly on
> Windows. It generates Windows command lines which need to be tokenized
> using Windows command line rules (hence why this patch makes clang-tidy
> work on Windows)
> On Sat, Aug 13, 2016 at 10:30 PM Zachary Turner 
> wrote:
>
>> I'm not disagreeing that it would be nice if CMake supported this.
>> It's probably worth trying to do even.
>>
>> But do we want to block having a working clang-tidy for clang-cl for
>> months because of that? Even if we can upstream the patch, how long 
>> before
>> we up the minimum required CMake version?
>>
>> The solution here does not regress behavior on any supported
>> configuration, and adds support for a new platform. Copying a compilation
>> database from one machine to another seems like a hypothetical edge case.
>>
>> To support testing perhaps we can make our compilation database
>> parser support an optional field in the json that CMake doesn't know 
>> about
>> like PathSyntax: 'windows'. Again, this seems like something we could do
>> iteratively and with low priority because it's not needed in order to
>> enable or fix any presently supported use cases.
>> On Sat, Aug 13, 2016 at 9:58 PM Manuel Klimek 
>> wrote:
>>
>>>
>>>
>>> On Sat, Aug 13, 2016, 10:17 PM Zachary Turner 
>>> wrote:
>>>
 The json is generated by CMake, so I don't thinks we can do this
 without patching CMake, which is a non-starter.

>>>
>>> Why? We did add compilation 

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Aaron Ballman via cfe-commits]

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

Thank you for working on this check!



Comment at: clang-tidy/cert/CERTTidyModule.cpp:37
@@ -35,1 +36,3 @@
 // DCL
+CheckFactories.registerCheck(
+"cert-msc50-cpp");

Please place this under a // MSC heading rather than // DCL.

This check should additionally be listed as cert-msc30-c 
(https://www.securecoding.cert.org/confluence/display/c/MSC30-C.+Do+not+use+the+rand%28%29+function+for+generating+pseudorandom+numbers).


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:22-23
@@ +21,4 @@
+  Finder->addMatcher(
+  declRefExpr(hasDeclaration(functionDecl(namedDecl(hasName("::rand")),
+  parameterCountIs(0
+  .bind("randomGenerator"),

This should be looking at a callExpr() rather than a declRefExpr(), should it 
not?


Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:31
@@ +30,3 @@
+  Result.Nodes.getNodeAs("randomGenerator");
+  diag(MatchedDecl->getLocation(), "rand() function has limited randomness, "
+   "use C++11 random library instead");

Prazek wrote:
> I am not sure about the diagnostics convention, it is possible that you 
> should replace comma with semicolon.
This diagnostic is incorrect for C code. Should only suggest C++  in 
C++ mode. Also, it should be a semicolon rather than a comma in the diagnostic 
text.


Comment at: clang-tidy/cert/LimitedRandomnessCheck.h:19
@@ +18,3 @@
+
+/// Pseudorandom number generators are not genuinely random. This checker warns
+/// for the usage of std::rand() function.

Both sentences are correct, but it doesn't clarify why `std::rand()` is bad. 
Should add a sentence between these two that says something about why 
std::rand() in particular is called out rather than the other pseudorandom 
number generators.


Comment at: docs/clang-tidy/checks/cert-msc50-cpp.rst:6
@@ +5,2 @@
+
+Pseudorandom number generators use mathematical algorithms to produce a 
sequence of numbers with good statistical properties, but the numbers produced 
are not genuinely random. This checker warns for the usage of std::rand().

Eugene.Zelenko wrote:
> Please use check and highlight std::rand() with ``.
The same argument could be used to disallow C++  generators that aren't 
true truly random sources. Should specify more about why rand() is particularly 
bad.


Comment at: docs/clang-tidy/checks/list.rst:20
@@ -19,2 +19,3 @@
cert-flp30-c
+   cert-msc50-cpp
cert-oop11-cpp (redirects to misc-move-constructor-init) 

Please also add a cert-msc30-c file with a redirect (like fio38-c from above).


Comment at: test/clang-tidy/cert-limited-randomness.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s cert-msc50-cpp %t
+

Please also add a test for C since the check works there as well, and will have 
different diagnostic text.


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D21959: [X86] Add xgetbv xsetbv intrinsics

[Guy Blank via cfe-commits]

guyblank added a comment.

If there aren't any further objections, I'd like go ahead with the commit.


https://reviews.llvm.org/D21959



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

Re: [PATCH] D22862: [analyzer] Fix for PR15623: eliminate unwanted ProgramState checker data propagation.

[Anton Yartsev via cfe-commits]

ayartsev added a comment.

@zaks.anna, sorry for the noise about the "misc-ps-region-store.m" test, my 
mistake.

In https://reviews.llvm.org/D22862#508674, @NoQ wrote:

> Hmm. The test in `unwanted-programstate-data-propagation.c` passes on my 
> machine even without the patch, and the return value on the respective path 
> is correctly represented as `(conj_$6{void *}) != 0U`, which comes from the 
> `evalCast()` call in `VisitLogicalExpr()` and is the default behavior of 
> `evalCast()` for Loc to pointer casts. There seems to be something amiss.


Hm, updated to trunk, now the test passes without the patch. Changing "_Bool" 
to "int" in the test reproduces the issue.

In https://reviews.llvm.org/D22862#501315, @dcoughlin wrote:

> Does this seem reasonable?


Thanks for the idea, working on the solution.

@dcoughlin, @NoQ, could you, please, tell, how you get dumps of symbolic 
expressions and constraints like "(conj_$6{void *}) != 0U"? Tried different 
debug.* checkers and clang_analyzer_explain() but failed.


https://reviews.llvm.org/D22862



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

Re: [PATCH] D23455: [Tooling] Parse compilation database command lines properly on Windows

[Manuel Klimek via cfe-commits]

On Sun, Aug 14, 2016, 9:52 AM Zachary Turner  wrote:

> I'll try and figure out who that was on Monday and loop them in. I'm not
> sure what problems the previous person ran into, but the test suite passes,
> i can run it on a large codebase, and all the results look fine and as if
> the tool is working. Hopefully the previous person has more insight into
> what I should be looking for.
>
> It's not that it's time critical, I'm just a little surprised that it
> seems so important to support a use case that I'm not sure anyone has ever
> tried to do or would ever want to do.
>

my concern is not copying files around.
My main concern is making the code more complex with a solution that only
half works in the end and confusing users even more in the end vs having a
solution that is well thought out and works reliably.
If we're sure enough eol detection will work reliably, I'm fine. So far all
attempts I've seen had some problems.


> The idea of copying a compilation database around across machines, is this
> really something we need to go out of our way to support?
> On Sat, Aug 13, 2016 at 11:34 PM Manuel Klimek  wrote:
>
>> For years nobody worked on Windows support, so I'm somewhat surprised
>> this is suddenly time critical.
>> Usually the way this works is that we add the feature to upstream cmake,
>> and then make a recent enough cmake a requirement for tooling. There's no
>> need to make it a requirement for anything else. That has worked well for
>> the initial version, too.
>>
>> My main problem is that I'm surprised you say you got a working version
>> at all, given all the differences. I'm on vacation, but afterwards I'm
>> happy to look up who previously worked on this and loop them into this
>> thread. Or you can figure out who that was (they added the arguments
>> support iirc) and make sure they're signing of on this.
>>
>>
>>
>> On Sun, Aug 14, 2016, 8:52 AM Zachary Turner  wrote:
>>
>>> According to the existing spec [
>>> http://clang.llvm.org/docs/JSONCompilationDatabase.html], the command
>>> field "must be a valid command to rerun the exact compilation step for the
>>> translation unit in the environment the build system uses.".
>>>
>>> So copying compilation databases across environments with incompatible
>>> command line syntaxes is already against spec.
>>>
>>> That said, this does make me think that perhaps we should be checking
>>> the target triple instead of the host compilation environment, because if
>>> you were to cross compile clang-tidy for Windows from linux then try to use
>>> that clang-tidy on Windows, it would expect unix paths.
>>>
>>> How does that sound?
>>> On Sat, Aug 13, 2016 at 10:31 PM Zachary Turner 
>>> wrote:
>>>
 Also, compilation database support with CMake works correctly on
 Windows. It generates Windows command lines which need to be tokenized
 using Windows command line rules (hence why this patch makes clang-tidy
 work on Windows)
 On Sat, Aug 13, 2016 at 10:30 PM Zachary Turner 
 wrote:

> I'm not disagreeing that it would be nice if CMake supported this.
> It's probably worth trying to do even.
>
> But do we want to block having a working clang-tidy for clang-cl for
> months because of that? Even if we can upstream the patch, how long before
> we up the minimum required CMake version?
>
> The solution here does not regress behavior on any supported
> configuration, and adds support for a new platform. Copying a compilation
> database from one machine to another seems like a hypothetical edge case.
>
> To support testing perhaps we can make our compilation database parser
> support an optional field in the json that CMake doesn't know about like
> PathSyntax: 'windows'. Again, this seems like something we could do
> iteratively and with low priority because it's not needed in order to
> enable or fix any presently supported use cases.
> On Sat, Aug 13, 2016 at 9:58 PM Manuel Klimek 
> wrote:
>
>>
>>
>> On Sat, Aug 13, 2016, 10:17 PM Zachary Turner 
>> wrote:
>>
>>> The json is generated by CMake, so I don't thinks we can do this
>>> without patching CMake, which is a non-starter.
>>>
>>
>> Why? We did add compilation database support to cmake in the first
>> place. Back then I did not support windows, btw, so I'd be surprised if
>> that worked now without also using the arguments format that has already
>> been added to the spec for that reason.
>>
>> I don't think this will break mingw. Mingw is still Windows, and
>>> still uses Windows backslashes, quoting rules, and escaping rules.
>>>
>>> You might be thinking of cygwin, but in the case LLVM_ON_WIN32is not
>>> defined.
>>>
>>> Reid, do you agree with this?
>>>
>>

Re: [PATCH] D22346: [Clang-tidy] CERT-MSC50-CPP (std:rand() )

[Piotr Padlewski via cfe-commits]

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

LGTM with the fixes of docs.



Comment at: clang-tidy/cert/LimitedRandomnessCheck.cpp:31
@@ +30,3 @@
+  Result.Nodes.getNodeAs("randomGenerator");
+  diag(MatchedDecl->getLocation(), "rand() function has limited randomness, "
+   "use C++11 random library instead");

I am not sure about the diagnostics convention, it is possible that you should 
replace comma with semicolon.


Repository:
  rL LLVM

https://reviews.llvm.org/D22346



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

Re: [PATCH] D23455: [Tooling] Parse compilation database command lines properly on Windows

[Zachary Turner via cfe-commits]

I'll try and figure out who that was on Monday and loop them in. I'm not
sure what problems the previous person ran into, but the test suite passes,
i can run it on a large codebase, and all the results look fine and as if
the tool is working. Hopefully the previous person has more insight into
what I should be looking for.

It's not that it's time critical, I'm just a little surprised that it seems
so important to support a use case that I'm not sure anyone has ever tried
to do or would ever want to do.

The idea of copying a compilation database around across machines, is this
really something we need to go out of our way to support?
On Sat, Aug 13, 2016 at 11:34 PM Manuel Klimek  wrote:

> For years nobody worked on Windows support, so I'm somewhat surprised this
> is suddenly time critical.
> Usually the way this works is that we add the feature to upstream cmake,
> and then make a recent enough cmake a requirement for tooling. There's no
> need to make it a requirement for anything else. That has worked well for
> the initial version, too.
>
> My main problem is that I'm surprised you say you got a working version at
> all, given all the differences. I'm on vacation, but afterwards I'm happy
> to look up who previously worked on this and loop them into this thread. Or
> you can figure out who that was (they added the arguments support iirc) and
> make sure they're signing of on this.
>
>
>
> On Sun, Aug 14, 2016, 8:52 AM Zachary Turner  wrote:
>
>> According to the existing spec [
>> http://clang.llvm.org/docs/JSONCompilationDatabase.html], the command
>> field "must be a valid command to rerun the exact compilation step for the
>> translation unit in the environment the build system uses.".
>>
>> So copying compilation databases across environments with incompatible
>> command line syntaxes is already against spec.
>>
>> That said, this does make me think that perhaps we should be checking the
>> target triple instead of the host compilation environment, because if you
>> were to cross compile clang-tidy for Windows from linux then try to use
>> that clang-tidy on Windows, it would expect unix paths.
>>
>> How does that sound?
>> On Sat, Aug 13, 2016 at 10:31 PM Zachary Turner 
>> wrote:
>>
>>> Also, compilation database support with CMake works correctly on
>>> Windows. It generates Windows command lines which need to be tokenized
>>> using Windows command line rules (hence why this patch makes clang-tidy
>>> work on Windows)
>>> On Sat, Aug 13, 2016 at 10:30 PM Zachary Turner 
>>> wrote:
>>>
 I'm not disagreeing that it would be nice if CMake supported this. It's
 probably worth trying to do even.

 But do we want to block having a working clang-tidy for clang-cl for
 months because of that? Even if we can upstream the patch, how long before
 we up the minimum required CMake version?

 The solution here does not regress behavior on any supported
 configuration, and adds support for a new platform. Copying a compilation
 database from one machine to another seems like a hypothetical edge case.

 To support testing perhaps we can make our compilation database parser
 support an optional field in the json that CMake doesn't know about like
 PathSyntax: 'windows'. Again, this seems like something we could do
 iteratively and with low priority because it's not needed in order to
 enable or fix any presently supported use cases.
 On Sat, Aug 13, 2016 at 9:58 PM Manuel Klimek 
 wrote:

>
>
> On Sat, Aug 13, 2016, 10:17 PM Zachary Turner 
> wrote:
>
>> The json is generated by CMake, so I don't thinks we can do this
>> without patching CMake, which is a non-starter.
>>
>
> Why? We did add compilation database support to cmake in the first
> place. Back then I did not support windows, btw, so I'd be surprised if
> that worked now without also using the arguments format that has already
> been added to the spec for that reason.
>
> I don't think this will break mingw. Mingw is still Windows, and still
>> uses Windows backslashes, quoting rules, and escaping rules.
>>
>> You might be thinking of cygwin, but in the case LLVM_ON_WIN32is not
>> defined.
>>
>> Reid, do you agree with this?
>>
>
> I'd like to see a stronger reason why adding arguments support to
> cmake is not the right thing to do.
>
>
>> On Sat, Aug 13, 2016 at 10:35 AM Alexander Kornienko <
>> ale...@google.com> wrote:
>>
>>> alexfh added inline comments.
>>>
>>> 
>>> Comment at: lib/Tooling/JSONCompilationDatabase.cpp:119
>>> @@ -115,1 +118,3 @@
>>>  StringRef EscapedCommandLine) {
>>> +#if defined(LLVM_ON_WIN32)
>>> +  llvm::BumpPtrAllocator Alloc;
>>> 
>>> 

Re: [PATCH] D23455: [Tooling] Parse compilation database command lines properly on Windows

[Manuel Klimek via cfe-commits]

For years nobody worked on Windows support, so I'm somewhat surprised this
is suddenly time critical.
Usually the way this works is that we add the feature to upstream cmake,
and then make a recent enough cmake a requirement for tooling. There's no
need to make it a requirement for anything else. That has worked well for
the initial version, too.

My main problem is that I'm surprised you say you got a working version at
all, given all the differences. I'm on vacation, but afterwards I'm happy
to look up who previously worked on this and loop them into this thread. Or
you can figure out who that was (they added the arguments support iirc) and
make sure they're signing of on this.


On Sun, Aug 14, 2016, 8:52 AM Zachary Turner  wrote:

> According to the existing spec [
> http://clang.llvm.org/docs/JSONCompilationDatabase.html], the command
> field "must be a valid command to rerun the exact compilation step for the
> translation unit in the environment the build system uses.".
>
> So copying compilation databases across environments with incompatible
> command line syntaxes is already against spec.
>
> That said, this does make me think that perhaps we should be checking the
> target triple instead of the host compilation environment, because if you
> were to cross compile clang-tidy for Windows from linux then try to use
> that clang-tidy on Windows, it would expect unix paths.
>
> How does that sound?
> On Sat, Aug 13, 2016 at 10:31 PM Zachary Turner 
> wrote:
>
>> Also, compilation database support with CMake works correctly on Windows.
>> It generates Windows command lines which need to be tokenized using Windows
>> command line rules (hence why this patch makes clang-tidy work on Windows)
>> On Sat, Aug 13, 2016 at 10:30 PM Zachary Turner 
>> wrote:
>>
>>> I'm not disagreeing that it would be nice if CMake supported this. It's
>>> probably worth trying to do even.
>>>
>>> But do we want to block having a working clang-tidy for clang-cl for
>>> months because of that? Even if we can upstream the patch, how long before
>>> we up the minimum required CMake version?
>>>
>>> The solution here does not regress behavior on any supported
>>> configuration, and adds support for a new platform. Copying a compilation
>>> database from one machine to another seems like a hypothetical edge case.
>>>
>>> To support testing perhaps we can make our compilation database parser
>>> support an optional field in the json that CMake doesn't know about like
>>> PathSyntax: 'windows'. Again, this seems like something we could do
>>> iteratively and with low priority because it's not needed in order to
>>> enable or fix any presently supported use cases.
>>> On Sat, Aug 13, 2016 at 9:58 PM Manuel Klimek  wrote:
>>>


 On Sat, Aug 13, 2016, 10:17 PM Zachary Turner 
 wrote:

> The json is generated by CMake, so I don't thinks we can do this
> without patching CMake, which is a non-starter.
>

 Why? We did add compilation database support to cmake in the first
 place. Back then I did not support windows, btw, so I'd be surprised if
 that worked now without also using the arguments format that has already
 been added to the spec for that reason.

 I don't think this will break mingw. Mingw is still Windows, and still
> uses Windows backslashes, quoting rules, and escaping rules.
>
> You might be thinking of cygwin, but in the case LLVM_ON_WIN32is not
> defined.
>
> Reid, do you agree with this?
>

 I'd like to see a stronger reason why adding arguments support to cmake
 is not the right thing to do.


> On Sat, Aug 13, 2016 at 10:35 AM Alexander Kornienko <
> ale...@google.com> wrote:
>
>> alexfh added inline comments.
>>
>> 
>> Comment at: lib/Tooling/JSONCompilationDatabase.cpp:119
>> @@ -115,1 +118,3 @@
>>  StringRef EscapedCommandLine) {
>> +#if defined(LLVM_ON_WIN32)
>> +  llvm::BumpPtrAllocator Alloc;
>> 
>> As noted on D23409, this will likely break mingw compatibility in
>> clang on windows. We should either add a sort of auto-detection of the
>> command line format, or extend the JSON compilation database with a way 
>> to
>> specify the command line format used (or as Reid suggests, specify a list
>> of arguments, but this should be done in a backward-compatible way).
>>
>>
>> https://reviews.llvm.org/D23455
>>
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23476: Allow manual specification of the binary directory in check_clang_tidy.py

[Alexander Kornienko via cfe-commits]

The script was never intended to be run manually. Its interface is rather
inconvenient for this. If you need to run a single test, it's easier to do
using llvm-lit (`path/to/lit test/file.cpp`). But if you for some reason
want to run the script directly, it should be possible to just modify PATH
or switch to the bin directory of the build. I don't think this flag is
needed.

On Aug 13, 2016 21:14, "Zachary Turner"  wrote:

> I was trying to rerun the lit commands manually to diagnose a failing
> test. This all works fine from lit, but if you want to run
> check_clang_tidy.py from the command line, this is convenient
> On Sat, Aug 13, 2016 at 10:27 AM Alexander Kornienko 
> wrote:
>
>> alexfh added a comment.
>>
>> Why is this change needed? What exactly doesn't work without it? I think,
>> lit should take care of setting paths or changing directories appropriately.
>>
>>
>> https://reviews.llvm.org/D23476
>>
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits