Re: r310694 - Implement latest feature test macro recommendations, P0096R4.

[Richard Smith via cfe-commits]

Hi Hans, this should go onto the Clang 5 branch. Thanks!

On 10 August 2017 at 20:39, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Thu Aug 10 20:39:40 2017
> New Revision: 310694
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310694=rev
> Log:
> Implement latest feature test macro recommendations, P0096R4.
>
> Modified:
> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> cfe/trunk/test/Lexer/cxx-features.cpp
> cfe/trunk/www/cxx_status.html
>
> Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> Frontend/InitPreprocessor.cpp?rev=310694=310693=310694=diff
> 
> ==
> --- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
> +++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Thu Aug 10 20:39:40 2017
> @@ -498,6 +498,8 @@ static void InitializeCPlusPlusFeatureTe
>  Builder.defineMacro("__cpp_ref_qualifiers", "200710");
>  Builder.defineMacro("__cpp_alias_templates", "200704");
>}
> +  if (LangOpts.ThreadsafeStatics)
> +Builder.defineMacro("__cpp_threadsafe_static_init", "200806");
>
>// C++14 features.
>if (LangOpts.CPlusPlus14) {
> @@ -520,6 +522,7 @@ static void InitializeCPlusPlusFeatureTe
>  Builder.defineMacro("__cpp_noexcept_function_type", "201510");
>  Builder.defineMacro("__cpp_capture_star_this", "201603");
>  Builder.defineMacro("__cpp_if_constexpr", "201606");
> +Builder.defineMacro("__cpp_deduction_guides", "201611");
>  Builder.defineMacro("__cpp_template_auto", "201606");
>  Builder.defineMacro("__cpp_namespace_attributes", "201411");
>  Builder.defineMacro("__cpp_enumerator_attributes", "201411");
> @@ -529,8 +532,6 @@ static void InitializeCPlusPlusFeatureTe
>  Builder.defineMacro("__cpp_structured_bindings", "201606");
>  Builder.defineMacro("__cpp_nontype_template_args", "201411");
>  Builder.defineMacro("__cpp_fold_expressions", "201603");
> -// FIXME: This is not yet listed in SD-6.
> -Builder.defineMacro("__cpp_deduction_guides", "201611");
>}
>if (LangOpts.AlignedAllocation)
>  Builder.defineMacro("__cpp_aligned_new", "201606");
>
> Modified: cfe/trunk/test/Lexer/cxx-features.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/
> cxx-features.cpp?rev=310694=310693=310694=diff
> 
> ==
> --- cfe/trunk/test/Lexer/cxx-features.cpp (original)
> +++ cfe/trunk/test/Lexer/cxx-features.cpp Thu Aug 10 20:39:40 2017
> @@ -4,7 +4,7 @@
>  // RUN: %clang_cc1 -std=c++14 -fcxx-exceptions -fsized-deallocation
> -verify %s
>  // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fsized-deallocation
> -verify %s
>  // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fsized-deallocation
> -fconcepts-ts -DCONCEPTS_TS=1 -verify %s
> -// RUN: %clang_cc1 -fno-rtti -verify %s -DNO_EXCEPTIONS -DNO_RTTI
> +// RUN: %clang_cc1 -fno-rtti -fno-threadsafe-statics -verify %s
> -DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS
>  // RUN: %clang_cc1 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify %s
>
>  // expected-no-diagnostics
> @@ -26,11 +26,11 @@
>  #error "wrong value for __cpp_hex_float"
>  #endif
>
> -#if check(inline_variables, 0, 0, 0, 201606) // FIXME: provisional name
> +#if check(inline_variables, 0, 0, 0, 201606)
>  #error "wrong value for __cpp_inline_variables"
>  #endif
>
> -#if check(aligned_new, 0, 0, 0, 201606) // FIXME: provisional name
> +#if check(aligned_new, 0, 0, 0, 201606)
>  #error "wrong value for __cpp_aligned_new"
>  #endif
>
> @@ -48,7 +48,7 @@
>
>  // constexpr checked below
>
> -#if check(if_constexpr, 0, 0, 0, 201606) // FIXME: provisional name
> +#if check(if_constexpr, 0, 0, 0, 201606)
>  #error "wrong value for __cpp_if_constexpr"
>  #endif
>
> @@ -56,11 +56,11 @@
>
>  // static_assert checked below
>
> -#if check(deduction_guides, 0, 0, 0, 201611) // FIXME: provisional name
> +#if check(deduction_guides, 0, 0, 0, 201611)
>  #error "wrong value for __cpp_deduction_guides"
>  #endif
>
> -#if check(template_auto, 0, 0, 0, 201606) // FIXME: provisional name
> +#if check(template_auto, 0, 0, 0, 201606)
>  #error "wrong value for __cpp_template_auto"
>  #endif
>
> @@ -80,7 +80,7 @@
>
>  // inheriting_constructors checked below
>
> -#if check(variadic_using, 0, 0, 0, 201611) // FIXME: provisional name
> +#if check(variadic_using, 0, 0, 0, 201611)
>  #error "wrong value for __cpp_variadic_using"
>  #endif
>
> @@ -163,6 +163,10 @@
>  #error "wrong value for __cpp_user_defined_literals"
>  #endif
>
> +#if defined(NO_THREADSAFE_STATICS) ? check(threadsafe_static_init, 0, 0,
> 0, 0) : check(threadsafe_static_init, 200806, 200806, 200806, 200806)
> +#error "wrong value for __cpp_threadsafe_static_init"
> +#endif
> +
>  #if check(lambdas, 0, 200907, 200907, 200907)
>  #error "wrong value for __cpp_lambdas"
>  #endif
>
> Modified: 

r310694 - Implement latest feature test macro recommendations, P0096R4.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Aug 10 20:39:40 2017
New Revision: 310694

URL: http://llvm.org/viewvc/llvm-project?rev=310694=rev
Log:
Implement latest feature test macro recommendations, P0096R4.

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/test/Lexer/cxx-features.cpp
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=310694=310693=310694=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Thu Aug 10 20:39:40 2017
@@ -498,6 +498,8 @@ static void InitializeCPlusPlusFeatureTe
 Builder.defineMacro("__cpp_ref_qualifiers", "200710");
 Builder.defineMacro("__cpp_alias_templates", "200704");
   }
+  if (LangOpts.ThreadsafeStatics)
+Builder.defineMacro("__cpp_threadsafe_static_init", "200806");
 
   // C++14 features.
   if (LangOpts.CPlusPlus14) {
@@ -520,6 +522,7 @@ static void InitializeCPlusPlusFeatureTe
 Builder.defineMacro("__cpp_noexcept_function_type", "201510");
 Builder.defineMacro("__cpp_capture_star_this", "201603");
 Builder.defineMacro("__cpp_if_constexpr", "201606");
+Builder.defineMacro("__cpp_deduction_guides", "201611");
 Builder.defineMacro("__cpp_template_auto", "201606");
 Builder.defineMacro("__cpp_namespace_attributes", "201411");
 Builder.defineMacro("__cpp_enumerator_attributes", "201411");
@@ -529,8 +532,6 @@ static void InitializeCPlusPlusFeatureTe
 Builder.defineMacro("__cpp_structured_bindings", "201606");
 Builder.defineMacro("__cpp_nontype_template_args", "201411");
 Builder.defineMacro("__cpp_fold_expressions", "201603");
-// FIXME: This is not yet listed in SD-6.
-Builder.defineMacro("__cpp_deduction_guides", "201611");
   }
   if (LangOpts.AlignedAllocation)
 Builder.defineMacro("__cpp_aligned_new", "201606");

Modified: cfe/trunk/test/Lexer/cxx-features.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/cxx-features.cpp?rev=310694=310693=310694=diff
==
--- cfe/trunk/test/Lexer/cxx-features.cpp (original)
+++ cfe/trunk/test/Lexer/cxx-features.cpp Thu Aug 10 20:39:40 2017
@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -std=c++14 -fcxx-exceptions -fsized-deallocation -verify %s
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fsized-deallocation -verify %s
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fsized-deallocation 
-fconcepts-ts -DCONCEPTS_TS=1 -verify %s
-// RUN: %clang_cc1 -fno-rtti -verify %s -DNO_EXCEPTIONS -DNO_RTTI
+// RUN: %clang_cc1 -fno-rtti -fno-threadsafe-statics -verify %s 
-DNO_EXCEPTIONS -DNO_RTTI -DNO_THREADSAFE_STATICS
 // RUN: %clang_cc1 -fcoroutines-ts -DNO_EXCEPTIONS -DCOROUTINES -verify %s
 
 // expected-no-diagnostics
@@ -26,11 +26,11 @@
 #error "wrong value for __cpp_hex_float"
 #endif
 
-#if check(inline_variables, 0, 0, 0, 201606) // FIXME: provisional name
+#if check(inline_variables, 0, 0, 0, 201606)
 #error "wrong value for __cpp_inline_variables"
 #endif
 
-#if check(aligned_new, 0, 0, 0, 201606) // FIXME: provisional name
+#if check(aligned_new, 0, 0, 0, 201606)
 #error "wrong value for __cpp_aligned_new"
 #endif
 
@@ -48,7 +48,7 @@
 
 // constexpr checked below
 
-#if check(if_constexpr, 0, 0, 0, 201606) // FIXME: provisional name
+#if check(if_constexpr, 0, 0, 0, 201606)
 #error "wrong value for __cpp_if_constexpr"
 #endif
 
@@ -56,11 +56,11 @@
 
 // static_assert checked below
 
-#if check(deduction_guides, 0, 0, 0, 201611) // FIXME: provisional name
+#if check(deduction_guides, 0, 0, 0, 201611)
 #error "wrong value for __cpp_deduction_guides"
 #endif
 
-#if check(template_auto, 0, 0, 0, 201606) // FIXME: provisional name
+#if check(template_auto, 0, 0, 0, 201606)
 #error "wrong value for __cpp_template_auto"
 #endif
 
@@ -80,7 +80,7 @@
 
 // inheriting_constructors checked below
 
-#if check(variadic_using, 0, 0, 0, 201611) // FIXME: provisional name
+#if check(variadic_using, 0, 0, 0, 201611)
 #error "wrong value for __cpp_variadic_using"
 #endif
 
@@ -163,6 +163,10 @@
 #error "wrong value for __cpp_user_defined_literals"
 #endif
 
+#if defined(NO_THREADSAFE_STATICS) ? check(threadsafe_static_init, 0, 0, 0, 0) 
: check(threadsafe_static_init, 200806, 200806, 200806, 200806)
+#error "wrong value for __cpp_threadsafe_static_init"
+#endif
+
 #if check(lambdas, 0, 200907, 200907, 200907)
 #error "wrong value for __cpp_lambdas"
 #endif

Modified: cfe/trunk/www/cxx_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?rev=310694=310693=310694=diff
==
--- cfe/trunk/www/cxx_status.html (original)
+++ cfe/trunk/www/cxx_status.html Thu Aug 10 20:39:40 2017
@@ -854,9 +854,9 @@ and library features that are not part o
  

r310693 - Update cxx_status to mention the upcoming Clang 5 release.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Aug 10 20:16:11 2017
New Revision: 310693

URL: http://llvm.org/viewvc/llvm-project?rev=310693=rev
Log:
Update cxx_status to mention the upcoming Clang 5 release.

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=310693=310692=310693=diff
==
--- cfe/trunk/www/cxx_status.html (original)
+++ cfe/trunk/www/cxx_status.html Thu Aug 10 20:16:11 2017
@@ -521,7 +521,7 @@ version 3.7.
 
 C++17 implementation status
 
-Clang SVN implements all the features
+Clang 5 and later implement all the features
 of the C++ 2017 Draft International Standard.
 
 You can use Clang in C++17 mode with the -std=c++1z option.
@@ -647,7 +647,7 @@ of the C++ 2017 Draft International Stan
 
   constexpr lambda expressions
   http://wg21.link/p0170r1;>P0170R1
-  SVN
+  Clang 5
 
 
   Differing begin and end types in range-based 
for
@@ -683,7 +683,7 @@ of the C++ 2017 Draft International Stan
 
   Template argument deduction for class templates
   http://wg21.link/p0091r3;>P0091R3
-  SVN
+  Clang 5
 

 http://wg21.link/p0512r0;>P0512R0
@@ -895,7 +895,7 @@ and library features that are not part o
   [DRAFT TS] Coroutines
   https://isocpp.org/files/papers/N4663.pdf;>N4663
   -fcoroutines-ts-stdlib=libc++
-  SVN
+  Clang 5
 
 
   [TS] Library Fundamentals, Version 1 (invocation type traits)


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

r310692 - PR33850: Update cxx_dr_status for Clang 5 branch.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Aug 10 20:14:20 2017
New Revision: 310692

URL: http://llvm.org/viewvc/llvm-project?rev=310692=rev
Log:
PR33850: Update cxx_dr_status for Clang 5 branch.

Modified:
cfe/trunk/test/CXX/drs/dr20xx.cpp
cfe/trunk/test/CXX/drs/dr4xx.cpp
cfe/trunk/www/cxx_dr_status.html
cfe/trunk/www/make_cxx_dr_status

Modified: cfe/trunk/test/CXX/drs/dr20xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr20xx.cpp?rev=310692=310691=310692=diff
==
--- cfe/trunk/test/CXX/drs/dr20xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr20xx.cpp Thu Aug 10 20:14:20 2017
@@ -10,7 +10,7 @@
 #define static_assert(...) _Static_assert(__VA_ARGS__)
 #endif
 
-namespace dr2094 { // dr2094: 5.0
+namespace dr2094 { // dr2094: 5
   struct A { int n; };
   struct B { volatile int n; };
   static_assert(__is_trivially_copyable(volatile int), "");

Modified: cfe/trunk/test/CXX/drs/dr4xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr4xx.cpp?rev=310692=310691=310692=diff
==
--- cfe/trunk/test/CXX/drs/dr4xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr4xx.cpp Thu Aug 10 20:14:20 2017
@@ -1202,7 +1202,7 @@ namespace dr495 { // dr495: 3.5
   long n2 = s2;
 }
 
-namespace dr496 { // dr496: sup dr2094
+namespace dr496 { // dr496: sup 2094
   struct A { int n; };
   struct B { volatile int n; };
   int check1[ __is_trivially_copyable(const int) ? 1 : -1];

Modified: cfe/trunk/www/cxx_dr_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_dr_status.html?rev=310692=310691=310692=diff
==
--- cfe/trunk/www/cxx_dr_status.html (original)
+++ cfe/trunk/www/cxx_dr_status.html Thu Aug 10 20:14:20 2017
@@ -591,7 +591,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#92;>92
 CD4
 Should exception-specifications be part of the type system?
-Clang 4 (C++17 onwards)
+Clang 4 (C++17 onwards)
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#93;>93
@@ -813,7 +813,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#129;>129
 CD3
 Stability of uninitialized auto variables
-Duplicate of 616
+Duplicate of 616
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#130;>130
@@ -1480,7 +1480,7 @@ accessible?
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#240;>240
 CD3
 Uninitialized values and undefined behavior
-Duplicate of 616
+Duplicate of 616
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#241;>241
@@ -1594,7 +1594,7 @@ accessible?
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#259;>259
 CD1
 Restrictions on explicit specialization and instantiation
-Clang 4
+Clang 4
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#260;>260
@@ -1913,7 +1913,7 @@ of class templates
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#312;>312
 CD3
 use of invalid pointer value not defined
-Duplicate of 616
+Duplicate of 616
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#313;>313
@@ -2279,7 +2279,7 @@ of class templates
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#373;>373
 C++11
 Lookup on namespace qualified name in using-directive
-SVN
+Clang 5
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#374;>374
@@ -3017,7 +3017,7 @@ of class templates
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#496;>496
 CD3
 Is a volatile-qualified type really a POD?
-Superseded by dr2094
+Superseded by 2094
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#497;>497
@@ -3541,7 +3541,7 @@ and POD class
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#583;>583
 CD3
 Relational pointer comparisons against the null pointer constant
-Clang 4
+Clang 4
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#584;>584
@@ -3613,7 +3613,7 @@ and POD class
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#595;>595
 dup
 Exception specifications in templates instantiated from class 
bodies
-Duplicate of 1330
+Duplicate of 1330
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#596;>596
@@ -3739,7 +3739,7 @@ and POD class
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#616;>616
 CD3
 Definition of indeterminate value
-Clang 4
+Clang 4
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#617;>617
@@ -5839,7 +5839,7 @@ and POD class
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1004;>1004
 C++11
 Injected-class-names as 

Re: r310691 - PR33489: A function-style cast to a deduced class template specialization type is type-dependent if it can't be resolved due to a type-dependent argument.

[Richard Smith via cfe-commits]

Hi Hans, this fixes a bug you wanted to treat as a 5.0 release blocker, so
should be ported to the branch :)

On 10 August 2017 at 19:04, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Thu Aug 10 19:04:19 2017
> New Revision: 310691
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310691=rev
> Log:
> PR33489: A function-style cast to a deduced class template specialization
> type is type-dependent if it can't be resolved due to a type-dependent
> argument.
>
> Modified:
> cfe/trunk/lib/AST/ExprCXX.cpp
> cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
>
> Modified: cfe/trunk/lib/AST/ExprCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
> ExprCXX.cpp?rev=310691=310690=310691=diff
> 
> ==
> --- cfe/trunk/lib/AST/ExprCXX.cpp (original)
> +++ cfe/trunk/lib/AST/ExprCXX.cpp Thu Aug 10 19:04:19 2017
> @@ -1052,7 +1052,9 @@ CXXUnresolvedConstructExpr::CXXUnresolve
>:Type->getType()->isRValueReferenceType()? VK_XValue
>:VK_RValue),
>   OK_Ordinary,
> - Type->getType()->isDependentType(), true, true,
> + Type->getType()->isDependentType() ||
> + Type->getType()->getContainedDeducedType(),
> + true, true,
>   Type->getType()->containsUnexpandedParameterPack()),
>  Type(Type),
>  LParenLoc(LParenLoc),
>
> Modified: cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-
> deduction.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaCXX/cxx1z-class-template-argument-deduction.cpp?rev=
> 310691=310690=310691=diff
> 
> ==
> --- cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
> (original)
> +++ cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
> Thu Aug 10 19:04:19 2017
> @@ -286,6 +286,29 @@ namespace tuple_tests {
>}
>  }
>
> +namespace dependent {
> +  template struct X {
> +X(T);
> +  };
> +  template int Var(T t) {
> +X x(t);
> +return X(x) + 1; // expected-error {{invalid operands}}
> +  }
> +  template int Cast(T t) {
> +return X(X(t)) + 1; // expected-error {{invalid operands}}
> +  }
> +  template int New(T t) {
> +return X(new X(t)) + 1; // expected-error {{invalid operands}}
> +  };
> +  template int Var(float); // expected-note {{instantiation of}}
> +  template int Cast(float); // expected-note {{instantiation of}}
> +  template int New(float); // expected-note {{instantiation of}}
> +  template int operator+(X, int);
> +  template int Var(int);
> +  template int Cast(int);
> +  template int New(int);
> +}
> +
>  #else
>
>  // expected-no-diagnostics
>
>
> ___
> 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

r310691 - PR33489: A function-style cast to a deduced class template specialization type is type-dependent if it can't be resolved due to a type-dependent argument.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Aug 10 19:04:19 2017
New Revision: 310691

URL: http://llvm.org/viewvc/llvm-project?rev=310691=rev
Log:
PR33489: A function-style cast to a deduced class template specialization type 
is type-dependent if it can't be resolved due to a type-dependent argument.

Modified:
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp

Modified: cfe/trunk/lib/AST/ExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprCXX.cpp?rev=310691=310690=310691=diff
==
--- cfe/trunk/lib/AST/ExprCXX.cpp (original)
+++ cfe/trunk/lib/AST/ExprCXX.cpp Thu Aug 10 19:04:19 2017
@@ -1052,7 +1052,9 @@ CXXUnresolvedConstructExpr::CXXUnresolve
   :Type->getType()->isRValueReferenceType()? VK_XValue
   :VK_RValue),
  OK_Ordinary,
- Type->getType()->isDependentType(), true, true,
+ Type->getType()->isDependentType() ||
+ Type->getType()->getContainedDeducedType(),
+ true, true,
  Type->getType()->containsUnexpandedParameterPack()),
 Type(Type),
 LParenLoc(LParenLoc),

Modified: cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp?rev=310691=310690=310691=diff
==
--- cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp 
(original)
+++ cfe/trunk/test/SemaCXX/cxx1z-class-template-argument-deduction.cpp Thu Aug 
10 19:04:19 2017
@@ -286,6 +286,29 @@ namespace tuple_tests {
   }
 }
 
+namespace dependent {
+  template struct X {
+X(T);
+  };
+  template int Var(T t) {
+X x(t);
+return X(x) + 1; // expected-error {{invalid operands}}
+  }
+  template int Cast(T t) {
+return X(X(t)) + 1; // expected-error {{invalid operands}}
+  }
+  template int New(T t) {
+return X(new X(t)) + 1; // expected-error {{invalid operands}}
+  };
+  template int Var(float); // expected-note {{instantiation of}}
+  template int Cast(float); // expected-note {{instantiation of}}
+  template int New(float); // expected-note {{instantiation of}}
+  template int operator+(X, int);
+  template int Var(int);
+  template int Cast(int);
+  template int New(int);
+}
+
 #else
 
 // expected-no-diagnostics


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

[libcxxabi] r310684 - Creating release candidate rc2 from release_500 branch

[Hans Wennborg via cfe-commits]

Author: hans
Date: Thu Aug 10 18:56:53 2017
New Revision: 310684

URL: http://llvm.org/viewvc/llvm-project?rev=310684=rev
Log:
Creating release candidate rc2 from release_500 branch

Added:
libcxxabi/tags/RELEASE_500/rc2/
  - copied from r310683, libcxxabi/branches/release_50/

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

[libunwind] r310690 - Creating release candidate rc2 from release_500 branch

[Hans Wennborg via cfe-commits]

Author: hans
Date: Thu Aug 10 18:57:00 2017
New Revision: 310690

URL: http://llvm.org/viewvc/llvm-project?rev=310690=rev
Log:
Creating release candidate rc2 from release_500 branch

Added:
libunwind/tags/RELEASE_500/rc2/   (props changed)
  - copied from r310689, libunwind/branches/release_50/

Propchange: libunwind/tags/RELEASE_500/rc2/
--
svn:mergeinfo = /libunwind/trunk:308871,309147


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

[libcxx] r310683 - Creating release candidate rc2 from release_500 branch

[Hans Wennborg via cfe-commits]

Author: hans
Date: Thu Aug 10 18:56:52 2017
New Revision: 310683

URL: http://llvm.org/viewvc/llvm-project?rev=310683=rev
Log:
Creating release candidate rc2 from release_500 branch

Added:
libcxx/tags/RELEASE_500/rc2/   (props changed)
  - copied from r310682, libcxx/branches/release_50/

Propchange: libcxx/tags/RELEASE_500/rc2/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Thu Aug 10 18:56:52 2017
@@ -0,0 +1,2 @@
+/libcxx/branches/apple:136569-137939
+/libcxx/trunk:309296,309307,309838,309851,309917,309920


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

Re: r310006 - [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.

[Hans Wennborg via cfe-commits]

r310677.

On Thu, Aug 10, 2017 at 5:30 PM, Akira Hatanaka  wrote:
> Can we merge this one to 5.0 too?
>
>> On Aug 3, 2017, at 4:55 PM, Akira Hatanaka via cfe-commits 
>>  wrote:
>>
>> Author: ahatanak
>> Date: Thu Aug  3 16:55:42 2017
>> New Revision: 310006
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310006=rev
>> Log:
>> [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.
>>
>> This commit fixes a bug where clang/llvm doesn't emit an unwind table
>> for a function when it is marked noexcept. Without this patch, the
>> following code terminates with an uncaught exception on ARM64:
>>
>> int foo1() noexcept {
>>  try {
>>throw 0;
>>  } catch (int i) {
>>return 0;
>>  }
>>  return 1;
>> }
>>
>> int main() {
>>  return foo1();
>> }
>>
>> rdar://problem/32411865
>>
>> Differential Revision: https://reviews.llvm.org/D35693
>>
>> Modified:
>>cfe/trunk/include/clang/Driver/ToolChain.h
>>cfe/trunk/lib/Driver/ToolChain.cpp
>>cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
>>cfe/trunk/lib/Driver/ToolChains/CrossWindows.h
>>cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>cfe/trunk/lib/Driver/ToolChains/Darwin.h
>>cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
>>cfe/trunk/lib/Driver/ToolChains/Gnu.h
>>cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
>>cfe/trunk/lib/Driver/ToolChains/MSVC.h
>>cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>>cfe/trunk/lib/Driver/ToolChains/MinGW.h
>>cfe/trunk/lib/Driver/ToolChains/NetBSD.h
>>cfe/trunk/test/Driver/clang-translation.c
>>
>> Modified: cfe/trunk/include/clang/Driver/ToolChain.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=310006=310005=310006=diff
>> ==
>> --- cfe/trunk/include/clang/Driver/ToolChain.h (original)
>> +++ cfe/trunk/include/clang/Driver/ToolChain.h Thu Aug  3 16:55:42 2017
>> @@ -315,7 +315,7 @@ public:
>>
>>   /// IsUnwindTablesDefault - Does this tool chain use -funwind-tables
>>   /// by default.
>> -  virtual bool IsUnwindTablesDefault() const;
>> +  virtual bool IsUnwindTablesDefault(const llvm::opt::ArgList ) const;
>>
>>   /// \brief Test whether this toolchain defaults to PIC.
>>   virtual bool isPICDefault() const = 0;
>>
>> Modified: cfe/trunk/lib/Driver/ToolChain.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=310006=310005=310006=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChain.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChain.cpp Thu Aug  3 16:55:42 2017
>> @@ -217,7 +217,7 @@ StringRef ToolChain::getDefaultUniversal
>>   }
>> }
>>
>> -bool ToolChain::IsUnwindTablesDefault() const {
>> +bool ToolChain::IsUnwindTablesDefault(const ArgList ) const {
>>   return false;
>> }
>>
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=310006=310005=310006=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Aug  3 16:55:42 2017
>> @@ -2599,7 +2599,7 @@ void Clang::ConstructJob(Compilation ,
>>   bool AsynchronousUnwindTables =
>>   Args.hasFlag(options::OPT_fasynchronous_unwind_tables,
>>options::OPT_fno_asynchronous_unwind_tables,
>> -   (getToolChain().IsUnwindTablesDefault() ||
>> +   (getToolChain().IsUnwindTablesDefault(Args) ||
>> getToolChain().getSanitizerArgs().needsUnwindTables()) &&
>>!KernelOrKext);
>>   if (Args.hasFlag(options::OPT_funwind_tables, 
>> options::OPT_fno_unwind_tables,
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp?rev=310006=310005=310006=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp Thu Aug  3 16:55:42 2017
>> @@ -213,7 +213,7 @@ CrossWindowsToolChain::CrossWindowsToolC
>>   }
>> }
>>
>> -bool CrossWindowsToolChain::IsUnwindTablesDefault() const {
>> +bool CrossWindowsToolChain::IsUnwindTablesDefault(const ArgList ) 
>> const {
>>   // FIXME: all non-x86 targets need unwind tables, however, LLVM currently 
>> does
>>   // not know how to emit them.
>>   return getArch() == llvm::Triple::x86_64;
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/CrossWindows.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CrossWindows.h?rev=310006=310005=310006=diff
>> 

Re: r309607 - [Driver] Allow users to silence the warning that is issued when the

[Hans Wennborg via cfe-commits]

r310676.

On Thu, Aug 10, 2017 at 5:28 PM, Akira Hatanaka  wrote:
> Forgot to mention there are three other patches that are needed to fix the
> bug introduced in r309607 (r309633, r309636 and r309640).
>
>
> On Aug 10, 2017, at 5:25 PM, Akira Hatanaka via cfe-commits
>  wrote:
>
> Can we merge this to 5.0?
>
> On Jul 31, 2017, at 12:16 PM, Akira Hatanaka via cfe-commits
>  wrote:
>
> Author: ahatanak
> Date: Mon Jul 31 12:16:40 2017
> New Revision: 309607
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309607=rev
> Log:
> [Driver] Allow users to silence the warning that is issued when the
> deployment target is earlier than iOS 11 and the target is 32-bit.
>
> This is a follow-up to r306922.
>
> rdar://problem/32230613
>
> Modified:
>   cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>   cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>   cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>   cfe/trunk/test/Driver/darwin-version.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Jul 31
> 12:16:40 2017
> @@ -138,9 +138,10 @@ def err_drv_cc_print_options_failure : E
> def err_drv_lto_without_lld : Error<"LTO requires -fuse-ld=lld">;
> def err_drv_preamble_format : Error<
>"incorrect format for -preamble-bytes=N,END">;
> -def err_invalid_ios_deployment_target : Error<
> +def warn_invalid_ios_deployment_target : Warning<
>  "invalid iOS deployment version '%0', iOS 10 is the maximum deployment "
> -  "target for 32-bit targets">;
> +  "target for 32-bit targets">, InGroup,
> +  DefaultError;
> def err_drv_conflicting_deployment_targets : Error<
>  "conflicting deployment targets, both '%0' and '%1' are present in
> environment">;
> def err_arc_unsupported_on_runtime : Error<
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jul 31 12:16:40
> 2017
> @@ -153,6 +153,9 @@ def GNUFlexibleArrayUnionMember : DiagGr
> def GNUFoldingConstant : DiagGroup<"gnu-folding-constant">;
> def FormatExtraArgs : DiagGroup<"format-extra-args">;
> def FormatZeroLength : DiagGroup<"format-zero-length">;
> +
> +def InvalidIOSDeploymentTarget :
> DiagGroup<"invalid-ios-deployment-target">;
> +
> def CXX1zCompatMangling : DiagGroup<"c++1z-compat-mangling">;
> // Name of this warning in GCC.
> def NoexceptType : DiagGroup<"noexcept-type", [CXX1zCompatMangling]>;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Mon Jul 31 12:16:40 2017
> @@ -1179,7 +1179,7 @@ void Darwin::AddDeploymentTarget(Derived
>  Driver::GetReleaseVersion(iOSVersion->getValue(), Major, Minor, Micro,
>HadExtra) &&
>  Major > 10)
> -getDriver().Diag(diag::err_invalid_ios_deployment_target)
> +getDriver().Diag(diag::warn_invalid_ios_deployment_target)
><< iOSVersion->getAsString(Args);
>
>  // Add a macro to differentiate between
> m(iphone|tv|watch)os-version-min=X.Y and
> @@ -1228,7 +1228,7 @@ void Darwin::AddDeploymentTarget(Derived
>Driver::GetReleaseVersion(iOSTarget.c_str(), Major, Minor, Micro,
>  HadExtra) &&
>Major > 10)
> -  getDriver().Diag(diag::err_invalid_ios_deployment_target)
> +  getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>  << std::string("IPHONEOS_DEPLOYMENT_TARGET=") + iOSTarget;
>
>// If there is no command-line argument to specify the Target version and
> @@ -1298,6 +1298,15 @@ void Darwin::AddDeploymentTarget(Derived
>  break;
>case llvm::Triple::IOS:
>  getTriple().getiOSVersion(Major, Minor, Micro);
> +
> +  // iOS 10 is the maximum deployment target for 32-bit targets. If
> the
> +  // inferred deployment target is iOS 11 or later, set it to
> 10.99.
> +  if (getTriple().isArch32Bit() && Major >= 11) {
> +Major = 10;
> +Minor = 99;
> +Micro = 99;
> +  }
> +
>  OSTarget = 
>  break;
>case 

Re: r309607 - [Driver] Allow users to silence the warning that is issued when the

[Hans Wennborg via cfe-commits]

r310675.

On Thu, Aug 10, 2017 at 5:25 PM, Akira Hatanaka  wrote:
> Can we merge this to 5.0?
>
>> On Jul 31, 2017, at 12:16 PM, Akira Hatanaka via cfe-commits 
>>  wrote:
>>
>> Author: ahatanak
>> Date: Mon Jul 31 12:16:40 2017
>> New Revision: 309607
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=309607=rev
>> Log:
>> [Driver] Allow users to silence the warning that is issued when the
>> deployment target is earlier than iOS 11 and the target is 32-bit.
>>
>> This is a follow-up to r306922.
>>
>> rdar://problem/32230613
>>
>> Modified:
>>cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>>cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>>cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>cfe/trunk/test/Driver/darwin-version.c
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Jul 31 
>> 12:16:40 2017
>> @@ -138,9 +138,10 @@ def err_drv_cc_print_options_failure : E
>> def err_drv_lto_without_lld : Error<"LTO requires -fuse-ld=lld">;
>> def err_drv_preamble_format : Error<
>> "incorrect format for -preamble-bytes=N,END">;
>> -def err_invalid_ios_deployment_target : Error<
>> +def warn_invalid_ios_deployment_target : Warning<
>>   "invalid iOS deployment version '%0', iOS 10 is the maximum deployment "
>> -  "target for 32-bit targets">;
>> +  "target for 32-bit targets">, InGroup,
>> +  DefaultError;
>> def err_drv_conflicting_deployment_targets : Error<
>>   "conflicting deployment targets, both '%0' and '%1' are present in 
>> environment">;
>> def err_arc_unsupported_on_runtime : Error<
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jul 31 12:16:40 
>> 2017
>> @@ -153,6 +153,9 @@ def GNUFlexibleArrayUnionMember : DiagGr
>> def GNUFoldingConstant : DiagGroup<"gnu-folding-constant">;
>> def FormatExtraArgs : DiagGroup<"format-extra-args">;
>> def FormatZeroLength : DiagGroup<"format-zero-length">;
>> +
>> +def InvalidIOSDeploymentTarget : DiagGroup<"invalid-ios-deployment-target">;
>> +
>> def CXX1zCompatMangling : DiagGroup<"c++1z-compat-mangling">;
>> // Name of this warning in GCC.
>> def NoexceptType : DiagGroup<"noexcept-type", [CXX1zCompatMangling]>;
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Mon Jul 31 12:16:40 2017
>> @@ -1179,7 +1179,7 @@ void Darwin::AddDeploymentTarget(Derived
>>   Driver::GetReleaseVersion(iOSVersion->getValue(), Major, Minor, Micro,
>> HadExtra) &&
>>   Major > 10)
>> -getDriver().Diag(diag::err_invalid_ios_deployment_target)
>> +getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>> << iOSVersion->getAsString(Args);
>>
>>   // Add a macro to differentiate between 
>> m(iphone|tv|watch)os-version-min=X.Y and
>> @@ -1228,7 +1228,7 @@ void Darwin::AddDeploymentTarget(Derived
>> Driver::GetReleaseVersion(iOSTarget.c_str(), Major, Minor, Micro,
>>   HadExtra) &&
>> Major > 10)
>> -  getDriver().Diag(diag::err_invalid_ios_deployment_target)
>> +  getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>>   << std::string("IPHONEOS_DEPLOYMENT_TARGET=") + iOSTarget;
>>
>> // If there is no command-line argument to specify the Target version and
>> @@ -1298,6 +1298,15 @@ void Darwin::AddDeploymentTarget(Derived
>>   break;
>> case llvm::Triple::IOS:
>>   getTriple().getiOSVersion(Major, Minor, Micro);
>> +
>> +  // iOS 10 is the maximum deployment target for 32-bit targets. If 
>> the
>> +  // inferred deployment target is iOS 11 or later, set it to 10.99.
>> +  if (getTriple().isArch32Bit() && Major >= 11) {
>> +Major = 10;
>> +Minor = 99;
>> +Micro = 99;
>> +  }
>> +
>>   OSTarget = 
>>   break;
>> case llvm::Triple::TvOS:
>> @@ -1393,13 +1402,6 @@ void Darwin::AddDeploymentTarget(Derived
>> HadExtra || Major >= 

[PATCH] D36423: [libc++] Introsort based sorting function

[Ben Craig via Phabricator via cfe-commits]

bcraig added a comment.

If you want the performance improvements in the BM_sort_std_worst_quick cases 
preserved, you really need to port the benchmark from Aditya's repo into the 
libcxx benchmark code base.  Otherwise, the next person that comes along to 
improve std::sort performance may very well wreck the performance gains you 
achieved.


https://reviews.llvm.org/D36423



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

Re: r309569 - Fix -Wshadow false positives with function-local classes.

[Hans Wennborg via cfe-commits]

r310674. Thanks!

On Thu, Aug 10, 2017 at 4:52 PM, Richard Smith  wrote:
> Seems reasonable to me.
>
> On 10 August 2017 at 14:28, Hans Wennborg via cfe-commits
>  wrote:
>>
>> Should we merge this to 5.0?
>>
>> On Mon, Jul 31, 2017 at 8:21 AM, Alexander Kornienko via cfe-commits
>>  wrote:
>> > Author: alexfh
>> > Date: Mon Jul 31 08:21:26 2017
>> > New Revision: 309569
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=309569=rev
>> > Log:
>> > Fix -Wshadow false positives with function-local classes.
>> >
>> > Summary:
>> > Fixes http://llvm.org/PR33947.
>> >
>> > https://godbolt.org/g/54XRMT
>> >
>> > void f(int a) {
>> >   struct A {
>> > void g(int a) {}
>> > A() { int a; }
>> >   };
>> > }
>> >
>> > 3 : :3:16: warning: declaration shadows a local variable
>> > [-Wshadow]
>> > void g(int a) {}
>> >^
>> > 1 : :1:12: note: previous declaration is here
>> > void f(int a) {
>> >^
>> > 4 : :4:15: warning: declaration shadows a local variable
>> > [-Wshadow]
>> > A() { int a; }
>> >   ^
>> > 1 : :1:12: note: previous declaration is here
>> > void f(int a) {
>> >^
>> > 2 warnings generated.
>> >
>> > The local variable `a` of the function `f` can't be accessed from a
>> > method of
>> > the function-local class A, thus no shadowing occurs and no diagnostic
>> > is
>> > needed.
>> >
>> > Reviewers: rnk, rsmith, arphaman, Quuxplusone
>> >
>> > Reviewed By: rnk, Quuxplusone
>> >
>> > Subscribers: Quuxplusone, cfe-commits
>> >
>> > Differential Revision: https://reviews.llvm.org/D35941
>> >
>> > Modified:
>> > cfe/trunk/lib/Sema/SemaDecl.cpp
>> > cfe/trunk/test/SemaCXX/warn-shadow.cpp
>> >
>> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=309569=309568=309569=diff
>> >
>> > ==
>> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Jul 31 08:21:26 2017
>> > @@ -6999,6 +6999,21 @@ void Sema::CheckShadow(NamedDecl *D, Nam
>> >return;
>> >  }
>> >}
>> > +
>> > +  if (cast(ShadowedDecl)->hasLocalStorage()) {
>> > +// A variable can't shadow a local variable in an enclosing
>> > scope, if
>> > +// they are separated by a non-capturing declaration context.
>> > +for (DeclContext *ParentDC = NewDC;
>> > + ParentDC && !ParentDC->Equals(OldDC);
>> > + ParentDC = getLambdaAwareParentOfDeclContext(ParentDC)) {
>> > +  // Only block literals, captured statements, and lambda
>> > expressions
>> > +  // can capture; other scopes don't.
>> > +  if (!isa(ParentDC) && !isa(ParentDC)
>> > &&
>> > +  !isLambdaCallOperator(ParentDC)) {
>> > +return;
>> > +  }
>> > +}
>> > +  }
>> >  }
>> >}
>> >
>> >
>> > Modified: cfe/trunk/test/SemaCXX/warn-shadow.cpp
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-shadow.cpp?rev=309569=309568=309569=diff
>> >
>> > ==
>> > --- cfe/trunk/test/SemaCXX/warn-shadow.cpp (original)
>> > +++ cfe/trunk/test/SemaCXX/warn-shadow.cpp Mon Jul 31 08:21:26 2017
>> > @@ -213,3 +213,12 @@ typedef int externC; // expected-note {{
>> >  void handleLinkageSpec() {
>> >typedef void externC; // expected-warning {{declaration shadows a
>> > typedef in the global namespace}}
>> >  }
>> > +
>> > +namespace PR33947 {
>> > +void f(int a) {
>> > +  struct A {
>> > +void g(int a) {}
>> > +A() { int a; }
>> > +  };
>> > +}
>> > +}
>> >
>> >
>> > ___
>> > 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
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

hamzasood wrote:
> rjmccall wrote:
> > hamzasood wrote:
> > > rjmccall wrote:
> > > > Shouldn't you only be accepting this in C++2a mode?
> > > I'm not sure what the system is with allowing future language features as 
> > > extensions, but I noticed that [*this] capture is allowed as an extension 
> > > pre-C++17 so I figured it would make sense for [=, this] to also be 
> > > allowed as an extension (since the proposal mentions how it's meant to 
> > > increase code clarify in the presence of [*this]).
> > Surely there should at least be an on-by-default extension warning?  The 
> > behavior we're using sounds a lot more like we're treating this as a 
> > bug-fix in the standard than a new feature.  Richard, can you weigh in here?
> The extension warning for this (ext_equals_this_lambda_capture_cxx2a) is on 
> by default.
Why did the diagnostic disappear from this file, then?


https://reviews.llvm.org/D36572



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

Re: r310006 - [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.

[Akira Hatanaka via cfe-commits]

Can we merge this one to 5.0 too?

> On Aug 3, 2017, at 4:55 PM, Akira Hatanaka via cfe-commits 
>  wrote:
> 
> Author: ahatanak
> Date: Thu Aug  3 16:55:42 2017
> New Revision: 310006
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=310006=rev
> Log:
> [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.
> 
> This commit fixes a bug where clang/llvm doesn't emit an unwind table
> for a function when it is marked noexcept. Without this patch, the
> following code terminates with an uncaught exception on ARM64:
> 
> int foo1() noexcept {
>  try {
>throw 0;
>  } catch (int i) {
>return 0;
>  }
>  return 1;
> }
> 
> int main() {
>  return foo1();
> }
> 
> rdar://problem/32411865
> 
> Differential Revision: https://reviews.llvm.org/D35693
> 
> Modified:
>cfe/trunk/include/clang/Driver/ToolChain.h
>cfe/trunk/lib/Driver/ToolChain.cpp
>cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
>cfe/trunk/lib/Driver/ToolChains/CrossWindows.h
>cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>cfe/trunk/lib/Driver/ToolChains/Darwin.h
>cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
>cfe/trunk/lib/Driver/ToolChains/Gnu.h
>cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
>cfe/trunk/lib/Driver/ToolChains/MSVC.h
>cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>cfe/trunk/lib/Driver/ToolChains/MinGW.h
>cfe/trunk/lib/Driver/ToolChains/NetBSD.h
>cfe/trunk/test/Driver/clang-translation.c
> 
> Modified: cfe/trunk/include/clang/Driver/ToolChain.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=310006=310005=310006=diff
> ==
> --- cfe/trunk/include/clang/Driver/ToolChain.h (original)
> +++ cfe/trunk/include/clang/Driver/ToolChain.h Thu Aug  3 16:55:42 2017
> @@ -315,7 +315,7 @@ public:
> 
>   /// IsUnwindTablesDefault - Does this tool chain use -funwind-tables
>   /// by default.
> -  virtual bool IsUnwindTablesDefault() const;
> +  virtual bool IsUnwindTablesDefault(const llvm::opt::ArgList ) const;
> 
>   /// \brief Test whether this toolchain defaults to PIC.
>   virtual bool isPICDefault() const = 0;
> 
> Modified: cfe/trunk/lib/Driver/ToolChain.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=310006=310005=310006=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChain.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChain.cpp Thu Aug  3 16:55:42 2017
> @@ -217,7 +217,7 @@ StringRef ToolChain::getDefaultUniversal
>   }
> }
> 
> -bool ToolChain::IsUnwindTablesDefault() const {
> +bool ToolChain::IsUnwindTablesDefault(const ArgList ) const {
>   return false;
> }
> 
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=310006=310005=310006=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Aug  3 16:55:42 2017
> @@ -2599,7 +2599,7 @@ void Clang::ConstructJob(Compilation ,
>   bool AsynchronousUnwindTables =
>   Args.hasFlag(options::OPT_fasynchronous_unwind_tables,
>options::OPT_fno_asynchronous_unwind_tables,
> -   (getToolChain().IsUnwindTablesDefault() ||
> +   (getToolChain().IsUnwindTablesDefault(Args) ||
> getToolChain().getSanitizerArgs().needsUnwindTables()) &&
>!KernelOrKext);
>   if (Args.hasFlag(options::OPT_funwind_tables, 
> options::OPT_fno_unwind_tables,
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp?rev=310006=310005=310006=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp Thu Aug  3 16:55:42 2017
> @@ -213,7 +213,7 @@ CrossWindowsToolChain::CrossWindowsToolC
>   }
> }
> 
> -bool CrossWindowsToolChain::IsUnwindTablesDefault() const {
> +bool CrossWindowsToolChain::IsUnwindTablesDefault(const ArgList ) const 
> {
>   // FIXME: all non-x86 targets need unwind tables, however, LLVM currently 
> does
>   // not know how to emit them.
>   return getArch() == llvm::Triple::x86_64;
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/CrossWindows.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CrossWindows.h?rev=310006=310005=310006=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/CrossWindows.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/CrossWindows.h Thu Aug  3 16:55:42 2017
> @@ 

Re: r309607 - [Driver] Allow users to silence the warning that is issued when the

[Akira Hatanaka via cfe-commits]

Forgot to mention there are three other patches that are needed to fix the bug 
introduced in r309607 (r309633, r309636 and r309640).

> On Aug 10, 2017, at 5:25 PM, Akira Hatanaka via cfe-commits 
>  wrote:
> 
> Can we merge this to 5.0?
> 
>> On Jul 31, 2017, at 12:16 PM, Akira Hatanaka via cfe-commits 
>>  wrote:
>> 
>> Author: ahatanak
>> Date: Mon Jul 31 12:16:40 2017
>> New Revision: 309607
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=309607=rev
>> Log:
>> [Driver] Allow users to silence the warning that is issued when the
>> deployment target is earlier than iOS 11 and the target is 32-bit.
>> 
>> This is a follow-up to r306922.
>> 
>> rdar://problem/32230613
>> 
>> Modified:
>>   cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>>   cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>>   cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>   cfe/trunk/test/Driver/darwin-version.c
>> 
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Jul 31 
>> 12:16:40 2017
>> @@ -138,9 +138,10 @@ def err_drv_cc_print_options_failure : E
>> def err_drv_lto_without_lld : Error<"LTO requires -fuse-ld=lld">;
>> def err_drv_preamble_format : Error<
>>"incorrect format for -preamble-bytes=N,END">;
>> -def err_invalid_ios_deployment_target : Error<
>> +def warn_invalid_ios_deployment_target : Warning<
>>  "invalid iOS deployment version '%0', iOS 10 is the maximum deployment "
>> -  "target for 32-bit targets">;
>> +  "target for 32-bit targets">, InGroup,
>> +  DefaultError;
>> def err_drv_conflicting_deployment_targets : Error<
>>  "conflicting deployment targets, both '%0' and '%1' are present in 
>> environment">;
>> def err_arc_unsupported_on_runtime : Error<
>> 
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jul 31 12:16:40 
>> 2017
>> @@ -153,6 +153,9 @@ def GNUFlexibleArrayUnionMember : DiagGr
>> def GNUFoldingConstant : DiagGroup<"gnu-folding-constant">;
>> def FormatExtraArgs : DiagGroup<"format-extra-args">;
>> def FormatZeroLength : DiagGroup<"format-zero-length">;
>> +
>> +def InvalidIOSDeploymentTarget : DiagGroup<"invalid-ios-deployment-target">;
>> +
>> def CXX1zCompatMangling : DiagGroup<"c++1z-compat-mangling">;
>> // Name of this warning in GCC.
>> def NoexceptType : DiagGroup<"noexcept-type", [CXX1zCompatMangling]>;
>> 
>> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=309607=309606=309607=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Mon Jul 31 12:16:40 2017
>> @@ -1179,7 +1179,7 @@ void Darwin::AddDeploymentTarget(Derived
>>  Driver::GetReleaseVersion(iOSVersion->getValue(), Major, Minor, Micro,
>>HadExtra) &&
>>  Major > 10)
>> -getDriver().Diag(diag::err_invalid_ios_deployment_target)
>> +getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>><< iOSVersion->getAsString(Args);
>> 
>>  // Add a macro to differentiate between 
>> m(iphone|tv|watch)os-version-min=X.Y and
>> @@ -1228,7 +1228,7 @@ void Darwin::AddDeploymentTarget(Derived
>>Driver::GetReleaseVersion(iOSTarget.c_str(), Major, Minor, Micro,
>>  HadExtra) &&
>>Major > 10)
>> -  getDriver().Diag(diag::err_invalid_ios_deployment_target)
>> +  getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>>  << std::string("IPHONEOS_DEPLOYMENT_TARGET=") + iOSTarget;
>> 
>>// If there is no command-line argument to specify the Target version and
>> @@ -1298,6 +1298,15 @@ void Darwin::AddDeploymentTarget(Derived
>>  break;
>>case llvm::Triple::IOS:
>>  getTriple().getiOSVersion(Major, Minor, Micro);
>> +
>> +  // iOS 10 is the maximum deployment target for 32-bit targets. If 
>> the
>> +  // inferred deployment target is iOS 11 or later, set it to 10.99.
>> +  if (getTriple().isArch32Bit() && Major >= 11) {
>> +Major = 10;
>> +Minor = 99;
>> +Micro = 99;
>> +  }
>> +
>>  OSTarget = 
>>  

Re: r309607 - [Driver] Allow users to silence the warning that is issued when the

[Akira Hatanaka via cfe-commits]

Can we merge this to 5.0?

> On Jul 31, 2017, at 12:16 PM, Akira Hatanaka via cfe-commits 
>  wrote:
> 
> Author: ahatanak
> Date: Mon Jul 31 12:16:40 2017
> New Revision: 309607
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=309607=rev
> Log:
> [Driver] Allow users to silence the warning that is issued when the
> deployment target is earlier than iOS 11 and the target is 32-bit.
> 
> This is a follow-up to r306922.
> 
> rdar://problem/32230613
> 
> Modified:
>cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>cfe/trunk/test/Driver/darwin-version.c
> 
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Jul 31 
> 12:16:40 2017
> @@ -138,9 +138,10 @@ def err_drv_cc_print_options_failure : E
> def err_drv_lto_without_lld : Error<"LTO requires -fuse-ld=lld">;
> def err_drv_preamble_format : Error<
> "incorrect format for -preamble-bytes=N,END">;
> -def err_invalid_ios_deployment_target : Error<
> +def warn_invalid_ios_deployment_target : Warning<
>   "invalid iOS deployment version '%0', iOS 10 is the maximum deployment "
> -  "target for 32-bit targets">;
> +  "target for 32-bit targets">, InGroup,
> +  DefaultError;
> def err_drv_conflicting_deployment_targets : Error<
>   "conflicting deployment targets, both '%0' and '%1' are present in 
> environment">;
> def err_arc_unsupported_on_runtime : Error<
> 
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jul 31 12:16:40 2017
> @@ -153,6 +153,9 @@ def GNUFlexibleArrayUnionMember : DiagGr
> def GNUFoldingConstant : DiagGroup<"gnu-folding-constant">;
> def FormatExtraArgs : DiagGroup<"format-extra-args">;
> def FormatZeroLength : DiagGroup<"format-zero-length">;
> +
> +def InvalidIOSDeploymentTarget : DiagGroup<"invalid-ios-deployment-target">;
> +
> def CXX1zCompatMangling : DiagGroup<"c++1z-compat-mangling">;
> // Name of this warning in GCC.
> def NoexceptType : DiagGroup<"noexcept-type", [CXX1zCompatMangling]>;
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=309607=309606=309607=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Mon Jul 31 12:16:40 2017
> @@ -1179,7 +1179,7 @@ void Darwin::AddDeploymentTarget(Derived
>   Driver::GetReleaseVersion(iOSVersion->getValue(), Major, Minor, Micro,
> HadExtra) &&
>   Major > 10)
> -getDriver().Diag(diag::err_invalid_ios_deployment_target)
> +getDriver().Diag(diag::warn_invalid_ios_deployment_target)
> << iOSVersion->getAsString(Args);
> 
>   // Add a macro to differentiate between 
> m(iphone|tv|watch)os-version-min=X.Y and
> @@ -1228,7 +1228,7 @@ void Darwin::AddDeploymentTarget(Derived
> Driver::GetReleaseVersion(iOSTarget.c_str(), Major, Minor, Micro,
>   HadExtra) &&
> Major > 10)
> -  getDriver().Diag(diag::err_invalid_ios_deployment_target)
> +  getDriver().Diag(diag::warn_invalid_ios_deployment_target)
>   << std::string("IPHONEOS_DEPLOYMENT_TARGET=") + iOSTarget;
> 
> // If there is no command-line argument to specify the Target version and
> @@ -1298,6 +1298,15 @@ void Darwin::AddDeploymentTarget(Derived
>   break;
> case llvm::Triple::IOS:
>   getTriple().getiOSVersion(Major, Minor, Micro);
> +
> +  // iOS 10 is the maximum deployment target for 32-bit targets. If 
> the
> +  // inferred deployment target is iOS 11 or later, set it to 10.99.
> +  if (getTriple().isArch32Bit() && Major >= 11) {
> +Major = 10;
> +Minor = 99;
> +Micro = 99;
> +  }
> +
>   OSTarget = 
>   break;
> case llvm::Triple::TvOS:
> @@ -1393,13 +1402,6 @@ void Darwin::AddDeploymentTarget(Derived
> HadExtra || Major >= 100 || Minor >= 100 || Micro >= 100)
>   getDriver().Diag(diag::err_drv_invalid_version_number)
>   << iOSVersion->getAsString(Args);
> -// iOS 10 is the maximum deployment 

[PATCH] D35362: [clang-tidy] Add a close-on-exec check on accept() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110659.

https://reviews.llvm.org/D35362

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecAcceptCheck.cpp
  clang-tidy/android/CloexecAcceptCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-accept.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-accept.cpp

Index: test/clang-tidy/android-cloexec-accept.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-accept.cpp
@@ -0,0 +1,28 @@
+// RUN: %check_clang_tidy %s android-cloexec-accept %t
+
+struct sockaddr {};
+typedef int socklen_t;
+#define NULL 0
+
+extern "C" int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+
+void f() {
+  accept(0, NULL, NULL);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer accept4() to accept() because accept4() allows SOCK_CLOEXEC [android-cloexec-accept]
+  // CHECK-FIXES: accept4(0, NULL, NULL, SOCK_CLOEXEC)
+}
+
+namespace i {
+int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+void g() {
+  accept(0, NULL, NULL);
+}
+} // namespace i
+
+class C {
+public:
+  int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+  void h() {
+accept(0, NULL, NULL);
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 =
 
 .. toctree::
+   android-cloexec-accept
android-cloexec-creat
android-cloexec-dup
android-cloexec-fopen
Index: docs/clang-tidy/checks/android-cloexec-accept.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-accept.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-accept
+
+android-cloexec-accept
+==
+
+The usage of ``accept()`` is not recommended, it's better to use ``accept4()``.
+Without this flag, an opened sensitive file descriptor would remain open across
+a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  accept(sockfd, addr, addrlen);
+
+  // becomes
+
+  accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,11 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-accept
+  `_ check
+
+  Detects usage of ``accept()``.
+
 - New `android-cloexec-dup
   `_ check
 
Index: clang-tidy/android/CloexecAcceptCheck.h
===
--- /dev/null
+++ clang-tidy/android/CloexecAcceptCheck.h
@@ -0,0 +1,35 @@
+//===--- CloexecAcceptCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_ACCEPT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_ACCEPT_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// accept() is better to be replaced by accept4().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-accept.html
+class CloexecAcceptCheck : public CloexecCheck {
+public:
+  CloexecAcceptCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_ACCEPT_H
Index: clang-tidy/android/CloexecAcceptCheck.cpp
===
--- /dev/null
+++ clang-tidy/android/CloexecAcceptCheck.cpp
@@ -0,0 +1,47 @@
+//===--- CloexecAcceptCheck.cpp - clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecAcceptCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace 

[PATCH] D36541: [CMake] Include LLVMFuzzer in Fuchsia toolchain

[Chris Bieneman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rL LLVM

https://reviews.llvm.org/D36541



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

r310672 - [Sema][ObjC] Fix spurious -Wcast-qual warnings.

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Thu Aug 10 17:06:49 2017
New Revision: 310672

URL: http://llvm.org/viewvc/llvm-project?rev=310672=rev
Log:
[Sema][ObjC] Fix spurious -Wcast-qual warnings.

We do not meaningfully track object const-ness of Objective-C object
types. Silence the -Wcast-qual warning that is issued when casting to or
from Objective-C object types results in losing const qualification.

rdar://problem/33807915

Modified:
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/test/SemaObjC/illegal-nonarc-bridged-cast.m

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=310672=310671=310672=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Thu Aug 10 17:06:49 2017
@@ -552,7 +552,14 @@ CastsAwayConstness(Sema , QualType
 Qualifiers SrcQuals, DestQuals;
 Self.Context.getUnqualifiedArrayType(UnwrappedSrcType, SrcQuals);
 Self.Context.getUnqualifiedArrayType(UnwrappedDestType, DestQuals);
-
+
+// We do not meaningfully track object const-ness of Objective-C object
+// types. Remove const from the source type if either the source or
+// the destination is an Objective-C object type.
+if (UnwrappedSrcType->isObjCObjectType() ||
+UnwrappedDestType->isObjCObjectType())
+  SrcQuals.removeConst();
+
 Qualifiers RetainedSrcQuals, RetainedDestQuals;
 if (CheckCVR) {
   RetainedSrcQuals.setCVRQualifiers(SrcQuals.getCVRQualifiers());

Modified: cfe/trunk/test/SemaObjC/illegal-nonarc-bridged-cast.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/illegal-nonarc-bridged-cast.m?rev=310672=310671=310672=diff
==
--- cfe/trunk/test/SemaObjC/illegal-nonarc-bridged-cast.m (original)
+++ cfe/trunk/test/SemaObjC/illegal-nonarc-bridged-cast.m Thu Aug 10 17:06:49 
2017
@@ -1,8 +1,9 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin11 -fsyntax-only -fblocks 
-verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin11 -fsyntax-only -fblocks 
-Wcast-qual -verify %s
 // rdar://10597832
 
 typedef const void *CFTypeRef;
 typedef const struct __CFString *CFStringRef;
+@class NSString;
 
 @interface NSString
 @end
@@ -18,7 +19,7 @@ NSString *CreateNSString();
 void from_cf() {
   id obj1 = (__bridge_transfer id)CFCreateSomething(); // expected-warning 
{{'__bridge_transfer' casts have no effect when not using ARC}}
   id obj2 = (__bridge_transfer NSString*)CFCreateString(); // expected-warning 
{{'__bridge_transfer' casts have no effect when not using ARC}}
-  (__bridge int*)CFCreateSomething(); // expected-warning {{expression result 
unused}}
+  (__bridge int*)CFCreateSomething(); // expected-warning {{expression result 
unused}} expected-warning {{cast from 'const void *' to 'int *' drops const 
qualifier}}
   id obj3 = (__bridge id)CFGetSomething();
   id obj4 = (__bridge NSString*)CFGetString();
 }
@@ -41,3 +42,15 @@ void to_cf_ignored(id obj) {
   CFTypeRef cf1 = (__bridge_retained CFTypeRef)CreateSomething(); // no-warning
   CFTypeRef cf3 = (__bridge CFTypeRef)CreateSomething(); // no-warning
 }
+
+// Check that clang doesn't warn about dropping const from Objective-C object
+// types.
+void test_wcast_qual() {
+  CFStringRef c;
+  NSString *n0 = (NSString *)c;
+  NSString **n1 = (NSString **)
+  const NSString *n2;
+  const NSString **n3;
+  void *p0 = (void *)n2;
+  void **p1 = (void **)n3;
+}


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

[PATCH] D35363: [clang-tidy] Add a close-on-exec check on accept4() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110655.

https://reviews.llvm.org/D35363

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecAccept4Check.cpp
  clang-tidy/android/CloexecAccept4Check.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-accept4.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-accept4.cpp

Index: test/clang-tidy/android-cloexec-accept4.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-accept4.cpp
@@ -0,0 +1,66 @@
+// RUN: %check_clang_tidy %s android-cloexec-accept4 %t
+
+typedef int socklen_t;
+struct sockaddr {};
+
+#define SOCK_NONBLOCK 1
+#define __O_CLOEXEC 3
+#define SOCK_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+#define NULL 0
+
+extern "C" int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
+
+void a() {
+  accept4(0, NULL, NULL, SOCK_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:39: warning: 'accept4' should use SOCK_CLOEXEC where possible [android-cloexec-accept4]
+  // CHECK-FIXES: accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC);
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_NONBLOCK));
+  // CHECK-MESSAGES: :[[@LINE-1]]:58: warning: 'accept4'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC))
+}
+
+void f() {
+  accept4(0, NULL, NULL, 3);
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: 'accept4'
+  // CHECK-FIXES: accept4(0, NULL, NULL, 3 | SOCK_CLOEXEC)
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, 3));
+  // CHECK-MESSAGES: :[[@LINE-1]]:46: warning: 'accept4'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, 3 | SOCK_CLOEXEC))
+
+  int flag = SOCK_NONBLOCK;
+  accept4(0, NULL, NULL, flag);
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, flag));
+}
+
+namespace i {
+int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
+
+void d() {
+  accept4(0, NULL, NULL, SOCK_NONBLOCK);
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_NONBLOCK));
+}
+
+} // namespace i
+
+void e() {
+  accept4(0, NULL, NULL, SOCK_CLOEXEC);
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_CLOEXEC));
+  accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC);
+  TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC));
+}
+
+class G {
+public:
+  int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
+  void d() {
+accept4(0, NULL, NULL, SOCK_NONBLOCK);
+TEMP_FAILURE_RETRY(accept4(0, NULL, NULL, SOCK_NONBLOCK));
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 =
 
 .. toctree::
+   android-cloexec-accept4
android-cloexec-creat
android-cloexec-dup
android-cloexec-fopen
Index: docs/clang-tidy/checks/android-cloexec-accept4.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-accept4.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-accept4
+
+android-cloexec-accept4
+===
+
+``accept4()`` should include ``SOCK_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  accept4(sockfd, addr, addrlen, SOCK_NONBLOCK);
+
+  // becomes
+
+  accept4(sockfd, addr, addrlen, SOCK_NONBLOCK | SOCK_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,12 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-accept4
+  `_ check
+
+  Checks if the required file flag ``SOCK_CLOEXEC`` is present in the argument of
+  ``accept4()``.
+
 - New `android-cloexec-dup
   `_ check
 
Index: clang-tidy/android/CloexecAccept4Check.h
===
--- /dev/null
+++ clang-tidy/android/CloexecAccept4Check.h
@@ -0,0 +1,35 @@
+//===--- CloexecAccept4Check.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//

[PATCH] D36349: [CMake] Build sanitized C++ runtimes for Fuchsia

[Chris Bieneman via Phabricator via cfe-commits]

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

This also looks good to me.


Repository:
  rL LLVM

https://reviews.llvm.org/D36349



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

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Some buildbots use the distro gcc (looks like 5.4) and at least one uses gcc 
7.1. I use gcc 6.2.
I think that with the addition of https://reviews.llvm.org/D36555, the empty 
source file warnings should go away. However, I imagine that the warnings about 
atomics will still be around. It seems that the file is written assuming it 
will be built with Clang (I'm not sure, I haven't looked at the code - just the 
warnings).


https://reviews.llvm.org/D36431



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

[PATCH] D35364: [clang-tidy] Add a close-on-exec check on dup() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110654.

https://reviews.llvm.org/D35364

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecCheck.cpp
  clang-tidy/android/CloexecCheck.h
  clang-tidy/android/CloexecDupCheck.cpp
  clang-tidy/android/CloexecDupCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-dup.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-dup.cpp

Index: test/clang-tidy/android-cloexec-dup.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-dup.cpp
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s android-cloexec-dup %t
+
+extern "C" int dup(int oldfd);
+void f() {
+  dup(1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer fcntl() to dup() because fcntl() allows F_DUPFD_CLOEXEC [android-cloexec-dup]
+  // CHECK-FIXES: fcntl(1, F_DUPFD_CLOEXEC)
+  int oldfd = 0;
+  dup(oldfd);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer
+  // CHECK-FIXES: fcntl(oldfd, F_DUPFD_CLOEXEC)
+}
+
+namespace i {
+int dup(int oldfd);
+void g() {
+  dup(0);
+  int oldfd = 1;
+  dup(oldfd);
+}
+} // namespace i
+
+class C {
+public:
+  int dup(int oldfd);
+  void h() {
+dup(0);
+int oldfd = 1;
+dup(oldfd);
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -5,6 +5,7 @@
 
 .. toctree::
android-cloexec-creat
+   android-cloexec-dup
android-cloexec-fopen
android-cloexec-memfd-create
android-cloexec-open
Index: docs/clang-tidy/checks/android-cloexec-dup.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-dup.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-dup
+
+android-cloexec-dup
+===
+
+The usage of ``dup()`` is not recommended, it's better to use ``fcntl()``,
+which can set the close-on-exec flag. Otherwise, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  int fd = dup(oldfd);
+
+  // becomes
+
+  int fd = fcntl(oldfd, F_DUPFD_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,11 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-dup
+  `_ check
+
+  Detects usage of ``dup()``.
+
 - New `android-cloexec-memfd_create
   `_ check
 
Index: clang-tidy/android/CloexecDupCheck.h
===
--- /dev/null
+++ clang-tidy/android/CloexecDupCheck.h
@@ -0,0 +1,36 @@
+//===--- CloexecDupCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_DUP_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_DUP_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// dup() is better to be replaced by fcntl(), which has close-on-exec flag.
+/// Find the usage of dup() and redirect user to use fcntl().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-dup.html
+class CloexecDupCheck : public CloexecCheck {
+public:
+  CloexecDupCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_DUP_H
Index: clang-tidy/android/CloexecDupCheck.cpp
===
--- /dev/null
+++ clang-tidy/android/CloexecDupCheck.cpp
@@ -0,0 +1,38 @@
+//===--- CloexecDupCheck.cpp - clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecDupCheck.h"
+#include "clang/AST/ASTContext.h"
+#include 

Re: r309569 - Fix -Wshadow false positives with function-local classes.

[Richard Smith via cfe-commits]

Seems reasonable to me.

On 10 August 2017 at 14:28, Hans Wennborg via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Should we merge this to 5.0?
>
> On Mon, Jul 31, 2017 at 8:21 AM, Alexander Kornienko via cfe-commits
>  wrote:
> > Author: alexfh
> > Date: Mon Jul 31 08:21:26 2017
> > New Revision: 309569
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=309569=rev
> > Log:
> > Fix -Wshadow false positives with function-local classes.
> >
> > Summary:
> > Fixes http://llvm.org/PR33947.
> >
> > https://godbolt.org/g/54XRMT
> >
> > void f(int a) {
> >   struct A {
> > void g(int a) {}
> > A() { int a; }
> >   };
> > }
> >
> > 3 : :3:16: warning: declaration shadows a local variable
> [-Wshadow]
> > void g(int a) {}
> >^
> > 1 : :1:12: note: previous declaration is here
> > void f(int a) {
> >^
> > 4 : :4:15: warning: declaration shadows a local variable
> [-Wshadow]
> > A() { int a; }
> >   ^
> > 1 : :1:12: note: previous declaration is here
> > void f(int a) {
> >^
> > 2 warnings generated.
> >
> > The local variable `a` of the function `f` can't be accessed from a
> method of
> > the function-local class A, thus no shadowing occurs and no diagnostic is
> > needed.
> >
> > Reviewers: rnk, rsmith, arphaman, Quuxplusone
> >
> > Reviewed By: rnk, Quuxplusone
> >
> > Subscribers: Quuxplusone, cfe-commits
> >
> > Differential Revision: https://reviews.llvm.org/D35941
> >
> > Modified:
> > cfe/trunk/lib/Sema/SemaDecl.cpp
> > cfe/trunk/test/SemaCXX/warn-shadow.cpp
> >
> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDecl.cpp?rev=309569=309568=309569=diff
> > 
> ==
> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Jul 31 08:21:26 2017
> > @@ -6999,6 +6999,21 @@ void Sema::CheckShadow(NamedDecl *D, Nam
> >return;
> >  }
> >}
> > +
> > +  if (cast(ShadowedDecl)->hasLocalStorage()) {
> > +// A variable can't shadow a local variable in an enclosing
> scope, if
> > +// they are separated by a non-capturing declaration context.
> > +for (DeclContext *ParentDC = NewDC;
> > + ParentDC && !ParentDC->Equals(OldDC);
> > + ParentDC = getLambdaAwareParentOfDeclContext(ParentDC)) {
> > +  // Only block literals, captured statements, and lambda
> expressions
> > +  // can capture; other scopes don't.
> > +  if (!isa(ParentDC) && !isa(ParentDC)
> &&
> > +  !isLambdaCallOperator(ParentDC)) {
> > +return;
> > +  }
> > +}
> > +  }
> >  }
> >}
> >
> >
> > Modified: cfe/trunk/test/SemaCXX/warn-shadow.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaCXX/warn-shadow.cpp?rev=309569=309568=309569=diff
> > 
> ==
> > --- cfe/trunk/test/SemaCXX/warn-shadow.cpp (original)
> > +++ cfe/trunk/test/SemaCXX/warn-shadow.cpp Mon Jul 31 08:21:26 2017
> > @@ -213,3 +213,12 @@ typedef int externC; // expected-note {{
> >  void handleLinkageSpec() {
> >typedef void externC; // expected-warning {{declaration shadows a
> typedef in the global namespace}}
> >  }
> > +
> > +namespace PR33947 {
> > +void f(int a) {
> > +  struct A {
> > +void g(int a) {}
> > +A() { int a; }
> > +  };
> > +}
> > +}
> >
> >
> > ___
> > 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
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

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

rsmith added a comment.

In https://reviews.llvm.org/D35941#823524, @alexfh wrote:

> IIUC, most cases where -Wshadow warnings are issued is when a declaration 
> from an enclosing scope would be accessible if there was no declaration that 
> shadows it. In this case the the local variable of a function would not be 
> accessible inside the local class anyway


That's not strictly true; the variable can be accessed in unevaluated operands, 
and in code doing so, a `-Wshadow` warning might (theoretically) be useful:

  void f(SomeComplexType val) {
struct A {
  decltype(val) 
  void g(int val) {
decltype(val) *p = 
  }
} a = {val};
  }

That said, suppressing the warning seems like a good thing in the common case. 
We've discussed the idea of deferring some `-Wshadow` warnings until we see a 
use; if someone cares about this case, we could consider warning only if the 
shadowed variable is actually used in an unevaluated operand.


Repository:
  rL LLVM

https://reviews.llvm.org/D35941



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

[PATCH] D36555: Move x86-specific sources to x86-specific source lists.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

Thank you for doing this. These were causing warnings with some compilers when 
built on PowerPC because the sources were just empty (macro-guarded). Not 
compiling them at all is a much cleaner solution.
LGTM but I am far from an authority on this part of the code so I'll let the 
approval come from one of the other reviewers.


https://reviews.llvm.org/D36555



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

[PATCH] D35365: [clang-tidy] Add a close-on-exec check on epoll_create1() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110652.

https://reviews.llvm.org/D35365

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecEpollCreate1Check.cpp
  clang-tidy/android/CloexecEpollCreate1Check.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-epoll-create1.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-epoll-create1.cpp

Index: test/clang-tidy/android-cloexec-epoll-create1.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-epoll-create1.cpp
@@ -0,0 +1,59 @@
+// RUN: %check_clang_tidy %s android-cloexec-epoll-create1 %t
+
+#define __O_CLOEXEC 3
+#define EPOLL_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+
+extern "C" int epoll_create1(int flags);
+
+void a() {
+  epoll_create1(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'epoll_create1' should use EPOLL_CLOEXEC where possible [android-cloexec-epoll-create1]
+  // CHECK-FIXES: epoll_create1(EPOLL_CLOEXEC)
+  TEMP_FAILURE_RETRY(epoll_create1(0));
+  // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: 'epoll_create1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(epoll_create1(EPOLL_CLOEXEC))
+}
+
+void f() {
+  epoll_create1(3);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'epoll_create1'
+  // CHECK-FIXES: epoll_create1(EPOLL_CLOEXEC)
+  TEMP_FAILURE_RETRY(epoll_create1(3));
+  // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: 'epoll_create1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(epoll_create1(EPOLL_CLOEXEC))
+
+  int flag = 0;
+  epoll_create1(EPOLL_CLOEXEC);
+  TEMP_FAILURE_RETRY(epoll_create1(EPOLL_CLOEXEC));
+}
+
+namespace i {
+int epoll_create1(int flags);
+
+void d() {
+  epoll_create1(0);
+  TEMP_FAILURE_RETRY(epoll_create1(0));
+}
+
+} // namespace i
+
+void e() {
+  epoll_create1(EPOLL_CLOEXEC);
+  TEMP_FAILURE_RETRY(epoll_create1(EPOLL_CLOEXEC));
+}
+
+class G {
+public:
+  int epoll_create1(int flags);
+  void d() {
+epoll_create1(EPOLL_CLOEXEC);
+TEMP_FAILURE_RETRY(epoll_create1(EPOLL_CLOEXEC));
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -5,6 +5,7 @@
 
 .. toctree::
android-cloexec-creat
+   android-cloexec-epoll-create1
android-cloexec-fopen
android-cloexec-memfd-create
android-cloexec-open
Index: docs/clang-tidy/checks/android-cloexec-epoll-create1.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-epoll-create1.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-epoll-create1
+
+android-cloexec-epoll-create1
+=
+
+``epoll_create1()`` should include ``EPOLL_CLOEXEC`` in its type argument to
+avoid the file descriptor leakage. Without this flag, an opened sensitive file
+would remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  epoll_create1(0);
+
+  // becomes
+
+  epoll_create1(EPOLL_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,12 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-epoll-create1
+  `_ check
+
+  Checks if the required file flag ``EPOLL_CLOEXEC`` is present in the argument of
+  ``epoll_create1()``.
+
 - New `android-cloexec-memfd_create
   `_ check
 
Index: clang-tidy/android/CloexecEpollCreate1Check.h
===
--- /dev/null
+++ clang-tidy/android/CloexecEpollCreate1Check.h
@@ -0,0 +1,35 @@
+//===--- CloexecEpollCreate1Check.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_EPOLL_CREATE1_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_EPOLL_CREATE1_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// Finds code that uses epoll_create1() without using the EPOLL_CLOEXEC flag.
+///
+/// For the user-facing documentation see:
+/// 

[PATCH] D35367: [clang-tidy] Add a close-on-exec check on epoll_create() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110650.

https://reviews.llvm.org/D35367

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecEpollCreateCheck.cpp
  clang-tidy/android/CloexecEpollCreateCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-epoll-create.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-epoll-create.cpp

Index: test/clang-tidy/android-cloexec-epoll-create.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-epoll-create.cpp
@@ -0,0 +1,24 @@
+// RUN: %check_clang_tidy %s android-cloexec-epoll-create %t
+
+extern "C" int epoll_create(int size);
+
+void f() {
+  epoll_create(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer epoll_create() to epoll_create1() because epoll_create1() allows EPOLL_CLOEXEC [android-cloexec-epoll-create]
+  // CHECK-FIXES: epoll_create1(EPOLL_CLOEXEC)
+}
+
+namespace i {
+int epoll_create(int size);
+void g() {
+  epoll_create(0);
+}
+} // namespace i
+
+class C {
+public:
+  int epoll_create(int size);
+  void h() {
+epoll_create(0);
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -5,6 +5,7 @@
 
 .. toctree::
android-cloexec-creat
+   android-cloexec-epoll-create
android-cloexec-fopen
android-cloexec-memfd-create
android-cloexec-open
Index: docs/clang-tidy/checks/android-cloexec-epoll-create.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-epoll-create.rst
@@ -0,0 +1,17 @@
+.. title:: clang-tidy - android-cloexec-epoll-create
+
+android-cloexec-epoll-create
+
+
+The usage of ``epoll_create()`` is not recommended, it's better to use
+``epoll_create1()``, which allows close-on-exec.
+
+Examples:
+
+.. code-block:: c++
+
+  epoll_create(size);
+
+  // becomes
+
+  epoll_create1(EPOLL_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,11 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-epoll-create
+  `_ check
+
+  Detects usage of ``epoll_create()``.
+
 - New `android-cloexec-memfd_create
   `_ check
 
Index: clang-tidy/android/CloexecEpollCreateCheck.h
===
--- /dev/null
+++ clang-tidy/android/CloexecEpollCreateCheck.h
@@ -0,0 +1,35 @@
+//===--- CloexecEpollCreateCheck.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_EPOLL_CREATE_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_EPOLL_CREATE_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// epoll_create() is better to be replaced by epoll_create1().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-epoll-create.html
+class CloexecEpollCreateCheck : public CloexecCheck {
+public:
+  CloexecEpollCreateCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_EPOLL_CREATE_H
Index: clang-tidy/android/CloexecEpollCreateCheck.cpp
===
--- /dev/null
+++ clang-tidy/android/CloexecEpollCreateCheck.cpp
@@ -0,0 +1,36 @@
+//===--- CloexecEpollCreateCheck.cpp - clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecEpollCreateCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void 

[PATCH] D35817: Ban implicit _Complex to scalar conversions in C++

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

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:9372
 if (!isa(Target)) {
-  if (S.SourceMgr.isInSystemMacro(CC))
+  if (S.SourceMgr.isInSystemMacro(CC) || Target->isBooleanType())
 return;

Do we really want to have different semantic rules for code from system macros?

If so, the way we usually do this is with a `DefaultError` `ExtWarn` (an 
off-by-default extension).



Comment at: clang/test/SemaCXX/warn-absolute-value.cpp:452
-  (void)abs(x);
-  // expected-warning@-1 {{using integer absolute value function 'abs' when 
argument is of complex type}}
-  // expected-note@-2 {{use function 'cabsf' instead}}

Do we have test coverage for this diagnostic in C still? (It seems to be 
unreachable in C++ now.)


https://reviews.llvm.org/D35817



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

[PATCH] D35368: [clang-tidy] Add a close-on-exec check on inotify_init1() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110649.

https://reviews.llvm.org/D35368

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecInotifyInit1Check.cpp
  clang-tidy/android/CloexecInotifyInit1Check.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-inotify-init1.cpp

Index: test/clang-tidy/android-cloexec-inotify-init1.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-inotify-init1.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s android-cloexec-inotify-init1 %t
+
+#define IN_NONBLOCK 1
+#define __O_CLOEXEC 3
+#define IN_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+
+extern "C" int inotify_init1(int flags);
+
+void a() {
+  inotify_init1(IN_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: 'inotify_init1' should use IN_CLOEXEC where possible [android-cloexec-inotify-init1]
+  // CHECK-FIXES: inotify_init1(IN_NONBLOCK | IN_CLOEXEC)
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK));
+  // CHECK-MESSAGES: :[[@LINE-1]]:47: warning: 'inotify_init1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK | IN_CLOEXEC))
+}
+
+void f() {
+  inotify_init1(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'inotify_init1'
+  // CHECK-FIXES: inotify_init1(IN_CLOEXEC)
+  TEMP_FAILURE_RETRY(inotify_init1(0));
+  // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: 'inotify_init1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(inotify_init1(IN_CLOEXEC))
+
+  int flag = 1;
+  inotify_init1(flag);
+  TEMP_FAILURE_RETRY(inotify_init1(flag));
+}
+
+namespace i {
+int inotify_init1(int flags);
+
+void d() {
+  inotify_init1(IN_NONBLOCK);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK));
+}
+
+} // namespace i
+
+void e() {
+  inotify_init1(IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_CLOEXEC));
+  inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK | IN_CLOEXEC));
+}
+
+class G {
+public:
+  int inotify_init1(int flags);
+  void d() {
+inotify_init1(IN_CLOEXEC);
+TEMP_FAILURE_RETRY(inotify_init1(IN_CLOEXEC));
+inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
+TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK | IN_CLOEXEC));
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -6,6 +6,7 @@
 .. toctree::
android-cloexec-creat
android-cloexec-fopen
+   android-cloexec-inotify-init1
android-cloexec-memfd-create
android-cloexec-open
android-cloexec-socket
Index: docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-inotify-init1
+
+android-cloexec-inotify-init1
+=
+
+``inotify_init1()`` should include ``IN_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  inotify_init1(IN_NONBLOCK);
+
+  // becomes
+
+  inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -82,6 +82,12 @@
   Finds cases where integer division in a floating point context is likely to
   cause unintended loss of precision.
 
+- New `android-cloexec-inotify-init1
+  `_ check
+
+  Checks if the required file flag ``IN_CLOEXEC`` is present in the argument of
+  ``inotify_init1()``.
+
 - New `readability-static-accessed-through-instance
   `_ check
 
Index: clang-tidy/android/CloexecInotifyInit1Check.h
===
--- /dev/null
+++ clang-tidy/android/CloexecInotifyInit1Check.h
@@ -0,0 +1,35 @@
+//===--- CloexecInotifyInit1Check.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT1_H
+#define 

Re: r310403 - Thread Safety Analysis: warn on nonsensical attributes.

[George Burgess IV via cfe-commits]

Sorry, I meant

bin/clang -Wthread-safety-attributes -Wthread-safety-analysis
/tmp/tc.cpp -std=c++17 -c -o/dev/null

(had -Wthread-safety-attributes twice in the email)

George

On Thu, Aug 10, 2017 at 4:08 PM, George Burgess IV
 wrote:
> Hello!
>
> It looks like this is causing buildbot failures related to libc++'s
> lock_guard and scoped_lock:
> http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4070/consoleFull
>
> Here's a reduced test-case (from libc++'s __mutex_base):
>
> struct __attribute__((capability("mutex"))) mutex {
>   mutex();
>   ~mutex();
> };
>
> template  struct __attribute__((scoped_lockable)) Foo {
>   _Mutex &__m_;
>
>   explicit Foo(_Mutex &__m) __attribute__((acquire_capability(__m)))
>   : __m_(__m) {}
>
>   ~Foo() __attribute__((release_capability())) {}
> };
>
> int main() {
>   ::mutex m;
>   Foo f(m);
> }
>
>
> Built with `clang -Wthread-safety-attributes
> -Wthread-safety-attributes /tmp/tc.cpp -std=c++17 -c -o/dev/null`, I
> see the following warning:
> warning: 'release_capability' attribute requires type annotated with
> 'capability' attribute; type here is 'Foo<_Mutex> *'
> [-Wthread-safety-attributes]
>
> If I change ~Foo to release_capability(__m_), I get warnings about
> both 'm' being held at the end of main, and about releasing f.__m_,
> which was not held.
>
> Since the buildbot uses -Werror, ...
>
> Can you look into this, please? :)
>
> Thanks,
> George
>
> On Tue, Aug 8, 2017 at 12:44 PM, Josh Gao via cfe-commits
>  wrote:
>> Author: jmgao
>> Date: Tue Aug  8 12:44:35 2017
>> New Revision: 310403
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310403=rev
>> Log:
>> Thread Safety Analysis: warn on nonsensical attributes.
>>
>> Add warnings in cases where an implicit `this` argument is expected to
>> attributes because either `this` doesn't exist because the attribute is
>> on a free function, or because `this` is on a type that doesn't have a
>> corresponding capability/lockable/scoped_lockable attribute.
>>
>> Reviewers: delesley, aaron.ballman
>>
>> Differential Revision: https://reviews.llvm.org/D36237
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> cfe/trunk/test/Sema/attr-capabilities.c
>> cfe/trunk/test/SemaCXX/warn-thread-safety-parsing.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=310403=310402=310403=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Aug  8 12:44:35 
>> 2017
>> @@ -2932,6 +2932,16 @@ def warn_thread_attribute_decl_not_locka
>>"%0 attribute can only be applied in a context annotated "
>>"with 'capability(\"mutex\")' attribute">,
>>InGroup, DefaultIgnore;
>> +def warn_thread_attribute_noargs_not_lockable : Warning<
>> +  "%0 attribute requires type annotated with 'capability' attribute; "
>> +  "type here is %1">,
>> +  InGroup, DefaultIgnore;
>> +def warn_thread_attribute_noargs_not_method : Warning<
>> +  "%0 attribute without arguments can only be applied to a method of a 
>> class">,
>> +  InGroup, DefaultIgnore;
>> +def warn_thread_attribute_noargs_static_method : Warning<
>> +  "%0 attribute without arguments cannot be applied to a static method">,
>> +  InGroup, DefaultIgnore;
>>  def warn_thread_attribute_decl_not_pointer : Warning<
>>"%0 only applies to pointer types; type here is %1">,
>>InGroup, DefaultIgnore;
>>
>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=310403=310402=310403=diff
>> ==
>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Aug  8 12:44:35 2017
>> @@ -480,7 +480,7 @@ static const RecordType *getRecordType(Q
>>return nullptr;
>>  }
>>
>> -static bool checkRecordTypeForCapability(Sema , QualType Ty) {
>> +template  static bool checkRecordTypeForAttr(Sema , QualType 
>> Ty) {
>>const RecordType *RT = getRecordType(Ty);
>>
>>if (!RT)
>> @@ -497,7 +497,7 @@ static bool checkRecordTypeForCapability
>>
>>// Check if the record itself has a capability.
>>RecordDecl *RD = RT->getDecl();
>> -  if (RD->hasAttr())
>> +  if (RD->hasAttr())
>>  return true;
>>
>>// Else check if any base classes have a capability.
>> @@ -505,14 +505,14 @@ static bool checkRecordTypeForCapability
>>  CXXBasePaths BPaths(false, false);
>>  if (CRD->lookupInBases([](const CXXBaseSpecifier *BS, CXXBasePath &) {
>>const auto *Type = BS->getType()->getAs();
>> -  return Type->getDecl()->hasAttr();
>> +  

[PATCH] D35370: [clang-tidy] Add a close-on-exec check on inotify_init() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110646.

https://reviews.llvm.org/D35370

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecInotifyInitCheck.cpp
  clang-tidy/android/CloexecInotifyInitCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-inotify-init.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-inotify-init.cpp

Index: test/clang-tidy/android-cloexec-inotify-init.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-inotify-init.cpp
@@ -0,0 +1,24 @@
+// RUN: %check_clang_tidy %s android-cloexec-inotify-init %t
+
+extern "C" int inotify_init();
+
+void f() {
+  inotify_init();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer inotify_init() to inotify_init1() because inotify_init1() allows IN_CLOEXEC [android-cloexec-inotify-init]
+  // CHECK-FIXES: inotify_init1(IN_CLOEXEC)
+}
+
+namespace i {
+int inotify_init();
+void g() {
+  inotify_init();
+}
+} // namespace i
+
+class C {
+public:
+  int inotify_init();
+  void h() {
+inotify_init();
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -6,6 +6,7 @@
 .. toctree::
android-cloexec-creat
android-cloexec-fopen
+   android-cloexec-inotify-init
android-cloexec-memfd-create
android-cloexec-open
android-cloexec-socket
Index: docs/clang-tidy/checks/android-cloexec-inotify-init.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-inotify-init.rst
@@ -0,0 +1,17 @@
+.. title:: clang-tidy - android-cloexec-inotify-init
+
+android-cloexec-inotify-init
+
+
+The usage of ``inotify_init()`` is not recommended, it's better to use
+``inotify_init1()``.
+
+Examples:
+
+.. code-block:: c++
+
+  inotify_init();
+
+  // becomes
+
+  inotify_init1(IN_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -70,6 +70,11 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-inotify-init
+  `_ check
+
+  Detects usage of ``inotify_init()``.
+
 - New `android-cloexec-memfd_create
   `_ check
 
Index: clang-tidy/android/CloexecInotifyInitCheck.h
===
--- /dev/null
+++ clang-tidy/android/CloexecInotifyInitCheck.h
@@ -0,0 +1,35 @@
+//===--- CloexecInotifyInitCheck.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// inotify_init() is better to be replaced by inotify_init1().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-inotify-init.html
+class CloexecInotifyInitCheck : public CloexecCheck {
+public:
+  CloexecInotifyInitCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
Index: clang-tidy/android/CloexecInotifyInitCheck.cpp
===
--- /dev/null
+++ clang-tidy/android/CloexecInotifyInitCheck.cpp
@@ -0,0 +1,34 @@
+//===--- CloexecInotifyInitCheck.cpp - clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecInotifyInitCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void CloexecInotifyInitCheck::registerMatchers(MatchFinder *Finder) {
+  

Re: r310436 - [AST] Move visibility computations into a class; NFC

[George Burgess IV via cfe-commits]

Okay, apparently release_capability doesn't work how I assumed, so it
looks like this may be a bug in r310403. Pinged that thread.

On Thu, Aug 10, 2017 at 3:24 PM, George Burgess IV
 wrote:
> Following up, 
> http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4070/console
> no longer shows ubsan failures.
>
> Looks like the attempt to fix Driver/openmp-offload.c is in r310580
> (the linked build was r310538).
>
> The libc++ test failures all seem to be a result of -Werror clang
> emitting warnings as a result of r310403, which gave us more
> diagnostics about thread safety annotations. Glancing at it, seems
> legit. Working on a fix now.
>
> On Wed, Aug 9, 2017 at 2:22 PM, George Burgess IV
>  wrote:
>> Sorry about that!
>>
>> Attempted fix is r310523. I'll keep an eye on the bot to make sure it
>> turns green.
>>
>> On Wed, Aug 9, 2017 at 1:23 PM, Juergen Ributzka  wrote:
>>> This seems to cause UBSAN issues:
>>>
>>> runtime error: load of value 4294967295, which is not a valid value for type
>>> 'clang::LVComputationKind'
>>>
>>> See ASAN+UBSAN bot on Green Dragon:
>>> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/4065/console
>>>
>>> On Tue, Aug 8, 2017 at 9:02 PM, George Burgess IV via cfe-commits
>>>  wrote:

 Author: gbiv
 Date: Tue Aug  8 21:02:49 2017
 New Revision: 310436

 URL: http://llvm.org/viewvc/llvm-project?rev=310436=rev
 Log:
 [AST] Move visibility computations into a class; NFC

 This is patch 1 in a 2 patch series that aims to fix PR29160. Its goal
 is to cache decl visibility/linkage for the duration of each
 visibility+linkage query.

 The simplest way I can see to do this is to put the visibility
 calculation code that needs to (transitively) access this cache into a
 class, which is what this patch does. Actual caching will come in patch
 2. (Another way would be to keep the cache in ASTContext + manually
 invalidate it or something, but that felt way too subtle to me.)

 Caching visibility results across multiple queries seems a bit tricky,
 since the user can add visibility attributes ~whenever they want, and
 these attributes can apparently have far-reaching effects (e.g. class
 visibility extends to its members, ...). Because a cache that's dropped
 at the end of each top-level query seems to work nearly as well and
 doesn't require any eviction logic, I opted for that design.

 Added:
 cfe/trunk/lib/AST/Linkage.h
 Modified:
 cfe/trunk/lib/AST/Decl.cpp
 cfe/trunk/lib/AST/Type.cpp

 Modified: cfe/trunk/lib/AST/Decl.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=310436=310435=310436=diff

 ==
 --- cfe/trunk/lib/AST/Decl.cpp (original)
 +++ cfe/trunk/lib/AST/Decl.cpp Tue Aug  8 21:02:49 2017
 @@ -12,6 +12,7 @@

 //===--===//

  #include "clang/AST/Decl.h"
 +#include "Linkage.h"
  #include "clang/AST/ASTContext.h"
  #include "clang/AST/ASTLambda.h"
  #include "clang/AST/ASTMutationListener.h"
 @@ -99,38 +100,6 @@ TranslationUnitDecl::TranslationUnitDecl
  // and 'matcher' is a type only matters when looking for attributes
  // and settings from the immediate context.

 -const static unsigned IgnoreExplicitVisibilityBit = 2;
 -const static unsigned IgnoreAllVisibilityBit = 4;
 -
 -/// Kinds of LV computation.  The linkage side of the computation is
 -/// always the same, but different things can change how visibility is
 -/// computed.
 -enum LVComputationKind {
 -  /// Do an LV computation for, ultimately, a type.
 -  /// Visibility may be restricted by type visibility settings and
 -  /// the visibility of template arguments.
 -  LVForType = NamedDecl::VisibilityForType,
 -
 -  /// Do an LV computation for, ultimately, a non-type declaration.
 -  /// Visibility may be restricted by value visibility settings and
 -  /// the visibility of template arguments.
 -  LVForValue = NamedDecl::VisibilityForValue,
 -
 -  /// Do an LV computation for, ultimately, a type that already has
 -  /// some sort of explicit visibility.  Visibility may only be
 -  /// restricted by the visibility of template arguments.
 -  LVForExplicitType = (LVForType | IgnoreExplicitVisibilityBit),
 -
 -  /// Do an LV computation for, ultimately, a non-type declaration
 -  /// that already has some sort of explicit visibility.  Visibility
 -  /// may only be restricted by the visibility of template arguments.
 -  LVForExplicitValue = (LVForValue | IgnoreExplicitVisibilityBit),
 -

Re: r310403 - Thread Safety Analysis: warn on nonsensical attributes.

[George Burgess IV via cfe-commits]

Hello!

It looks like this is causing buildbot failures related to libc++'s
lock_guard and scoped_lock:
http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4070/consoleFull

Here's a reduced test-case (from libc++'s __mutex_base):

struct __attribute__((capability("mutex"))) mutex {
  mutex();
  ~mutex();
};

template  struct __attribute__((scoped_lockable)) Foo {
  _Mutex &__m_;

  explicit Foo(_Mutex &__m) __attribute__((acquire_capability(__m)))
  : __m_(__m) {}

  ~Foo() __attribute__((release_capability())) {}
};

int main() {
  ::mutex m;
  Foo f(m);
}


Built with `clang -Wthread-safety-attributes
-Wthread-safety-attributes /tmp/tc.cpp -std=c++17 -c -o/dev/null`, I
see the following warning:
warning: 'release_capability' attribute requires type annotated with
'capability' attribute; type here is 'Foo<_Mutex> *'
[-Wthread-safety-attributes]

If I change ~Foo to release_capability(__m_), I get warnings about
both 'm' being held at the end of main, and about releasing f.__m_,
which was not held.

Since the buildbot uses -Werror, ...

Can you look into this, please? :)

Thanks,
George

On Tue, Aug 8, 2017 at 12:44 PM, Josh Gao via cfe-commits
 wrote:
> Author: jmgao
> Date: Tue Aug  8 12:44:35 2017
> New Revision: 310403
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310403=rev
> Log:
> Thread Safety Analysis: warn on nonsensical attributes.
>
> Add warnings in cases where an implicit `this` argument is expected to
> attributes because either `this` doesn't exist because the attribute is
> on a free function, or because `this` is on a type that doesn't have a
> corresponding capability/lockable/scoped_lockable attribute.
>
> Reviewers: delesley, aaron.ballman
>
> Differential Revision: https://reviews.llvm.org/D36237
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Sema/attr-capabilities.c
> cfe/trunk/test/SemaCXX/warn-thread-safety-parsing.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=310403=310402=310403=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Aug  8 12:44:35 
> 2017
> @@ -2932,6 +2932,16 @@ def warn_thread_attribute_decl_not_locka
>"%0 attribute can only be applied in a context annotated "
>"with 'capability(\"mutex\")' attribute">,
>InGroup, DefaultIgnore;
> +def warn_thread_attribute_noargs_not_lockable : Warning<
> +  "%0 attribute requires type annotated with 'capability' attribute; "
> +  "type here is %1">,
> +  InGroup, DefaultIgnore;
> +def warn_thread_attribute_noargs_not_method : Warning<
> +  "%0 attribute without arguments can only be applied to a method of a 
> class">,
> +  InGroup, DefaultIgnore;
> +def warn_thread_attribute_noargs_static_method : Warning<
> +  "%0 attribute without arguments cannot be applied to a static method">,
> +  InGroup, DefaultIgnore;
>  def warn_thread_attribute_decl_not_pointer : Warning<
>"%0 only applies to pointer types; type here is %1">,
>InGroup, DefaultIgnore;
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=310403=310402=310403=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Aug  8 12:44:35 2017
> @@ -480,7 +480,7 @@ static const RecordType *getRecordType(Q
>return nullptr;
>  }
>
> -static bool checkRecordTypeForCapability(Sema , QualType Ty) {
> +template  static bool checkRecordTypeForAttr(Sema , QualType 
> Ty) {
>const RecordType *RT = getRecordType(Ty);
>
>if (!RT)
> @@ -497,7 +497,7 @@ static bool checkRecordTypeForCapability
>
>// Check if the record itself has a capability.
>RecordDecl *RD = RT->getDecl();
> -  if (RD->hasAttr())
> +  if (RD->hasAttr())
>  return true;
>
>// Else check if any base classes have a capability.
> @@ -505,14 +505,14 @@ static bool checkRecordTypeForCapability
>  CXXBasePaths BPaths(false, false);
>  if (CRD->lookupInBases([](const CXXBaseSpecifier *BS, CXXBasePath &) {
>const auto *Type = BS->getType()->getAs();
> -  return Type->getDecl()->hasAttr();
> +  return Type->getDecl()->hasAttr();
>  }, BPaths))
>return true;
>}
>return false;
>  }
>
> -static bool checkTypedefTypeForCapability(QualType Ty) {
> +template  static bool checkTypedefTypeForAttr(QualType Ty) {
>const auto *TD = Ty->getAs();
>if (!TD)
>  return false;
> @@ -521,19 +521,27 @@ static bool checkTypedefTypeForCapabilit
>if (!TN)
>  return false;
>
> -  return 

[PATCH] D35372: [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng added a comment.

https://reviews.llvm.org/rL310669 is the latest and complete version. It fixes 
an issue in windows platform.


https://reviews.llvm.org/D35372



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

[PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Wei Mi via Phabricator via cfe-commits]

wmi added a comment.

I limit the bitfield separation in the last update to only happen at the 
beginning of a run so no bitfield combine will be blocked.

I think I need to explain more about why I change the direction and start to 
work on the problem in frontend. Keeping the information by generating widening 
type and letting llvm pass to do narrowing looks like a good solution to me 
originally. However, I saw in real cases that the narrowing approach in a late 
llvm stage has more difficulties than I originally thought. Some of them are 
solved but at the cost of code complexity, but others are more difficult.

- store forwarding issue: To extract legal integer width bitfields from a large 
integer generated by frontend, we need to split both stores and loads related 
with legal integer bitfields. If store is narrowed and load is not, the width 
of load may be smaller than the store and the target may have difficulty to do 
store forwarding and that fact will hit the performance.  Note, we found case 
that related load and store are in different funcs, so when deciding whether to 
narrow a store or not, it is possible that we have no idea that the related 
load is narrowed or not. If we cannot know all the related loads will be 
narrowed, the store is better not to be narrowed.

- After instcombine, some bitfield access information will be lost: The case we 
saw is: unsigned long bf1 : 16 unsigned long bf2 : 16 unsigned long bf3 : 16 
unsigned long bf4 : 8

  bool cond = "bf3 == 0 && bf4 == -1";

  Before instcombine, bf3 and bf4 are extracted from an i64 separately. We can 
know bf3 is a 16 bits access and bf4 is a 8 bit access from the extracting code 
pattern. After instcombine, bf3 and bf4 are merged into a 24 bit access, the 
comparison above is changed to: extract 24 bit data from the i64 (%bf.load = 
wide load i64, %extract = and %bf.load, 0xff) and compare %extract 
with 0x. The information that there are two legal integer bitfield 
accesses is lost, and we won't do narrowing for the load here.

  Because we cannot split the load here, we trigger store forwarding issue.

That is why I am exploring to work on the bitfield access issue in multiple 
directions.


Repository:
  rL LLVM

https://reviews.llvm.org/D36562



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

[PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Wei Mi via Phabricator via cfe-commits]

wmi updated this revision to Diff 110641.
wmi added a comment.

Don't separate bitfield in the middle of a run because it is possible to hinder 
bitfields accesses combine. Only separate bitfield at the beginning of a run.


Repository:
  rL LLVM

https://reviews.llvm.org/D36562

Files:
  lib/CodeGen/CGRecordLayoutBuilder.cpp
  test/CodeGen/2009-12-07-BitFieldAlignment.c
  test/CodeGenCXX/2009-12-23-MissingSext.cpp
  test/CodeGenCXX/bitfield.cpp
  test/CodeGenCXX/pod-member-memcpys.cpp
  test/OpenMP/atomic_capture_codegen.cpp
  test/OpenMP/atomic_read_codegen.c
  test/OpenMP/atomic_update_codegen.cpp
  test/OpenMP/atomic_write_codegen.c

Index: test/OpenMP/atomic_write_codegen.c
===
--- test/OpenMP/atomic_write_codegen.c
+++ test/OpenMP/atomic_write_codegen.c
@@ -28,12 +28,14 @@
 int4 int4x;
 
 struct BitFields {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } bfx;
 
 struct BitFields_packed {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } __attribute__ ((__packed__)) bfx_packed;
 
@@ -58,13 +60,15 @@
 } __attribute__ ((__packed__)) bfx3_packed;
 
 struct BitFields4 {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } bfx4;
 
 struct BitFields4_packed {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } __attribute__ ((__packed__)) bfx4_packed;
Index: test/OpenMP/atomic_update_codegen.cpp
===
--- test/OpenMP/atomic_update_codegen.cpp
+++ test/OpenMP/atomic_update_codegen.cpp
@@ -27,12 +27,14 @@
 int4 int4x;
 
 struct BitFields {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } bfx;
 
 struct BitFields_packed {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } __attribute__ ((__packed__)) bfx_packed;
 
@@ -57,13 +59,15 @@
 } __attribute__ ((__packed__)) bfx3_packed;
 
 struct BitFields4 {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } bfx4;
 
 struct BitFields4_packed {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } __attribute__ ((__packed__)) bfx4_packed;
Index: test/OpenMP/atomic_read_codegen.c
===
--- test/OpenMP/atomic_read_codegen.c
+++ test/OpenMP/atomic_read_codegen.c
@@ -28,12 +28,14 @@
 int4 int4x;
 
 struct BitFields {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } bfx;
 
 struct BitFields_packed {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } __attribute__ ((__packed__)) bfx_packed;
 
@@ -58,13 +60,15 @@
 } __attribute__ ((__packed__)) bfx3_packed;
 
 struct BitFields4 {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } bfx4;
 
 struct BitFields4_packed {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } __attribute__ ((__packed__)) bfx4_packed;
Index: test/OpenMP/atomic_capture_codegen.cpp
===
--- test/OpenMP/atomic_capture_codegen.cpp
+++ test/OpenMP/atomic_capture_codegen.cpp
@@ -27,12 +27,14 @@
 int4 int4x;
 
 struct BitFields {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } bfx;
 
 struct BitFields_packed {
-  int : 32;
+  int : 2;
+  int : 30;
   int a : 31;
 } __attribute__ ((__packed__)) bfx_packed;
 
@@ -57,13 +59,15 @@
 } __attribute__ ((__packed__)) bfx3_packed;
 
 struct BitFields4 {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } bfx4;
 
 struct BitFields4_packed {
-  short : 16;
+  short : 6;
+  short : 10;
   int a: 1;
   long b : 7;
 } __attribute__ ((__packed__)) bfx4_packed;
Index: test/CodeGenCXX/pod-member-memcpys.cpp
===
--- test/CodeGenCXX/pod-member-memcpys.cpp
+++ test/CodeGenCXX/pod-member-memcpys.cpp
@@ -69,7 +69,7 @@
 
 struct BitfieldMember3 {
   virtual void f();
-  int   : 8;
+  int z : 8;
   int x : 1;
   int y;
 };
Index: test/CodeGenCXX/bitfield.cpp
===
--- test/CodeGenCXX/bitfield.cpp
+++ test/CodeGenCXX/bitfield.cpp
@@ -478,3 +478,42 @@
 s->b = x;
   }
 }
+
+namespace N8 {
+  // If a bitfield is at the beginning of a group of bitfields, has the width of legal integer type
+  // and it is natually aligned, the bitfield will be accessed like a separate memory location.
+  struct S {
+unsigned b1 : 16;
+unsigned b2 : 6;
+unsigned b3 : 2;
+unsigned b4 : 3;
+  };
+  unsigned read00(S* s) {
+// CHECK-X86-64-LABEL: define i32 @_ZN2N86read00EPNS_1SE
+// CHECK-X86-64:   %[[cast:.*]] = bitcast %{{.*}} to i16*
+// CHECK-X86-64:   %[[val:.*]]  = load i16, i16* %[[cast]]
+// CHECK-X86-64:   %[[ext:.*]]  = zext i16 %[[val]] to i32
+// CHECK-X86-64:  ret i32 %[[ext]]
+// CHECK-PPC64-LABEL: define zeroext i32 @_ZN2N86read00EPNS_1SE
+// CHECK-PPC64:   %[[val:.*]]   = load i32, i32* {{.*}}
+// 

Re: r310436 - [AST] Move visibility computations into a class; NFC

[George Burgess IV via cfe-commits]

Following up, 
http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4070/console
no longer shows ubsan failures.

Looks like the attempt to fix Driver/openmp-offload.c is in r310580
(the linked build was r310538).

The libc++ test failures all seem to be a result of -Werror clang
emitting warnings as a result of r310403, which gave us more
diagnostics about thread safety annotations. Glancing at it, seems
legit. Working on a fix now.

On Wed, Aug 9, 2017 at 2:22 PM, George Burgess IV
 wrote:
> Sorry about that!
>
> Attempted fix is r310523. I'll keep an eye on the bot to make sure it
> turns green.
>
> On Wed, Aug 9, 2017 at 1:23 PM, Juergen Ributzka  wrote:
>> This seems to cause UBSAN issues:
>>
>> runtime error: load of value 4294967295, which is not a valid value for type
>> 'clang::LVComputationKind'
>>
>> See ASAN+UBSAN bot on Green Dragon:
>> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/4065/console
>>
>> On Tue, Aug 8, 2017 at 9:02 PM, George Burgess IV via cfe-commits
>>  wrote:
>>>
>>> Author: gbiv
>>> Date: Tue Aug  8 21:02:49 2017
>>> New Revision: 310436
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=310436=rev
>>> Log:
>>> [AST] Move visibility computations into a class; NFC
>>>
>>> This is patch 1 in a 2 patch series that aims to fix PR29160. Its goal
>>> is to cache decl visibility/linkage for the duration of each
>>> visibility+linkage query.
>>>
>>> The simplest way I can see to do this is to put the visibility
>>> calculation code that needs to (transitively) access this cache into a
>>> class, which is what this patch does. Actual caching will come in patch
>>> 2. (Another way would be to keep the cache in ASTContext + manually
>>> invalidate it or something, but that felt way too subtle to me.)
>>>
>>> Caching visibility results across multiple queries seems a bit tricky,
>>> since the user can add visibility attributes ~whenever they want, and
>>> these attributes can apparently have far-reaching effects (e.g. class
>>> visibility extends to its members, ...). Because a cache that's dropped
>>> at the end of each top-level query seems to work nearly as well and
>>> doesn't require any eviction logic, I opted for that design.
>>>
>>> Added:
>>> cfe/trunk/lib/AST/Linkage.h
>>> Modified:
>>> cfe/trunk/lib/AST/Decl.cpp
>>> cfe/trunk/lib/AST/Type.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/Decl.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=310436=310435=310436=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/Decl.cpp (original)
>>> +++ cfe/trunk/lib/AST/Decl.cpp Tue Aug  8 21:02:49 2017
>>> @@ -12,6 +12,7 @@
>>>
>>> //===--===//
>>>
>>>  #include "clang/AST/Decl.h"
>>> +#include "Linkage.h"
>>>  #include "clang/AST/ASTContext.h"
>>>  #include "clang/AST/ASTLambda.h"
>>>  #include "clang/AST/ASTMutationListener.h"
>>> @@ -99,38 +100,6 @@ TranslationUnitDecl::TranslationUnitDecl
>>>  // and 'matcher' is a type only matters when looking for attributes
>>>  // and settings from the immediate context.
>>>
>>> -const static unsigned IgnoreExplicitVisibilityBit = 2;
>>> -const static unsigned IgnoreAllVisibilityBit = 4;
>>> -
>>> -/// Kinds of LV computation.  The linkage side of the computation is
>>> -/// always the same, but different things can change how visibility is
>>> -/// computed.
>>> -enum LVComputationKind {
>>> -  /// Do an LV computation for, ultimately, a type.
>>> -  /// Visibility may be restricted by type visibility settings and
>>> -  /// the visibility of template arguments.
>>> -  LVForType = NamedDecl::VisibilityForType,
>>> -
>>> -  /// Do an LV computation for, ultimately, a non-type declaration.
>>> -  /// Visibility may be restricted by value visibility settings and
>>> -  /// the visibility of template arguments.
>>> -  LVForValue = NamedDecl::VisibilityForValue,
>>> -
>>> -  /// Do an LV computation for, ultimately, a type that already has
>>> -  /// some sort of explicit visibility.  Visibility may only be
>>> -  /// restricted by the visibility of template arguments.
>>> -  LVForExplicitType = (LVForType | IgnoreExplicitVisibilityBit),
>>> -
>>> -  /// Do an LV computation for, ultimately, a non-type declaration
>>> -  /// that already has some sort of explicit visibility.  Visibility
>>> -  /// may only be restricted by the visibility of template arguments.
>>> -  LVForExplicitValue = (LVForValue | IgnoreExplicitVisibilityBit),
>>> -
>>> -  /// Do an LV computation when we only care about the linkage.
>>> -  LVForLinkageOnly =
>>> -  LVForValue | IgnoreExplicitVisibilityBit | IgnoreAllVisibilityBit
>>> -};
>>> -
>>>  /// Does this computation kind permit us to consider additional
>>>  /// visibility settings from attributes and the like?
>>>  static bool 

[PATCH] D35743: [clang-format] Handle Structured binding declaration in C++17

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110640.
yawanng added a comment.

Show full context.


https://reviews.llvm.org/D35743

Files:
  lib/Format/TokenAnnotator.cpp
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11085,6 +11085,41 @@
   EXPECT_EQ("auto c = u8'a';", format("auto c = u8'a';"));
 }
 
+TEST_F(FormatTest, StructuredBindingDeclaration) {
+  // structured-binding-declaration is a C++17 feature.
+  EXPECT_EQ("auto [x, y] = a;", format("auto[x, y] = a;"));
+  EXPECT_EQ("auto &[x, y] = a;", format("auto   &   [x, y] = a;"));
+  EXPECT_EQ("auto &&[x, y] = a;", format("auto &&   [x, y] = a;"));
+  EXPECT_EQ("auto &&[x, y] = a;", format("auto &&   [x, y] = a;"));
+  EXPECT_EQ("auto [x] = a;", format("auto[x] = a;"));
+  EXPECT_EQ("auto &[x] = a;", format("auto   &   [x] = a;"));
+  EXPECT_EQ("auto &&[x] = a;", format("auto &&   [x] = a;"));
+  EXPECT_EQ("const auto [x, y] = f();", format("const auto[x, y] = f();"));
+  EXPECT_EQ("const auto &[x, y] = f();", format("const auto  &   [x, y] = f();"));
+  EXPECT_EQ("const auto &&[x, y] = f();", format("const auto  &&   [x, y] = f();"));
+  EXPECT_EQ("auto [x, y] = A{};", format("auto[x,y] = A{};"));
+  EXPECT_EQ("auto &[x, y] = A{};", format("auto   &   [x,y] = A{};"));
+  EXPECT_EQ("auto &&[x, y] = A{};", format("auto   &&   [x,y] = A{};"));
+  EXPECT_EQ("for (const auto &&[a, b] : some_range) {\n"
+"}",
+format("for (const auto   &&   [a, b] : some_range) {\n"
+"}"));
+  EXPECT_EQ("for (const auto &[a, b] : some_range) {\n"
+"}",
+format("for (const auto   &   [a, b] : some_range) {\n"
+"}"));
+  EXPECT_EQ("for (const auto [a, b] : some_range) {\n"
+"}",
+format("for (const auto[a, b] : some_range) {\n"
+"}"));
+  EXPECT_EQ("auto [x, y](expr);", format("auto[x,y]  (expr);"));
+  EXPECT_EQ("auto &[x, y](expr);", format("auto   &   [x,y](expr);"));
+  EXPECT_EQ("auto &&[x, y](expr);", format("auto   &&   [x,y](expr);"));
+  EXPECT_EQ("auto [x, y]{expr};", format("auto[x,y] {expr};"));
+  EXPECT_EQ("auto &[x, y]{expr};", format("auto   &   [x,y]  {expr};"));
+  EXPECT_EQ("auto &&[x, y]{expr};", format("auto   &&   [x,y]  {expr};"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UnwrappedLineParser.h
===
--- lib/Format/UnwrappedLineParser.h
+++ lib/Format/UnwrappedLineParser.h
@@ -125,6 +125,7 @@
   bool eof() const;
   void nextToken();
   const FormatToken *getPreviousToken();
+  const FormatToken *getPrePreviousToken();
   void readToken();
 
   // Decides which comment tokens should be added to the current line and which
Index: lib/Format/UnwrappedLineParser.cpp
===
--- lib/Format/UnwrappedLineParser.cpp
+++ lib/Format/UnwrappedLineParser.cpp
@@ -1211,9 +1211,12 @@
 return false;
   }
   const FormatToken* Previous = getPreviousToken();
+  const FormatToken* PrePrevious = getPrePreviousToken();
   if (Previous &&
   (Previous->isOneOf(tok::identifier, tok::kw_operator, tok::kw_new,
- tok::kw_delete) ||
+ tok::kw_delete, tok::kw_auto) ||
+   (PrePrevious && Previous->isOneOf(tok::amp, tok::ampamp) &&
+PrePrevious->is(tok::kw_auto)) ||
Previous->closesScope() || Previous->isSimpleTypeSpecifier())) {
 nextToken();
 return false;
@@ -2306,6 +2309,12 @@
   return Line->Tokens.back().Tok;
 }
 
+const FormatToken *UnwrappedLineParser::getPrePreviousToken() {
+  if (!Line || Line->Tokens.size() < 2)
+return nullptr;
+  return std::prev(Line->Tokens.end(), 2)->Tok;
+}
+
 void UnwrappedLineParser::distributeComments(
 const SmallVectorImpl ,
 const FormatToken *NextTok) {
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -330,8 +330,15 @@
 (Contexts.back().CanBeExpression || Contexts.back().IsExpression ||
  Contexts.back().InTemplateArgument);
 
+bool CppStructuredBindingDecl =
+!CppArrayTemplates && Style.isCpp() && Parent &&
+(Parent->is(tok::kw_auto) ||
+ (Parent->isOneOf(tok::amp, tok::ampamp) &&
+  Parent->getPreviousNonComment() &&
+  Parent->getPreviousNonComment()->is(tok::kw_auto)));
+
 bool StartsObjCMethodExpr =
-!CppArrayTemplates && Style.isCpp() &&
+!CppStructuredBindingDecl && !CppArrayTemplates && Style.isCpp() &&
 Contexts.back().CanBeExpression && 

[clang-tools-extra] r310669 - [clang-tidy] Fix for buildbot.

[Yan Wang via cfe-commits]

Author: yawanng
Date: Thu Aug 10 15:09:22 2017
New Revision: 310669

URL: http://llvm.org/viewvc/llvm-project?rev=310669=rev
Log:
[clang-tidy] Fix for buildbot.

Summary:
Fix an issue for windows.

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

Added:
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-memfd-create.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-memfd-create.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310669=310668=310669=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Thu Aug 10 
15:09:22 2017
@@ -12,6 +12,7 @@
 #include "../ClangTidyModuleRegistry.h"
 #include "CloexecCreatCheck.h"
 #include "CloexecFopenCheck.h"
+#include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
 #include "CloexecSocketCheck.h"
 
@@ -27,6 +28,8 @@ public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
 CheckFactories.registerCheck("android-cloexec-creat");
 CheckFactories.registerCheck("android-cloexec-fopen");
+CheckFactories.registerCheck(
+"android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");
 CheckFactories.registerCheck("android-cloexec-socket");
   }

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310669=310668=310669=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Thu Aug 10 
15:09:22 2017
@@ -2,8 +2,10 @@ set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyAndroidModule
   AndroidTidyModule.cpp
+  CloexecCheck.cpp
   CloexecCreatCheck.cpp
   CloexecFopenCheck.cpp
+  CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp
   CloexecSocketCheck.cpp
 

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp?rev=310669=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp Thu Aug 10 
15:09:22 2017
@@ -0,0 +1,105 @@
+//===--- CloexecCheck.cpp - 
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecCheck.h"
+#include "../utils/ASTUtils.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+namespace {
+
+const char *const FuncDeclBindingStr = "funcDecl";
+const char *const FuncBindingStr = "func";
+
+// Helper function to form the correct string mode for Type3.
+// Build the replace text. If it's string constant, add  directly in the
+// end of the string. Else, add .
+std::string buildFixMsgForStringFlag(const Expr *Arg, const SourceManager ,
+ const LangOptions , char Mode) {
+  if (Arg->getLocStart().isMacroID())
+return (Lexer::getSourceText(
+CharSourceRange::getTokenRange(Arg->getSourceRange()), SM,
+LangOpts) +
+" \"" + Twine(Mode) + "\"")
+.str();
+
+  StringRef SR = cast(Arg->IgnoreParenCasts())->getString();
+  return ("\"" + SR + Twine(Mode) + "\"").str();
+}
+} // namespace
+
+void CloexecCheck::registerMatchersImpl(
+MatchFinder *Finder, internal::Matcher Function) {
+  // We assume all the checked APIs are C functions.
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(isExternC(), Function).bind(FuncDeclBindingStr)))
+  .bind(FuncBindingStr),
+  this);
+}
+
+void 

Re: r309569 - Fix -Wshadow false positives with function-local classes.

[Hans Wennborg via cfe-commits]

Should we merge this to 5.0?

On Mon, Jul 31, 2017 at 8:21 AM, Alexander Kornienko via cfe-commits
 wrote:
> Author: alexfh
> Date: Mon Jul 31 08:21:26 2017
> New Revision: 309569
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309569=rev
> Log:
> Fix -Wshadow false positives with function-local classes.
>
> Summary:
> Fixes http://llvm.org/PR33947.
>
> https://godbolt.org/g/54XRMT
>
> void f(int a) {
>   struct A {
> void g(int a) {}
> A() { int a; }
>   };
> }
>
> 3 : :3:16: warning: declaration shadows a local variable [-Wshadow]
> void g(int a) {}
>^
> 1 : :1:12: note: previous declaration is here
> void f(int a) {
>^
> 4 : :4:15: warning: declaration shadows a local variable [-Wshadow]
> A() { int a; }
>   ^
> 1 : :1:12: note: previous declaration is here
> void f(int a) {
>^
> 2 warnings generated.
>
> The local variable `a` of the function `f` can't be accessed from a method of
> the function-local class A, thus no shadowing occurs and no diagnostic is
> needed.
>
> Reviewers: rnk, rsmith, arphaman, Quuxplusone
>
> Reviewed By: rnk, Quuxplusone
>
> Subscribers: Quuxplusone, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D35941
>
> Modified:
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/SemaCXX/warn-shadow.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=309569=309568=309569=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Jul 31 08:21:26 2017
> @@ -6999,6 +6999,21 @@ void Sema::CheckShadow(NamedDecl *D, Nam
>return;
>  }
>}
> +
> +  if (cast(ShadowedDecl)->hasLocalStorage()) {
> +// A variable can't shadow a local variable in an enclosing scope, if
> +// they are separated by a non-capturing declaration context.
> +for (DeclContext *ParentDC = NewDC;
> + ParentDC && !ParentDC->Equals(OldDC);
> + ParentDC = getLambdaAwareParentOfDeclContext(ParentDC)) {
> +  // Only block literals, captured statements, and lambda expressions
> +  // can capture; other scopes don't.
> +  if (!isa(ParentDC) && !isa(ParentDC) &&
> +  !isLambdaCallOperator(ParentDC)) {
> +return;
> +  }
> +}
> +  }
>  }
>}
>
>
> Modified: cfe/trunk/test/SemaCXX/warn-shadow.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-shadow.cpp?rev=309569=309568=309569=diff
> ==
> --- cfe/trunk/test/SemaCXX/warn-shadow.cpp (original)
> +++ cfe/trunk/test/SemaCXX/warn-shadow.cpp Mon Jul 31 08:21:26 2017
> @@ -213,3 +213,12 @@ typedef int externC; // expected-note {{
>  void handleLinkageSpec() {
>typedef void externC; // expected-warning {{declaration shadows a typedef 
> in the global namespace}}
>  }
> +
> +namespace PR33947 {
> +void f(int a) {
> +  struct A {
> +void g(int a) {}
> +A() { int a; }
> +  };
> +}
> +}
>
>
> ___
> 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: [clang-tools-extra] r310630 - [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Reid Kleckner via cfe-commits]

I think on Linux overload resolution was selecting
'DiagnosticBuilder<<(DiagnosticBuilder,int)' for you, which is
probably not right anyway. I didn't find any tests for this diagnostic, so
I couldn't fix it, and ended up reverting the change in r310661.

On Thu, Aug 10, 2017 at 12:15 PM, Yan Wang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Yes. Sorry for the broken. But it works well in my Linux machine. Maybe I
> should revert it first.
>
> Thanks,
> Yan Wang
>
> On Thu, Aug 10, 2017 at 12:07 PM, Nico Weber  wrote:
>
>> Not sure if you've seen it, this broke the Windows build:
>> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/build
>> s/5880/steps/build%20stage%201/logs/stdio
>>
>> FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP
>> -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
>> -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE
>> -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0
>> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Itools\clang\tools\extra\clang-tidy\android
>> -ID:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\extra\clang-tidy\android
>> -ID:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include
>> -Itools\clang\include -Iinclude 
>> -ID:\buildslave\clang-x64-ninja-win7\llvm\include
>> /DWIN32 /D_WINDOWS   /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4
>> -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351
>> -wd4355 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800
>> -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706
>> -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091
>> -wd4592 -wd4319 -wd4324 -w14062 -we4238 /MD /O2 /Ob2   -UNDEBUG  /EHs-c-
>> /GR- /showIncludes /Fotools\clang\tools\extra\cla
>> ng-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\CloexecCheck.cpp.obj
>> /Fdtools\clang\tools\extra\clang-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\
>> /FS -c D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\ex
>> tra\clang-tidy\android\CloexecCheck.cpp
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\ex
>> tra\clang-tidy\android\CloexecCheck.cpp(99): error C2666:
>> 'clang::operator <<': 4 overloads have similar conversions
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2612):
>> note: could be 'llvm::raw_ostream ::operator <<(llvm::raw_ostream
>> &,const clang::ObjCImplementationDecl &)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2429):
>> note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
>> &,const clang::ObjCCategoryImplDecl &)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3698):
>> note: or   'const clang::PartialDiagnostic ::operator <<(const
>> clang::PartialDiagnostic &,clang::AccessSpecifier)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3695):
>> note: or   'const clang::DiagnosticBuilder ::operator <<(const
>> clang::DiagnosticBuilder &,clang::AccessSpecifier)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(202):
>> note: or   'const clang::PartialDiagnostic ::operator <<(const
>> clang::PartialDiagnostic &,const clang::Attr *)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(195):
>> note: or   'const clang::DiagnosticBuilder ::operator <<(const
>> clang::DiagnosticBuilder &,const clang::Attr *)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\
>> clang/Sema/CodeCompleteConsumer.h(802): note: or
>> 'llvm::raw_ostream ::operator <<(llvm::raw_ostream &,const
>> clang::CodeCompletionString &)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\
>> clang/AST/CanonicalType.h(204): note: or   'const
>> clang::DiagnosticBuilder ::operator <<(const clang::DiagnosticBuilder
>> &,clang::CanQualType)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/TemplateBase.h(646):
>> note: or   'const clang::DiagnosticBuilder ::operator <<(const
>> clang::DiagnosticBuilder &,const clang::TemplateArgument &)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3961):
>> note: or   'const clang::PartialDiagnostic ::operator <<(const
>> clang::PartialDiagnostic &,const clang::NamedDecl *)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3955):
>> note: or   'const clang::DiagnosticBuilder ::operator <<(const
>> clang::DiagnosticBuilder &,const clang::NamedDecl *)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(404):
>> note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
>> &,const clang::NamedDecl &)'
>> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Type.h(6024):

[clang-tools-extra] r310661 - Revert "[clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module."

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Thu Aug 10 14:21:15 2017
New Revision: 310661

URL: http://llvm.org/viewvc/llvm-project?rev=310661=rev
Log:
Revert "[clang-tidy] Refactor the code and add a close-on-exec check on 
memfd_create() in Android module."

This reverts commit r310630.

The new code broke on Windows and was untested. On Linux, it was
selecting the "int" overload of operator<<, which definitely does not
print the right thing when fed a "Mode" char.

Removed:
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-memfd-create.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-memfd-create.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310661=310660=310661=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Thu Aug 10 
14:21:15 2017
@@ -12,7 +12,6 @@
 #include "../ClangTidyModuleRegistry.h"
 #include "CloexecCreatCheck.h"
 #include "CloexecFopenCheck.h"
-#include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
 #include "CloexecSocketCheck.h"
 
@@ -28,8 +27,6 @@ public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
 CheckFactories.registerCheck("android-cloexec-creat");
 CheckFactories.registerCheck("android-cloexec-fopen");
-CheckFactories.registerCheck(
-"android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");
 CheckFactories.registerCheck("android-cloexec-socket");
   }

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310661=310660=310661=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Thu Aug 10 
14:21:15 2017
@@ -2,10 +2,8 @@ set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyAndroidModule
   AndroidTidyModule.cpp
-  CloexecCheck.cpp
   CloexecCreatCheck.cpp
   CloexecFopenCheck.cpp
-  CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp
   CloexecSocketCheck.cpp
 

Removed: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp?rev=310660=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (removed)
@@ -1,105 +0,0 @@
-//===--- CloexecCheck.cpp - 
clang-tidy-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "CloexecCheck.h"
-#include "../utils/ASTUtils.h"
-#include "clang/AST/ASTContext.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Lex/Lexer.h"
-
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-namespace android {
-
-namespace {
-
-const char *const FuncDeclBindingStr = "funcDecl";
-const char *const FuncBindingStr = "func";
-
-// Helper function to form the correct string mode for Type3.
-// Build the replace text. If it's string constant, add  directly in the
-// end of the string. Else, add .
-std::string buildFixMsgForStringFlag(const Expr *Arg, const SourceManager ,
- const LangOptions , char Mode) {
-  if (Arg->getLocStart().isMacroID())
-return (Lexer::getSourceText(
-CharSourceRange::getTokenRange(Arg->getSourceRange()), SM,
-LangOpts) +
-" \"" + Twine(Mode) + "\"")
-.str();
-
-  StringRef SR = cast(Arg->IgnoreParenCasts())->getString();
-  return ("\"" + SR + Twine(Mode) + "\"").str();
-}
-} // namespace
-
-void CloexecCheck::registerMatchersImpl(
-MatchFinder *Finder, internal::Matcher Function) {
-  // We assume all the checked APIs are C functions.
-  Finder->addMatcher(

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

[Hamza Sood via Phabricator via cfe-commits]

hamzasood added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

rjmccall wrote:
> hamzasood wrote:
> > rjmccall wrote:
> > > Shouldn't you only be accepting this in C++2a mode?
> > I'm not sure what the system is with allowing future language features as 
> > extensions, but I noticed that [*this] capture is allowed as an extension 
> > pre-C++17 so I figured it would make sense for [=, this] to also be allowed 
> > as an extension (since the proposal mentions how it's meant to increase 
> > code clarify in the presence of [*this]).
> Surely there should at least be an on-by-default extension warning?  The 
> behavior we're using sounds a lot more like we're treating this as a bug-fix 
> in the standard than a new feature.  Richard, can you weigh in here?
The extension warning for this (ext_equals_this_lambda_capture_cxx2a) is on by 
default.


https://reviews.llvm.org/D36572



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

Re: r310576 - [Lexer] Finding beginning of token with escaped new line

[Richard Smith via cfe-commits]

On 10 August 2017 at 03:06, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alexfh
> Date: Thu Aug 10 03:06:16 2017
> New Revision: 310576
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310576=rev
> Log:
> [Lexer] Finding beginning of token with escaped new line
>
> Summary:
> Lexer::GetBeginningOfToken produced invalid location when
> backtracking across escaped new lines.
>
> This fixes PR26228
>
> Reviewers: akyrtzi, alexfh, rsmith, doug.gregor
>
> Reviewed By: alexfh
>
> Subscribers: alexfh, cfe-commits
>
> Patch by Paweł Żukowski!
>
> Differential Revision: https://reviews.llvm.org/D30748
>
> Modified:
> cfe/trunk/include/clang/Lex/Lexer.h
> cfe/trunk/lib/Lex/Lexer.cpp
> cfe/trunk/unittests/Lex/LexerTest.cpp
>
> Modified: cfe/trunk/include/clang/Lex/Lexer.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Lex/Lexer.h?rev=310576=310575=310576=diff
> 
> ==
> --- cfe/trunk/include/clang/Lex/Lexer.h (original)
> +++ cfe/trunk/include/clang/Lex/Lexer.h Thu Aug 10 03:06:16 2017
> @@ -463,6 +463,10 @@ public:
>/// \brief Returns true if the given character could appear in an
> identifier.
>static bool isIdentifierBodyChar(char c, const LangOptions );
>
> +  /// \brief Checks whether new line pointed by Str is preceded by escape
> +  /// sequence.
> +  static bool isNewLineEscaped(const char *BufferStart, const char *Str);
> +
>/// getCharAndSizeNoWarn - Like the getCharAndSize method, but does not
> ever
>/// emit a warning.
>static inline char getCharAndSizeNoWarn(const char *Ptr, unsigned ,
>
> Modified: cfe/trunk/lib/Lex/Lexer.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/
> Lexer.cpp?rev=310576=310575=310576=diff
> 
> ==
> --- cfe/trunk/lib/Lex/Lexer.cpp (original)
> +++ cfe/trunk/lib/Lex/Lexer.cpp Thu Aug 10 03:06:16 2017
> @@ -463,19 +463,15 @@ static const char *findBeginningOfLine(S
>const char *BufStart = Buffer.data();
>if (Offset >= Buffer.size())
>  return nullptr;
> -  const char *StrData = BufStart + Offset;
>
> -  if (StrData[0] == '\n' || StrData[0] == '\r')
> -return StrData;
> -
> -  const char *LexStart = StrData;
> -  while (LexStart != BufStart) {
> -if (LexStart[0] == '\n' || LexStart[0] == '\r') {
> +  const char *LexStart = BufStart + Offset;
> +  for (; LexStart != BufStart; --LexStart) {
> +if (isVerticalWhitespace(LexStart[0]) &&
> +!Lexer::isNewLineEscaped(BufStart, LexStart)) {
> +  // LexStart should point at first character of logical line.
>++LexStart;
>break;
>  }
> -
> ---LexStart;
>}
>return LexStart;
>  }
> @@ -487,7 +483,7 @@ static SourceLocation getBeginningOfFile
>std::pair LocInfo = SM.getDecomposedLoc(Loc);
>if (LocInfo.first.isInvalid())
>  return Loc;
> -
> +
>bool Invalid = false;
>StringRef Buffer = SM.getBufferData(LocInfo.first, );
>if (Invalid)
> @@ -499,31 +495,31 @@ static SourceLocation getBeginningOfFile
>const char *LexStart = findBeginningOfLine(Buffer, LocInfo.second);
>if (!LexStart || LexStart == StrData)
>  return Loc;
> -
> +
>// Create a lexer starting at the beginning of this token.
>SourceLocation LexerStartLoc = Loc.getLocWithOffset(-LocInfo.second);
>Lexer TheLexer(LexerStartLoc, LangOpts, Buffer.data(), LexStart,
>   Buffer.end());
>TheLexer.SetCommentRetentionState(true);
> -
> +
>// Lex tokens until we find the token that contains the source location.
>Token TheTok;
>do {
>  TheLexer.LexFromRawLexer(TheTok);
> -
> +
>  if (TheLexer.getBufferLocation() > StrData) {
>// Lexing this token has taken the lexer past the source location
> we're
>// looking for. If the current token encompasses our source
> location,
>// return the beginning of that token.
>if (TheLexer.getBufferLocation() - TheTok.getLength() <= StrData)
>  return TheTok.getLocation();
> -
> +
>// We ended up skipping over the source location entirely, which
> means
>// that it points into whitespace. We're done here.
>break;
>  }
>} while (TheTok.getKind() != tok::eof);
> -
> +
>// We've passed our source location; just return the original source
> location.
>return Loc;
>  }
> @@ -531,20 +527,20 @@ static SourceLocation getBeginningOfFile
>  SourceLocation Lexer::GetBeginningOfToken(SourceLocation Loc,
>const SourceManager ,
>const LangOptions ) {
> - if (Loc.isFileID())
> -   return getBeginningOfFileToken(Loc, SM, LangOpts);
> -
> - if (!SM.isMacroArgExpansion(Loc))
> -   return Loc;
> -
> - SourceLocation FileLoc = SM.getSpellingLoc(Loc);
> - SourceLocation BeginFileLoc = 

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

hamzasood wrote:
> rjmccall wrote:
> > Shouldn't you only be accepting this in C++2a mode?
> I'm not sure what the system is with allowing future language features as 
> extensions, but I noticed that [*this] capture is allowed as an extension 
> pre-C++17 so I figured it would make sense for [=, this] to also be allowed 
> as an extension (since the proposal mentions how it's meant to increase code 
> clarify in the presence of [*this]).
Surely there should at least be an on-by-default extension warning?  The 
behavior we're using sounds a lot more like we're treating this as a bug-fix in 
the standard than a new feature.  Richard, can you weigh in here?


https://reviews.llvm.org/D36572



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

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[James Y Knight via Phabricator via cfe-commits]

jyknight added a comment.

In https://reviews.llvm.org/D34158#838454, @mibintc wrote:

> This patch is responding to @jyknight 's concern about preprocessed input. 
> The patch as it stands doesn't have this issue. I added 2 test cases, one 
> using option -x cpp-output, and another for a source file suffixed with .i
>
> Quoting James: "Firstly, let's consider a "clang foo.i" or "clang -x 
> cpp-output foo.c" compilation. In that case, it *clearly* should not be 
> including the predef file. I think the patch as it stands may not do this 
> properly. A test needs to be added for this to this patch, and perhaps the 
> behavior needs to be fixed as well."


Thanks for the test. It wasn't obvious from the code, so I'm glad to hear it 
was already correct. :)

Did you see the other suggestion I cleverly hid within a big block of 
commentary? "(TO FIX: We should be stripping the new arg as well: add 
"-fsystem-include-if-exists" argument to the list of include things in the 
skipArgs() function in lib/Driver/Job.cpp)"


https://reviews.llvm.org/D34158



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

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via cfe-commits]

+klimek@ who contributed the first version of clang-fuzzer.
We now have clang-proto-fuzzer
(see tools/clang/tools/clang-fuzzer/README.txt)
which shares code with clang-fuzzer, but which also depends on various
packages (protobufs, in particular).
clang-proto-fuzzer is off by default (requires a cmake flag) so these extra
deps don't hurt anyone,
but Nico's concern is that this way we pollute the main repo with code that
requires extra deps.

We could probably move the code to another repo (clang-tools-extra?) but my
concerns are:

* this is extra work, I don't want to do it "just in case". Only if it's a
common agreement that the change will improve the overall state enough to
spend this time.

* we need to keep clang-fuzzer together with clang-proto-fuzzer, they are
too close to have them separately.
But this will make clang-fuzzer even less used.  (Admittedly, the bugs
found by clang-fuzzer are not being fixed anyway)

WDYT?

--kcc





On Thu, Aug 10, 2017 at 12:32 PM, Nico Weber  wrote:

> On Thu, Aug 10, 2017 at 3:13 PM, Kostya Serebryany  wrote:
>
>>
>>
>> On Thu, Aug 10, 2017 at 12:01 PM, Nico Weber  wrote:
>>
>>> On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany 
>>> wrote:
>>>


 On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> I really believe this has way too many deps to live in the clang
> repro, as said on the review already.
>

 I don't have a very strong opinion here and would be happy to move if I
 see more support for Nico's opinion
 (I haven't seen it on the review, and you didn't object further, so we
 proceeded).
 Again, my rational is that the simpler it is to use the more likely
 other researchers will extend this work.

 BTW, I am going to commit a Dockerfile that will make experimenting
 with this trivial.
 My current (dirty) version looks like this. Not too much trouble.

 FROM ubuntu:16.04
 RUN apt-get update -y && apt-get install -y autoconf automake libtool
 curl make g++ unzip
 RUN apt-get install -y wget
 RUN apt-get install -y git binutils liblzma-dev libz-dev
 RUN apt-get install -y python-all
 RUN apt-get install -y cmake ninja-build
 RUN apt-get install -y subversion

 WORKDIR /root
 RUN wget -qO- https://github.com/google/prot
 obuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
 RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j
 $(nproc) && make check -j $(nproc) && make install && ldconfig
 RUN apt-get install -y pkg-config
 RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
 RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk
 clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
 RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-proje
 ct/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision |
 awk '{print $2}')
 RUN mkdir build0 && cd build0 && cmake -GNinja
 -DCMAKE_BUILD_TYPE=Release ../llvm && ninja
 RUN mkdir build1 && cd build1 && cmake -GNinja
 -DCMAKE_BUILD_TYPE=Release ../llvm -DLLVM_ENABLE_ASSERTIONS=ON
  -DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang
 -DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++
 -DLLVM_USE_SANITIZE_COVERAGE=YES -DLLVM_USE_SANITIZER=Address
 -DCLANG_ENABLE_PROTO_FUZZER=ON
 RUN cd build1 && ninja clang-fuzzer
 RUN cd build1 && ninja clang-proto-fuzzer
 #RUN cd build1 && ninja clang-proto-to-cxx



> Maybe this could live in clang-extra instead?
>

 clang-extra?

>>>
>>> clang-tools-extra, sorry.
>>>
>>>
 That's a separate repo, right?

>>>
>>> Yes.
>>>
>>>
 It may require more cmake trickery, and we'll also have to share  the
 clang-fuzzer-specific code between two repos.

>>>
>>> We could move the whole thing. I'd imagine that at most 3% of people who
>>> use clang will use this fuzzer, so having it elsewhere seems reasonable.
>>> (I'd imagine many more people to use clang-tidy for example, and that's in
>>> the other repro.)
>>>
>>
>> The clang-tidy argument doesn't work for me.
>> clang-tidy is a separate tool.
>> clang*fuzzer are ways to test clang, and so they have more reasons to
>> stay closer to clang (for the same reason that the clang tests stay with
>> clang).
>>
>
> Then think of the "[cfe-dev] Proposal for an ABI testsuite for clang"
> thread instead, which was about testing clang. We ended up putting that
> into a completely separate repo.
>
>
>
>
>>
>> --kcc
>>
>>
>>> Also see the "Contributing Extensions to Clang" section on
>>> http://clang.llvm.org/get_involved.html
>>>
>>>
 I do want the original clang-fuzzer to remain where it was, and both
 (clang-fuzzer and clang-proto-fuzzer) share the code.




>
> On Aug 8, 2017 

Re: r310605 - [Modules] Prevent #import to reenter header if not building a module.

[Richard Smith via cfe-commits]

On 10 August 2017 at 10:42, Hans Wennborg via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Sounds good to me.
>
> Richard, what do you think?
>
> On Thu, Aug 10, 2017 at 9:38 AM, Bruno Cardoso Lopes
>  wrote:
> > Hi Hans, can we please get this merged into 5.0?
> >
> > Thanks,
> >
> > On Thu, Aug 10, 2017 at 12:16 PM, Bruno Cardoso Lopes via cfe-commits
> >  wrote:
> >> Author: bruno
> >> Date: Thu Aug 10 08:16:24 2017
> >> New Revision: 310605
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=310605=rev
> >> Log:
> >> [Modules] Prevent #import to reenter header if not building a module.
> >>
> >> When non-modular headers are imported while not building a module but
> >> in -fmodules mode, be conservative and preserve the default #import
> >> semantic: do not reenter headers.
>

This comment doesn't appear to describe what this patch does: even when
building a module it does not re-enter headers except for ones declared
'textual header' within the module being built. (isCompilingModuleHeader
doesn't mean "are we compiling a module header right now?", it means "is
this file declared as some kind of header within the current
CompilingModule?".)

I'm nervous about taking this change: it will presumably break some cases
(particularly with local submodule visibility enabled) where a #pragma once
header is #included into multiple headers in the same module, by refusing
to re-enter such headers -- and it will fix other such cases, depending on
what exactly the header does and the structure of the module.

If this were restricted to the case where we're not building a module
(!LangOpts.isCompilingModule()), then I'd be OK putting it on the branch.

>>
> >> rdar://problem/33745031
> >>
> >> Added:
> >> cfe/trunk/test/Modules/Inputs/import-textual/x.h
> >> cfe/trunk/test/Modules/import-textual-nomodules.m
> >> Modified:
> >> cfe/trunk/lib/Lex/HeaderSearch.cpp
> >>
> >> Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/
> HeaderSearch.cpp?rev=310605=310604=310605=diff
> >> 
> ==
> >> --- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
> >> +++ cfe/trunk/lib/Lex/HeaderSearch.cpp Thu Aug 10 08:16:24 2017
> >> @@ -1143,7 +1143,7 @@ bool HeaderSearch::ShouldEnterIncludeFil
> >>  // headers find in the wild might rely only on #import and do not
> contain
> >>  // controlling macros, be conservative and only try to enter
> textual headers
> >>  // if such macro is present.
> >> -if (!FileInfo.isModuleHeader &&
> >> +if (FileInfo.isCompilingModuleHeader && !FileInfo.isModuleHeader
> &&
> >>  FileInfo.getControllingMacro(ExternalLookup))
> >>TryEnterHdr = true;
> >>  return TryEnterHdr;
> >>
> >> Added: cfe/trunk/test/Modules/Inputs/import-textual/x.h
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/Inputs/import-textual/x.h?rev=310605=auto
> >> 
> ==
> >> --- cfe/trunk/test/Modules/Inputs/import-textual/x.h (added)
> >> +++ cfe/trunk/test/Modules/Inputs/import-textual/x.h Thu Aug 10
> 08:16:24 2017
> >> @@ -0,0 +1,6 @@
> >> +#ifndef RANDOM_DEP
> >> +
> >> +@interface X
> >> +@end
> >> +
> >> +#endif // RANDOM_DEP
> >>
> >> Added: cfe/trunk/test/Modules/import-textual-nomodules.m
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/import-textual-nomodules.m?rev=310605=auto
> >> 
> ==
> >> --- cfe/trunk/test/Modules/import-textual-nomodules.m (added)
> >> +++ cfe/trunk/test/Modules/import-textual-nomodules.m Thu Aug 10
> 08:16:24 2017
> >> @@ -0,0 +1,8 @@
> >> +// RUN: rm -rf %t
> >> +// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps
> -I%S/Inputs/import-textual -fmodules-cache-path=%t %s -verify
> >> +
> >> +// expected-no-diagnostics
> >> +
> >> +#import "x.h"
> >> +#import "x.h"
> >> +
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> >
> > --
> > Bruno Cardoso Lopes
> > http://www.brunocardoso.cc
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

[Hamza Sood via Phabricator via cfe-commits]

hamzasood added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

rjmccall wrote:
> Shouldn't you only be accepting this in C++2a mode?
I'm not sure what the system is with allowing future language features as 
extensions, but I noticed that [*this] capture is allowed as an extension 
pre-C++17 so I figured it would make sense for [=, this] to also be allowed as 
an extension (since the proposal mentions how it's meant to increase code 
clarify in the presence of [*this]).


https://reviews.llvm.org/D36572



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

[PATCH] D35449: [X86] Implement __builtin_cpu_is

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL310657: [X86] Implement __builtin_cpu_is (authored by 
ctopper).

Changed prior to commit:
  https://reviews.llvm.org/D35449?vs=106751=110629#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35449

Files:
  cfe/trunk/include/clang/Basic/BuiltinsX86.def
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/include/clang/Basic/TargetInfo.h
  cfe/trunk/lib/Basic/Targets/X86.cpp
  cfe/trunk/lib/Basic/Targets/X86.h
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/CodeGen/builtin-cpu-is.c
  cfe/trunk/test/CodeGen/target-builtin-noerror.c
  cfe/trunk/test/Sema/builtin-cpu-supports.c

Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -1841,6 +1841,26 @@
   return false;
 }
 
+/// SemaBuiltinCpuIs - Handle __builtin_cpu_is(char *).
+/// This checks that the target supports __builtin_cpu_is and
+/// that the string argument is constant and valid.
+static bool SemaBuiltinCpuIs(Sema , CallExpr *TheCall) {
+  Expr *Arg = TheCall->getArg(0);
+
+  // Check if the argument is a string literal.
+  if (!isa(Arg->IgnoreParenImpCasts()))
+return S.Diag(TheCall->getLocStart(), diag::err_expr_not_string_literal)
+   << Arg->getSourceRange();
+
+  // Check the contents of the string.
+  StringRef Feature =
+  cast(Arg->IgnoreParenImpCasts())->getString();
+  if (!S.Context.getTargetInfo().validateCpuIs(Feature))
+return S.Diag(TheCall->getLocStart(), diag::err_invalid_cpu_is)
+   << Arg->getSourceRange();
+  return false;
+}
+
 // Check if the rounding mode is legal.
 bool Sema::CheckX86BuiltinRoundingOrSAE(unsigned BuiltinID, CallExpr *TheCall) {
   // Indicates if this instruction has rounding control or just SAE.
@@ -2154,6 +2174,9 @@
   if (BuiltinID == X86::BI__builtin_cpu_supports)
 return SemaBuiltinCpuSupports(*this, TheCall);
 
+  if (BuiltinID == X86::BI__builtin_cpu_is)
+return SemaBuiltinCpuIs(*this, TheCall);
+
   // If the intrinsic has rounding or SAE make sure its valid.
   if (CheckX86BuiltinRoundingOrSAE(BuiltinID, TheCall))
 return true;
Index: cfe/trunk/lib/Basic/Targets/X86.h
===
--- cfe/trunk/lib/Basic/Targets/X86.h
+++ cfe/trunk/lib/Basic/Targets/X86.h
@@ -382,6 +382,8 @@
 
   bool validateCpuSupports(StringRef Name) const override;
 
+  bool validateCpuIs(StringRef Name) const override;
+
   bool validateAsmConstraint(const char *,
  TargetInfo::ConstraintInfo ) const override;
 
Index: cfe/trunk/lib/Basic/Targets/X86.cpp
===
--- cfe/trunk/lib/Basic/Targets/X86.cpp
+++ cfe/trunk/lib/Basic/Targets/X86.cpp
@@ -1307,6 +1307,44 @@
   .Default(false);
 }
 
+// We can't use a generic validation scheme for the cpus accepted here
+// versus subtarget cpus accepted in the target attribute because the
+// variables intitialized by the runtime only support the below currently
+// rather than the full range of cpus.
+bool X86TargetInfo::validateCpuIs(StringRef FeatureStr) const {
+  return llvm::StringSwitch(FeatureStr)
+  .Case("amd", true)
+  .Case("amdfam10h", true)
+  .Case("amdfam15h", true)
+  .Case("atom", true)
+  .Case("barcelona", true)
+  .Case("bdver1", true)
+  .Case("bdver2", true)
+  .Case("bdver3", true)
+  .Case("bdver4", true)
+  .Case("bonnell", true)
+  .Case("broadwell", true)
+  .Case("btver1", true)
+  .Case("btver2", true)
+  .Case("core2", true)
+  .Case("corei7", true)
+  .Case("haswell", true)
+  .Case("intel", true)
+  .Case("istanbul", true)
+  .Case("ivybridge", true)
+  .Case("knl", true)
+  .Case("nehalem", true)
+  .Case("sandybridge", true)
+  .Case("shanghai", true)
+  .Case("silvermont", true)
+  .Case("skylake", true)
+  .Case("skylake-avx512", true)
+  .Case("slm", true)
+  .Case("westmere", true)
+  .Case("znver1", true)
+  .Default(false);
+}
+
 bool X86TargetInfo::validateAsmConstraint(
 const char *, TargetInfo::ConstraintInfo ) const {
   switch (*Name) {
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -7287,8 +7287,125 @@
   return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
 }
 
+static Value *EmitX86CpuIs(CodeGenFunction , const CallExpr *E) {
+  const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
+  StringRef CPUStr = cast(CPUExpr)->getString();
+
+  // This enum contains the vendor, type, and subtype enums from the
+  // runtime library concatenated together. The _START labels mark
+  // the start and are 

r310657 - [X86] Implement __builtin_cpu_is

[Craig Topper via cfe-commits]

Author: ctopper
Date: Thu Aug 10 13:28:30 2017
New Revision: 310657

URL: http://llvm.org/viewvc/llvm-project?rev=310657=rev
Log:
[X86] Implement __builtin_cpu_is

This patch adds support for __builtin_cpu_is. I've tried to match the strings 
supported to the latest version of gcc.

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

Added:
cfe/trunk/test/CodeGen/builtin-cpu-is.c   (with props)
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/CodeGen/target-builtin-noerror.c
cfe/trunk/test/Sema/builtin-cpu-supports.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=310657=310656=310657=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Thu Aug 10 13:28:30 2017
@@ -33,6 +33,7 @@
 // TODO: Make this somewhat generic so that other backends
 // can use it?
 BUILTIN(__builtin_cpu_supports, "bcC*", "nc")
+BUILTIN(__builtin_cpu_is, "bcC*", "nc")
 
 // Undefined Values
 //

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=310657=310656=310657=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Aug 10 13:28:30 
2017
@@ -583,6 +583,7 @@ def warn_redecl_library_builtin : Warnin
 def err_builtin_definition : Error<"definition of builtin function %0">;
 def err_arm_invalid_specialreg : Error<"invalid special register for builtin">;
 def err_invalid_cpu_supports : Error<"invalid cpu feature string for builtin">;
+def err_invalid_cpu_is : Error<"invalid cpu name for builtin">;
 def err_builtin_needs_feature : Error<"%0 needs target feature %1">;
 def err_function_needs_feature
 : Error<"always_inline function %1 requires target feature '%2', but would 
"

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=310657=310656=310657=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Thu Aug 10 13:28:30 2017
@@ -911,6 +911,10 @@ public:
   // argument.
   virtual bool validateCpuSupports(StringRef Name) const { return false; }
 
+  // \brief Validate the contents of the __builtin_cpu_is(const char*)
+  // argument.
+  virtual bool validateCpuIs(StringRef Name) const { return false; }
+
   // \brief Returns maximal number of args passed in registers.
   unsigned getRegParmMax() const {
 assert(RegParmMax < 7 && "RegParmMax value is larger than AST can handle");

Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=310657=310656=310657=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Thu Aug 10 13:28:30 2017
@@ -1307,6 +1307,44 @@ bool X86TargetInfo::validateCpuSupports(
   .Default(false);
 }
 
+// We can't use a generic validation scheme for the cpus accepted here
+// versus subtarget cpus accepted in the target attribute because the
+// variables intitialized by the runtime only support the below currently
+// rather than the full range of cpus.
+bool X86TargetInfo::validateCpuIs(StringRef FeatureStr) const {
+  return llvm::StringSwitch(FeatureStr)
+  .Case("amd", true)
+  .Case("amdfam10h", true)
+  .Case("amdfam15h", true)
+  .Case("atom", true)
+  .Case("barcelona", true)
+  .Case("bdver1", true)
+  .Case("bdver2", true)
+  .Case("bdver3", true)
+  .Case("bdver4", true)
+  .Case("bonnell", true)
+  .Case("broadwell", true)
+  .Case("btver1", true)
+  .Case("btver2", true)
+  .Case("core2", true)
+  .Case("corei7", true)
+  .Case("haswell", true)
+  .Case("intel", true)
+  .Case("istanbul", true)
+  .Case("ivybridge", true)
+  .Case("knl", true)
+  .Case("nehalem", true)
+  .Case("sandybridge", true)
+  .Case("shanghai", true)
+  .Case("silvermont", true)
+  .Case("skylake", true)
+  .Case("skylake-avx512", true)
+  .Case("slm", true)
+  .Case("westmere", true)
+  .Case("znver1", true)
+  .Default(false);
+}
+
 bool X86TargetInfo::validateAsmConstraint(
 const 

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 110627.
mibintc added a comment.

This patch is responding to @jyknight 's concern about preprocessed input. The 
patch as it stands doesn't have this issue. I added 2 test cases, one using 
option -x cpp-output, and another for a source file suffixed with .i

Quoting James: "Firstly, let's consider a "clang foo.i" or "clang -x cpp-output 
foo.c" compilation. In that case, it *clearly* should not be including the 
predef file. I think the patch as it stands may not do this properly. A test 
needs to be added for this to this patch, and perhaps the behavior needs to be 
fixed as well."


https://reviews.llvm.org/D34158

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Lex/PreprocessorOptions.h
  lib/Driver/ToolChains/Linux.cpp
  lib/Driver/ToolChains/Linux.h
  lib/Frontend/CompilerInvocation.cpp
  lib/Frontend/InitPreprocessor.cpp
  test/Driver/Inputs/stdc-predef/usr/include/stdc-predef.h
  test/Driver/clang_cpp.c
  test/Driver/crash-report-header.h
  test/Driver/crash-report-spaces.c
  test/Driver/crash-report.c
  test/Driver/rewrite-legacy-objc.m
  test/Driver/rewrite-map-in-diagnostics.c
  test/Driver/rewrite-objc.m
  test/Driver/stdc-predef.c
  test/Driver/stdc-predef.i
  test/Index/IBOutletCollection.m
  test/Index/annotate-macro-args.m
  test/Index/annotate-tokens-pp.c
  test/Index/annotate-tokens.c
  test/Index/c-index-getCursor-test.m
  test/Index/get-cursor-macro-args.m
  test/Index/get-cursor.cpp
  test/Preprocessor/ignore-pragmas.c
  unittests/Tooling/TestVisitor.h

Index: lib/Driver/ToolChains/Linux.h
===
--- lib/Driver/ToolChains/Linux.h
+++ lib/Driver/ToolChains/Linux.h
@@ -31,6 +31,8 @@
   void addLibStdCxxIncludePaths(
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
+  void AddGnuIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const;
   void AddCudaIncludeArgs(const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
   void AddIAMCUIncludeArgs(const llvm::opt::ArgList ,
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -705,6 +705,8 @@
   addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/include");
 
   addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include");
+
+  AddGnuIncludeArgs(DriverArgs, CC1Args);
 }
 
 static std::string DetectLibcxxIncludePath(StringRef base) {
@@ -743,6 +745,17 @@
   return "";
 }
 
+void Linux::AddGnuIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const {
+  if (!DriverArgs.hasArg(options::OPT_ffreestanding)) {
+// For gcc compatibility, clang will preinclude 
+// -ffreestanding suppresses this behavior.
+CC1Args.push_back("-fsystem-include-if-exists");
+CC1Args.push_back("stdc-predef.h");
+  }
+}
+
+
 void Linux::addLibStdCxxIncludePaths(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) const {
   // We need a detected GCC installation on Linux to provide libstdc++'s
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2517,6 +2517,10 @@
   for (const Arg *A : Args.filtered(OPT_chain_include))
 Opts.ChainedIncludes.emplace_back(A->getValue());
 
+  // Add the ordered list of -fsystem-include-if-exists.
+  for (const Arg *A : Args.filtered(OPT_fsystem_include_if_exists))
+Opts.FSystemIncludeIfExists.emplace_back(A->getValue());
+
   for (const Arg *A : Args.filtered(OPT_remap_file)) {
 std::pair Split = StringRef(A->getValue()).split(';');
 
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -70,6 +70,15 @@
   Builder.append(Twine("#include \"") + File + "\"");
 }
 
+/// AddImplicitSystemIncludeIfExists - Add an implicit system \#include of the 
+/// specified file to the predefines buffer: precheck with __has_include.
+static void AddImplicitSystemIncludeIfExists(MacroBuilder , 
+ StringRef File) {
+  Builder.append(Twine("#if __has_include( <") + File + ">)");
+  Builder.append(Twine("#include <") + File + ">");
+  Builder.append(Twine("#endif"));
+}
+
 static void AddImplicitIncludeMacros(MacroBuilder , StringRef File) {
   Builder.append(Twine("#__include_macros \"") + File + "\"");
   // Marker token to stop the __include_macros fetch loop.
@@ -1104,6 +1113,13 @@
   // Exit the command line and go back to  (2 is LC_LEAVE).
   if (!PP.getLangOpts().AsmPreprocessor)
 Builder.append("# 1 \"\" 2");
+  
+  // Process 

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

Shouldn't you only be accepting this in C++2a mode?


https://reviews.llvm.org/D36572



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

[PATCH] D36567: [Bash-autocompletion] Add --autocomplete flag to 5.0 release notes

[Raphael Isemann via Phabricator via cfe-commits]

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

LGTM, more publicity means that more shells will make use of it.


https://reviews.llvm.org/D36567



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

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Nico Weber via cfe-commits]

On Thu, Aug 10, 2017 at 3:13 PM, Kostya Serebryany  wrote:

>
>
> On Thu, Aug 10, 2017 at 12:01 PM, Nico Weber  wrote:
>
>> On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 I really believe this has way too many deps to live in the clang repro,
 as said on the review already.

>>>
>>> I don't have a very strong opinion here and would be happy to move if I
>>> see more support for Nico's opinion
>>> (I haven't seen it on the review, and you didn't object further, so we
>>> proceeded).
>>> Again, my rational is that the simpler it is to use the more likely
>>> other researchers will extend this work.
>>>
>>> BTW, I am going to commit a Dockerfile that will make experimenting with
>>> this trivial.
>>> My current (dirty) version looks like this. Not too much trouble.
>>>
>>> FROM ubuntu:16.04
>>> RUN apt-get update -y && apt-get install -y autoconf automake libtool
>>> curl make g++ unzip
>>> RUN apt-get install -y wget
>>> RUN apt-get install -y git binutils liblzma-dev libz-dev
>>> RUN apt-get install -y python-all
>>> RUN apt-get install -y cmake ninja-build
>>> RUN apt-get install -y subversion
>>>
>>> WORKDIR /root
>>> RUN wget -qO- https://github.com/google/prot
>>> obuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
>>> RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc)
>>> && make check -j $(nproc) && make install && ldconfig
>>> RUN apt-get install -y pkg-config
>>> RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
>>> RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk
>>> clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
>>> RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-proje
>>> ct/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision |
>>> awk '{print $2}')
>>> RUN mkdir build0 && cd build0 && cmake -GNinja
>>> -DCMAKE_BUILD_TYPE=Release ../llvm && ninja
>>> RUN mkdir build1 && cd build1 && cmake -GNinja
>>> -DCMAKE_BUILD_TYPE=Release ../llvm -DLLVM_ENABLE_ASSERTIONS=ON
>>>  -DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang
>>> -DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++
>>> -DLLVM_USE_SANITIZE_COVERAGE=YES -DLLVM_USE_SANITIZER=Address
>>> -DCLANG_ENABLE_PROTO_FUZZER=ON
>>> RUN cd build1 && ninja clang-fuzzer
>>> RUN cd build1 && ninja clang-proto-fuzzer
>>> #RUN cd build1 && ninja clang-proto-to-cxx
>>>
>>>
>>>
 Maybe this could live in clang-extra instead?

>>>
>>> clang-extra?
>>>
>>
>> clang-tools-extra, sorry.
>>
>>
>>> That's a separate repo, right?
>>>
>>
>> Yes.
>>
>>
>>> It may require more cmake trickery, and we'll also have to share  the
>>> clang-fuzzer-specific code between two repos.
>>>
>>
>> We could move the whole thing. I'd imagine that at most 3% of people who
>> use clang will use this fuzzer, so having it elsewhere seems reasonable.
>> (I'd imagine many more people to use clang-tidy for example, and that's in
>> the other repro.)
>>
>
> The clang-tidy argument doesn't work for me.
> clang-tidy is a separate tool.
> clang*fuzzer are ways to test clang, and so they have more reasons to stay
> closer to clang (for the same reason that the clang tests stay with clang).
>

Then think of the "[cfe-dev] Proposal for an ABI testsuite for clang"
thread instead, which was about testing clang. We ended up putting that
into a completely separate repo.




>
> --kcc
>
>
>> Also see the "Contributing Extensions to Clang" section on
>> http://clang.llvm.org/get_involved.html
>>
>>
>>> I do want the original clang-fuzzer to remain where it was, and both
>>> (clang-fuzzer and clang-proto-fuzzer) share the code.
>>>
>>>
>>>
>>>

 On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
 cfe-commits@lists.llvm.org> wrote:

> Author: morehouse
> Date: Tue Aug  8 13:15:04 2017
> New Revision: 310408
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
> Log:
> Integrate Kostya's clang-proto-fuzzer with LLVM.
>
> Summary:
> The clang-proto-fuzzer models a subset of C++ as a protobuf and
> uses libprotobuf-mutator to generate interesting mutations of C++
> programs.  Clang-proto-fuzzer has already found several bugs in
> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
> https://bugs.llvm.org/show_bug.cgi?id=33749).
>
> As with clang-fuzzer, clang-proto-fuzzer requires the following
> cmake flags:
> - CMAKE_C_COMPILER=clang
> - CMAKE_CXX_COMPILER=clang++
> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>
> In addition, clang-proto-fuzzer requires:
> - CLANG_ENABLE_PROTO_FUZZER=ON
>
> clang-proto-fuzzer also requires the following dependencies:
> - binutils  // needed for 

[PATCH] D36492: [RFC][time-report] Add preprocessor timer

[Michael Zolotukhin via Phabricator via cfe-commits]

mzolotukhin added a comment.

FWIW, I strongly support the idea of adding more detailed timers into the 
frontend. Thanks for working on it!
I probably won't be very helpful in reviewing this code, but I'd appreciate if 
you CC me in the future patches.

Thanks,
Michael


https://reviews.llvm.org/D36492



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

Re: [clang-tools-extra] r310630 - [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Yan Wang via cfe-commits]

Yes. Sorry for the broken. But it works well in my Linux machine. Maybe I
should revert it first.

Thanks,
Yan Wang

On Thu, Aug 10, 2017 at 12:07 PM, Nico Weber  wrote:

> Not sure if you've seen it, this broke the Windows build:
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/
> builds/5880/steps/build%20stage%201/logs/stdio
>
> FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP
> -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
> -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE
> -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools\clang\tools\extra\clang-tidy\android -ID:\buildslave\clang-x64-
> ninja-win7\llvm\tools\clang\tools\extra\clang-tidy\android
> -ID:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include
> -Itools\clang\include -Iinclude 
> -ID:\buildslave\clang-x64-ninja-win7\llvm\include
> /DWIN32 /D_WINDOWS   /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4
> -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351
> -wd4355 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800
> -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706
> -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091
> -wd4592 -wd4319 -wd4324 -w14062 -we4238 /MD /O2 /Ob2   -UNDEBUG  /EHs-c-
> /GR- /showIncludes /Fotools\clang\tools\extra\
> clang-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\CloexecCheck.cpp.obj
> /Fdtools\clang\tools\extra\clang-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\
> /FS -c D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\
> extra\clang-tidy\android\CloexecCheck.cpp
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\
> extra\clang-tidy\android\CloexecCheck.cpp(99): error C2666:
> 'clang::operator <<': 4 overloads have similar conversions
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2612):
> note: could be 'llvm::raw_ostream ::operator <<(llvm::raw_ostream
> &,const clang::ObjCImplementationDecl &)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2429):
> note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
> &,const clang::ObjCCategoryImplDecl &)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3698):
> note: or   'const clang::PartialDiagnostic ::operator <<(const
> clang::PartialDiagnostic &,clang::AccessSpecifier)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3695):
> note: or   'const clang::DiagnosticBuilder ::operator <<(const
> clang::DiagnosticBuilder &,clang::AccessSpecifier)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(202):
> note: or   'const clang::PartialDiagnostic ::operator <<(const
> clang::PartialDiagnostic &,const clang::Attr *)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(195):
> note: or   'const clang::DiagnosticBuilder ::operator <<(const
> clang::DiagnosticBuilder &,const clang::Attr *)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/Sema/CodeCompleteConsumer.h(802):
> note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
> &,const clang::CodeCompletionString &)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\
> clang/AST/CanonicalType.h(204): note: or   'const
> clang::DiagnosticBuilder ::operator <<(const clang::DiagnosticBuilder
> &,clang::CanQualType)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/TemplateBase.h(646):
> note: or   'const clang::DiagnosticBuilder ::operator <<(const
> clang::DiagnosticBuilder &,const clang::TemplateArgument &)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3961):
> note: or   'const clang::PartialDiagnostic ::operator <<(const
> clang::PartialDiagnostic &,const clang::NamedDecl *)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3955):
> note: or   'const clang::DiagnosticBuilder ::operator <<(const
> clang::DiagnosticBuilder &,const clang::NamedDecl *)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(404):
> note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
> &,const clang::NamedDecl &)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Type.h(6024):
> note: or   'const clang::PartialDiagnostic ::operator <<(const
> clang::PartialDiagnostic &,clang::QualType)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Type.h(6015):
> note: or   'const clang::DiagnosticBuilder ::operator <<(const
> clang::DiagnosticBuilder &,clang::QualType)'
> D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/TemplateName.h(309):
> note: or   

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via cfe-commits]

On Thu, Aug 10, 2017 at 12:01 PM, Nico Weber  wrote:

> On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany  wrote:
>
>>
>>
>> On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> I really believe this has way too many deps to live in the clang repro,
>>> as said on the review already.
>>>
>>
>> I don't have a very strong opinion here and would be happy to move if I
>> see more support for Nico's opinion
>> (I haven't seen it on the review, and you didn't object further, so we
>> proceeded).
>> Again, my rational is that the simpler it is to use the more likely other
>> researchers will extend this work.
>>
>> BTW, I am going to commit a Dockerfile that will make experimenting with
>> this trivial.
>> My current (dirty) version looks like this. Not too much trouble.
>>
>> FROM ubuntu:16.04
>> RUN apt-get update -y && apt-get install -y autoconf automake libtool
>> curl make g++ unzip
>> RUN apt-get install -y wget
>> RUN apt-get install -y git binutils liblzma-dev libz-dev
>> RUN apt-get install -y python-all
>> RUN apt-get install -y cmake ninja-build
>> RUN apt-get install -y subversion
>>
>> WORKDIR /root
>> RUN wget -qO- https://github.com/google/prot
>> obuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
>> RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc)
>> && make check -j $(nproc) && make install && ldconfig
>> RUN apt-get install -y pkg-config
>> RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
>> RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk
>> clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
>> RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-proje
>> ct/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision | awk
>> '{print $2}')
>> RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
>> ../llvm && ninja
>> RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
>> ../llvm -DLLVM_ENABLE_ASSERTIONS=ON  
>> -DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang
>> -DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++
>> -DLLVM_USE_SANITIZE_COVERAGE=YES -DLLVM_USE_SANITIZER=Address
>> -DCLANG_ENABLE_PROTO_FUZZER=ON
>> RUN cd build1 && ninja clang-fuzzer
>> RUN cd build1 && ninja clang-proto-fuzzer
>> #RUN cd build1 && ninja clang-proto-to-cxx
>>
>>
>>
>>> Maybe this could live in clang-extra instead?
>>>
>>
>> clang-extra?
>>
>
> clang-tools-extra, sorry.
>
>
>> That's a separate repo, right?
>>
>
> Yes.
>
>
>> It may require more cmake trickery, and we'll also have to share  the
>> clang-fuzzer-specific code between two repos.
>>
>
> We could move the whole thing. I'd imagine that at most 3% of people who
> use clang will use this fuzzer, so having it elsewhere seems reasonable.
> (I'd imagine many more people to use clang-tidy for example, and that's in
> the other repro.)
>

The clang-tidy argument doesn't work for me.
clang-tidy is a separate tool.
clang*fuzzer are ways to test clang, and so they have more reasons to stay
closer to clang (for the same reason that the clang tests stay with clang).

--kcc


> Also see the "Contributing Extensions to Clang" section on
> http://clang.llvm.org/get_involved.html
>
>
>> I do want the original clang-fuzzer to remain where it was, and both
>> (clang-fuzzer and clang-proto-fuzzer) share the code.
>>
>>
>>
>>
>>>
>>> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: morehouse
 Date: Tue Aug  8 13:15:04 2017
 New Revision: 310408

 URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
 Log:
 Integrate Kostya's clang-proto-fuzzer with LLVM.

 Summary:
 The clang-proto-fuzzer models a subset of C++ as a protobuf and
 uses libprotobuf-mutator to generate interesting mutations of C++
 programs.  Clang-proto-fuzzer has already found several bugs in
 Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
 https://bugs.llvm.org/show_bug.cgi?id=33749).

 As with clang-fuzzer, clang-proto-fuzzer requires the following
 cmake flags:
 - CMAKE_C_COMPILER=clang
 - CMAKE_CXX_COMPILER=clang++
 - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
 - LLVM_USE_SANITIZER=Address  // needed for libFuzzer

 In addition, clang-proto-fuzzer requires:
 - CLANG_ENABLE_PROTO_FUZZER=ON

 clang-proto-fuzzer also requires the following dependencies:
 - binutils  // needed for libprotobuf-mutator
 - liblzma-dev  // needed for libprotobuf-mutator
 - libz-dev  // needed for libprotobuf-mutator
 - docbook2x  // needed for libprotobuf-mutator
 - Recent version of protobuf [3.3.0 is known to work]

 A working version of libprotobuf-mutator will automatically be
 downloaded and built as an external project.

 Implementation of clang-proto-fuzzer provided by 

Re: [clang-tools-extra] r310630 - [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Nico Weber via cfe-commits]

Not sure if you've seen it, this broke the Windows build:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/5880/steps/build%20stage%201/logs/stdio

FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP
-DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE
-D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools\clang\tools\extra\clang-tidy\android
-ID:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\extra\clang-tidy\android
-ID:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include
-Itools\clang\include -Iinclude
-ID:\buildslave\clang-x64-ninja-win7\llvm\include /DWIN32 /D_WINDOWS
/Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146 -wd4180
-wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 -wd4456 -wd4457
-wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 -wd4512
-wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703
-wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4324
-w14062 -we4238 /MD /O2 /Ob2   -UNDEBUG  /EHs-c- /GR- /showIncludes
/Fotools\clang\tools\extra\clang-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\CloexecCheck.cpp.obj
/Fdtools\clang\tools\extra\clang-tidy\android\CMakeFiles\clangTidyAndroidModule.dir\
/FS -c
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\extra\clang-tidy\android\CloexecCheck.cpp
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\tools\extra\clang-tidy\android\CloexecCheck.cpp(99):
error C2666: 'clang::operator <<': 4 overloads have similar conversions
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2612):
note: could be 'llvm::raw_ostream ::operator <<(llvm::raw_ostream
&,const clang::ObjCImplementationDecl &)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclObjC.h(2429):
note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
&,const clang::ObjCCategoryImplDecl &)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3698):
note: or   'const clang::PartialDiagnostic ::operator <<(const
clang::PartialDiagnostic &,clang::AccessSpecifier)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/DeclCXX.h(3695):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,clang::AccessSpecifier)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(202):
note: or   'const clang::PartialDiagnostic ::operator <<(const
clang::PartialDiagnostic &,const clang::Attr *)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Attr.h(195):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,const clang::Attr *)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/Sema/CodeCompleteConsumer.h(802):
note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
&,const clang::CodeCompletionString &)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/CanonicalType.h(204):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,clang::CanQualType)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/TemplateBase.h(646):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,const clang::TemplateArgument &)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3961):
note: or   'const clang::PartialDiagnostic ::operator <<(const
clang::PartialDiagnostic &,const clang::NamedDecl *)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(3955):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,const clang::NamedDecl *)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Decl.h(404):
note: or   'llvm::raw_ostream ::operator <<(llvm::raw_ostream
&,const clang::NamedDecl &)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Type.h(6024):
note: or   'const clang::PartialDiagnostic ::operator <<(const
clang::PartialDiagnostic &,clang::QualType)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/Type.h(6015):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,clang::QualType)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/TemplateName.h(309):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,clang::TemplateName)'
D:\buildslave\clang-x64-ninja-win7\llvm\tools\clang\include\clang/AST/NestedNameSpecifier.h(507):
note: or   'const clang::DiagnosticBuilder ::operator <<(const
clang::DiagnosticBuilder &,clang::NestedNameSpecifier *)'

[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: lib/Sema/SemaDeclCXX.cpp:14024
+
+  if (OldFT->hasExtParameterInfos())
+for (unsigned I = 0, E = OldFT->getNumParams(); I != E; ++I)

ahatanak wrote:
> rjmccall wrote:
> > I think we generally encourage the uses of braces when the nested statement 
> > is this complex, even if it is technically a single statement.
> I assume you are suggesting using braces for the if statement, not the for 
> loop?
Yes, exactly.  This looks better, thank you.



Comment at: lib/Sema/SemaExpr.cpp:7251
+if (const auto *rhproto = dyn_cast(rhptee))
+  rhptee = S.removeNoEscapeFromFunctionProto(lhproto, rhproto);
+

ahatanak wrote:
> rjmccall wrote:
> > I think the right place to do this is probably mergeFunctionTypes.
> When we have the following conditional operator expression, what is the type 
> of the expression?
> 
> ```
> void func0(__attribute__((noescape)) int *a, int *b);
> void func1(int *a, __attribute__((noescape)) int *b);
> 
> c ? func0 : func1;
> ```
> 
> The standard says the type of each parameter in the composite parameter type 
> list is the composite type of the corresponding parameters of both functions, 
> so I guess mergeFunctionType should drop noescape from both parameters?
Yes, that sounds right.



Comment at: lib/Sema/SemaExpr.cpp:7199
+  const auto *ToProto = dyn_cast(ToType);
+  const auto *FromProto = dyn_cast(FromType);
+

getAs<>, please.



Comment at: lib/Sema/SemaExpr.cpp:7210
+  if (!FromProto->hasExtParameterInfos())
+return FromType;
+

There's a potential for an illegal conversion here if 
ToProto->hasExtParameterInfos().


https://reviews.llvm.org/D32210



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

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Nico Weber via cfe-commits]

On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany  wrote:

>
>
> On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> I really believe this has way too many deps to live in the clang repro,
>> as said on the review already.
>>
>
> I don't have a very strong opinion here and would be happy to move if I
> see more support for Nico's opinion
> (I haven't seen it on the review, and you didn't object further, so we
> proceeded).
> Again, my rational is that the simpler it is to use the more likely other
> researchers will extend this work.
>
> BTW, I am going to commit a Dockerfile that will make experimenting with
> this trivial.
> My current (dirty) version looks like this. Not too much trouble.
>
> FROM ubuntu:16.04
> RUN apt-get update -y && apt-get install -y autoconf automake libtool curl
> make g++ unzip
> RUN apt-get install -y wget
> RUN apt-get install -y git binutils liblzma-dev libz-dev
> RUN apt-get install -y python-all
> RUN apt-get install -y cmake ninja-build
> RUN apt-get install -y subversion
>
> WORKDIR /root
> RUN wget -qO- https://github.com/google/protobuf/releases/download/v3.
> 3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
> RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc)
> && make check -j $(nproc) && make install && ldconfig
> RUN apt-get install -y pkg-config
> RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
> RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk
> clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
> RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-
> project/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision |
> awk '{print $2}')
> RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
> ../llvm && ninja
> RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
> ../llvm -DLLVM_ENABLE_ASSERTIONS=ON  
> -DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang
> -DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++
> -DLLVM_USE_SANITIZE_COVERAGE=YES -DLLVM_USE_SANITIZER=Address
> -DCLANG_ENABLE_PROTO_FUZZER=ON
> RUN cd build1 && ninja clang-fuzzer
> RUN cd build1 && ninja clang-proto-fuzzer
> #RUN cd build1 && ninja clang-proto-to-cxx
>
>
>
>> Maybe this could live in clang-extra instead?
>>
>
> clang-extra?
>

clang-tools-extra, sorry.


> That's a separate repo, right?
>

Yes.


> It may require more cmake trickery, and we'll also have to share  the
> clang-fuzzer-specific code between two repos.
>

We could move the whole thing. I'd imagine that at most 3% of people who
use clang will use this fuzzer, so having it elsewhere seems reasonable.
(I'd imagine many more people to use clang-tidy for example, and that's in
the other repro.) Also see the "Contributing Extensions to Clang" section
on http://clang.llvm.org/get_involved.html


> I do want the original clang-fuzzer to remain where it was, and both
> (clang-fuzzer and clang-proto-fuzzer) share the code.
>
>
>
>
>>
>> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: morehouse
>>> Date: Tue Aug  8 13:15:04 2017
>>> New Revision: 310408
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
>>> Log:
>>> Integrate Kostya's clang-proto-fuzzer with LLVM.
>>>
>>> Summary:
>>> The clang-proto-fuzzer models a subset of C++ as a protobuf and
>>> uses libprotobuf-mutator to generate interesting mutations of C++
>>> programs.  Clang-proto-fuzzer has already found several bugs in
>>> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
>>> https://bugs.llvm.org/show_bug.cgi?id=33749).
>>>
>>> As with clang-fuzzer, clang-proto-fuzzer requires the following
>>> cmake flags:
>>> - CMAKE_C_COMPILER=clang
>>> - CMAKE_CXX_COMPILER=clang++
>>> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
>>> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>>>
>>> In addition, clang-proto-fuzzer requires:
>>> - CLANG_ENABLE_PROTO_FUZZER=ON
>>>
>>> clang-proto-fuzzer also requires the following dependencies:
>>> - binutils  // needed for libprotobuf-mutator
>>> - liblzma-dev  // needed for libprotobuf-mutator
>>> - libz-dev  // needed for libprotobuf-mutator
>>> - docbook2x  // needed for libprotobuf-mutator
>>> - Recent version of protobuf [3.3.0 is known to work]
>>>
>>> A working version of libprotobuf-mutator will automatically be
>>> downloaded and built as an external project.
>>>
>>> Implementation of clang-proto-fuzzer provided by Kostya
>>> Serebryany.
>>>
>>> https://bugs.llvm.org/show_bug.cgi?id=33829
>>>
>>> Reviewers: kcc, vitalybuka, bogner
>>>
>>> Reviewed By: kcc, vitalybuka
>>>
>>> Subscribers: thakis, mgorny, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D36324
>>>
>>> Added:
>>> cfe/trunk/cmake/modules/ProtobufMutator.cmake
>>> cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
>>> cfe/trunk/tools/clang-fuzzer/README.txt
>>>  

[PATCH] D36354: [clang-tidy] Implement type-based check for `gsl::owner`

[Jonas Toth via Phabricator via cfe-commits]

JonasToth updated this revision to Diff 110617.
JonasToth added a comment.

[Misc] remove unneccessary stuff


https://reviews.llvm.org/D36354

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
  clang-tidy/cppcoreguidelines/OwningMemoryCheck.h
  clang-tidy/utils/Matchers.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/cppcoreguidelines-owning-memory.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-owning-memory.cpp

Index: test/clang-tidy/cppcoreguidelines-owning-memory.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-owning-memory.cpp
@@ -0,0 +1,347 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-owning-memory %t
+
+namespace gsl {
+template 
+using owner = T;
+} // namespace gsl
+
+template 
+class unique_ptr {
+public:
+  unique_ptr(gsl::owner resource) : memory(resource) {}
+  unique_ptr(const unique_ptr &) = default;
+
+  ~unique_ptr() { delete memory; }
+
+private:
+  gsl::owner memory;
+};
+
+void takes_owner(gsl::owner owned_int) {
+}
+
+void takes_pointer(int *unowned_int) {
+}
+
+void takes_owner_and_more(int some_int, gsl::owner owned_int, float f) {
+}
+
+template 
+void takes_templated_owner(gsl::owner owned_T) {
+}
+
+gsl::owner returns_owner1() { return gsl::owner(new int(42)); } // Ok
+gsl::owner returns_owner2() { return new int(42); } // Ok
+
+int *returns_no_owner1() { return nullptr; }
+int *returns_no_owner2() {
+  return new int(42);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: returning an owner/resource from a function but not declaring it as one
+}
+int *returns_no_owner3() {
+  int *should_be_owner = new int(42);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non owner with a newly created owner/resource
+  return should_be_owner;
+}
+int *returns_no_owner4() {
+  gsl::owner owner = new int(42);
+  return owner;
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: returning an owner/resource from a function but not declaring it as one
+}
+
+unique_ptr returns_no_owner5() {
+  return unique_ptr(new int(42)); // Ok
+}
+
+/// FIXME CSA finds it, but the report is misleading.
+void csa_not_finding_leak() {
+  gsl::owner o1 = new int(42); // Ok
+
+  gsl::owner o2 = o1; // Ok
+  o2 = new int(45); // conceptual leak, the memory from o1 is now leaked, since its considered moved in the guideLINEs
+
+  delete o2;
+  // actual leak occurs here, its found, but mixed
+  delete o1;
+}
+
+void test_assignment_and_initialization() {
+  int stack_int1 = 15;
+  int stack_int2;
+
+  gsl::owner owned_int1 = _int1; // BAD
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing neither with an owner nor a recognized resource
+
+  gsl::owner owned_int2;
+  owned_int2 = _int2; // BAD since no owner, bad since uninitialized
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: assigning neither an owner nor a recognized resource
+
+  gsl::owner owned_int3 = new int(42); // Good
+  owned_int3 = nullptr; // Good
+
+  gsl::owner owned_int4(nullptr); // Ok
+  owned_int4 = new int(42); // Good
+
+  gsl::owner owned_int5 = owned_int3; // Good
+
+  gsl::owner owned_int6{nullptr}; // Ok
+  owned_int6 = owned_int4; // Good
+
+  // FIXME, flow analysis for the case of reassignment. Value must be released before
+  owned_int6 = owned_int3; // BAD, because reassignment without resource release
+
+  auto owned_int7 = returns_owner1(); // Bad, since typededuction eliminates the owner wrapper
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non owner with a newly created owner/resource
+  // CHECK-MESSAGES: [[@LINE-2]]:3: note: type deduction did not result in an owner
+
+  const auto owned_int8 = returns_owner2(); // Bad, since typededuction eliminates the owner wrapper
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non owner with a newly created owner/resource
+  // CHECK-MESSAGES: [[@LINE-2]]:3: note: type deduction did not result in an owner
+
+  gsl::owner owned_int9 = returns_owner1(); // Ok
+  int *unowned_int3 = returns_owner1(); // Bad
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non owner with a newly created owner/resource
+
+  gsl::owner owned_int10;
+  owned_int10 = returns_owner1(); // Ok
+
+  int *unowned_int4;
+  unowned_int4 = returns_owner1(); // Bad
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: assigning newly created owner/resource to non-owner
+
+  gsl::owner owned_int11 = returns_no_owner1(); // Bad since no owner
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing neither with an owner nor a recognized resource
+
+  gsl::owner owned_int12;
+  owned_int12 = returns_no_owner1(); // Bad since no owner
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: assigning neither an owner nor a recognized resource
+
+  int *unowned_int5 = returns_no_owner1(); // Ok
+  int *unowned_int6;
+  unowned_int6 = returns_no_owner1(); // Ok
+
+  int 

r310649 - Enable bunch of sanitizers on NetBSD/X86 and X86_64

[Kamil Rytarowski via cfe-commits]

Author: kamil
Date: Thu Aug 10 11:53:52 2017
New Revision: 310649

URL: http://llvm.org/viewvc/llvm-project?rev=310649=rev
Log:
Enable bunch of sanitizers on NetBSD/X86 and X86_64

Summary:
Enable more sanitizers:
 - i386 and amd64:
 * SanitizerKind::Vptr;
 * SanitizerKind::Leak;
 * SanitizerKind::SafeStack;
 * SanitizerKind::Function;

 - amd64 only:
 * SanitizerKind::Thread;

These sanitizers are in the process of upstreaming to LLVM projects.

Sponsored by 

Reviewers: joerg, dim, vitalybuka, kcc, filcab, fjricci

Reviewed By: vitalybuka

Subscribers: #sanitizers, cfe-commits

Tags: #sanitizers

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

Modified:
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/test/Driver/fsanitize.c

Modified: cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp?rev=310649=310648=310649=diff
==
--- cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp Thu Aug 10 11:53:52 2017
@@ -422,6 +422,13 @@ SanitizerMask NetBSD::getSupportedSaniti
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   if (IsX86 || IsX86_64) {
 Res |= SanitizerKind::Address;
+Res |= SanitizerKind::Function;
+Res |= SanitizerKind::Leak;
+Res |= SanitizerKind::SafeStack;
+Res |= SanitizerKind::Vptr;
+  }
+  if (IsX86_64) {
+Res |= SanitizerKind::Thread;
   }
   return Res;
 }

Modified: cfe/trunk/test/Driver/fsanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=310649=310648=310649=diff
==
--- cfe/trunk/test/Driver/fsanitize.c (original)
+++ cfe/trunk/test/Driver/fsanitize.c Thu Aug 10 11:53:52 2017
@@ -516,6 +516,29 @@
 // RUN: %clang -target x86_64-unknown-cloudabi -fsanitize=safe-stack %s -### 
2>&1 | FileCheck %s -check-prefix=SAFESTACK-CLOUDABI
 // SAFESTACK-CLOUDABI: "-fsanitize=safe-stack"
 
+// RUN: %clang -target i386--netbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s -check-prefix=ADDRESS-NETBSD
+// RUN: %clang -target x86_64--netbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s -check-prefix=ADDRESS-NETBSD
+// ADDRESS-NETBSD: "-fsanitize=address"
+
+// RUN: %clang -target i386--netbsd -fsanitize=vptr %s -### 2>&1 | FileCheck 
%s -check-prefix=VPTR-NETBSD
+// RUN: %clang -target x86_64--netbsd -fsanitize=vptr %s -### 2>&1 | FileCheck 
%s -check-prefix=VPTR-NETBSD
+// VPTR-NETBSD: "-fsanitize=vptr"
+
+// RUN: %clang -target i386--netbsd -fsanitize=safe-stack %s -### 2>&1 | 
FileCheck %s -check-prefix=SAFESTACK-NETBSD
+// RUN: %clang -target x86_64--netbsd -fsanitize=safe-stack %s -### 2>&1 | 
FileCheck %s -check-prefix=SAFESTACK-NETBSD
+// SAFESTACK-NETBSD: "-fsanitize=safe-stack"
+
+// RUN: %clang -target i386--netbsd -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-NETBSD
+// RUN: %clang -target x86_64--netbsd -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-NETBSD
+// FUNCTION-NETBSD: "-fsanitize=function"
+
+// RUN: %clang -target i386--netbsd -fsanitize=leak %s -### 2>&1 | FileCheck 
%s -check-prefix=LEAK-NETBSD
+// RUN: %clang -target x86_64--netbsd -fsanitize=leak %s -### 2>&1 | FileCheck 
%s -check-prefix=LEAK-NETBSD
+// LEAK-NETBSD: "-fsanitize=leak"
+
+// RUN: %clang -target x86_64--netbsd -fsanitize=thread %s -### 2>&1 | 
FileCheck %s -check-prefix=THREAD-NETBSD
+// THREAD-NETBSD: "-fsanitize=thread"
+
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function 
-fsanitize=undefined %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-FSAN-UBSAN-PS4
 // CHECK-FSAN-UBSAN-PS4: unsupported option '-fsanitize=function' for target 
'x86_64-scei-ps4'
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-FSAN-PS4


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

[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: lib/AST/ItaniumMangle.cpp:2700
+  if (FD->getParamDecl(I)->hasAttr())
+Out << "U8noescape";
 }

rjmccall wrote:
> This is not the right place to do this:
> 
> * It needs to be mangled in function types, not just on function 
> declarations.  It looks like the code here supporting pass_object_size just 
> gets this wrong.
> * We don't want to mangle this in top-level declarations because doing so 
> will make it more directly ABI-breaking to retroactively add this attribute 
> to a declaration.
> 
> Instead, you should handle it in mangleExtParameterInfo.  Because these 
> qualifiers are mangled in reverse alphabetical order, and "noescape" precedes 
> "ns_consumed", it should be the last thing tested for in that function.
Oh that's right. We should avoid breaking ABI when retroactively adding 
noescape.



Comment at: lib/Sema/SemaDeclCXX.cpp:14024
+
+  if (OldFT->hasExtParameterInfos())
+for (unsigned I = 0, E = OldFT->getNumParams(); I != E; ++I)

rjmccall wrote:
> I think we generally encourage the uses of braces when the nested statement 
> is this complex, even if it is technically a single statement.
I assume you are suggesting using braces for the if statement, not the for loop?



Comment at: lib/Sema/SemaDeclObjC.cpp:186
+oldDecl->hasAttr()) {
+  Diag(newDecl->getLocation(), diag::err_nsconsumed_attribute_mismatch);
+  Diag(oldDecl->getLocation(), diag::note_previous_decl) << "parameter";

rjmccall wrote:
> I know this is existing code, but you should probably at least warn about 
> ns_consumed mismatches here in non-ARC.
I made warn_nsconsumed_attribute_mismatch and 
warn_nsreturns_retained_attribute_mismatch warnings that get promoted to errors 
when ARC is enabled.



Comment at: lib/Sema/SemaExpr.cpp:7180
+  if (!FromType->hasExtParameterInfos())
+return FromType;
+

rjmccall wrote:
> So this function removes noescape attributes from FromType to match ToType, 
> but only if it's a legal conversion?  Maybe it would be more reasonable to 
> report an inability to convert in a more direct way, like by returning a null 
> type.
> 
> Also, I think you're much more likely to avoid implicitly stripping sugar if 
> you take both of these (or at least FromType?) as a QualType, and also return 
> a QualType.  Or you could pass the original QualType down separately and just 
> return that in the cases where you don't need to change anything.
Yes. that's correct. The original implementation of the function removed 
noescape attributes from FromType's parameters to match ToType, but only if 
doing so made it a legal conversion.

I made changes to have this function take and return QualType and return 
QualType() when noescape on parameters makes the conversion invalid.



Comment at: lib/Sema/SemaExpr.cpp:7251
+if (const auto *rhproto = dyn_cast(rhptee))
+  rhptee = S.removeNoEscapeFromFunctionProto(lhproto, rhproto);
+

rjmccall wrote:
> I think the right place to do this is probably mergeFunctionTypes.
When we have the following conditional operator expression, what is the type of 
the expression?

```
void func0(__attribute__((noescape)) int *a, int *b);
void func1(int *a, __attribute__((noescape)) int *b);

c ? func0 : func1;
```

The standard says the type of each parameter in the composite parameter type 
list is the composite type of the corresponding parameters of both functions, 
so I guess mergeFunctionType should drop noescape from both parameters?



Comment at: lib/Sema/SemaTemplate.cpp:5477
+  }
+}
+

rjmccall wrote:
> I think this is not the right place to be doing this; instead, we should be 
> applying a conversion to the argument expression in CheckTemplateArgument.  
> It looks like we already do that in C++17 mode, because C++17 broadened the 
> rules here to allow an arbitrary function conversion (among the other things 
> allowed by the "converted constant expression" rules, [temp.arg.nontype]p2).  
> We probably could just leave it at that, since earlier standards are (in 
> their infinite wisdom) stricter about type-matching here.  If that poses a 
> serious compatibility problem, the right fix is to modify the clause in 
> CheckTemplateArgument for non-type template parameters where it deals with 
> pointers, references, and member pointers to functions to specifically allow 
> this conversion.  But I'll note that we don't seem to be similarly generous 
> about noreturn.
I removed this code so that noescape is handled the same way noreturn is 
handled, which causes clang to complain about "S4<> e1;" in 
test/SemaObjCXX/noescape.mm when it is not compiling for c++17 or later.

Is that what you meant?


https://reviews.llvm.org/D32210



___

[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 110612.
ahatanak marked 6 inline comments as done.
ahatanak added a comment.

Address review comments.


https://reviews.llvm.org/D32210

Files:
  include/clang/AST/Type.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/AST/ItaniumMangle.cpp
  lib/AST/TypePrinter.cpp
  lib/CodeGen/CGCall.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaDeclObjC.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaType.cpp
  test/Analysis/retain-release.m
  test/CodeGenCXX/noescape.cpp
  test/CodeGenObjC/noescape.m
  test/Misc/ast-dump-attr.cpp
  test/Misc/pragma-attribute-supported-attributes-list.test
  test/Sema/noescape.c
  test/SemaObjC/arc-nsconsumed-errors.m
  test/SemaObjCXX/noescape.mm

Index: test/SemaObjCXX/noescape.mm
===
--- /dev/null
+++ test/SemaObjCXX/noescape.mm
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -std=c++1z %s
+
+typedef void (^BlockTy)();
+
+struct S {
+  int i;
+  void m();
+};
+
+void noescapeFunc0(id, __attribute__((noescape)) BlockTy);
+void noescapeFunc1(id, [[clang::noescape]] BlockTy);
+void noescapeFunc2(__attribute__((noescape)) int *); // expected-note {{previous declaration is here}}
+void noescapeFunc3(__attribute__((noescape)) id);
+void noescapeFunc4(__attribute__((noescape)) int &);
+void noescapeFunc2(int *); // expected-error {{conflicting types for 'noescapeFunc2'}}
+
+void invalidFunc0(int __attribute__((noescape))); // expected-warning {{'noescape' attribute only applies to pointer arguments}}
+void invalidFunc1(int __attribute__((noescape(0; // expected-error {{'noescape' attribute takes no arguments}}
+void invalidFunc2(int0 *__attribute__((noescape))); // expected-error {{use of undeclared identifier 'int0'; did you mean 'int'?}}
+void invalidFunc3(__attribute__((noescape)) int (S::*Ty)); // expected-warning {{'noescape' attribute only applies to pointer arguments}}
+void invalidFunc4(__attribute__((noescape)) void (S::*Ty)()); // expected-warning {{'noescape' attribute only applies to pointer arguments}}
+int __attribute__((noescape)) g; // expected-warning {{'noescape' attribute only applies to parameters}}
+
+struct S1 {
+  virtual void m0(int *__attribute__((noescape))); // expected-note {{parameter of overridden method is annotated with __attribute__((noescape))}}
+};
+
+struct S2 : S1 {
+  void m0(int *__attribute__((noescape))) override;
+};
+
+struct S3 : S1 {
+  void m0(int *) override; // expected-warning {{parameter of overriding method should be annotated with __attribute__((noescape))}}
+};
+
+__attribute__((objc_root_class))
+@interface C0
+-(void) m0:(int*)__attribute__((noescape)) p; // expected-note {{parameter of overridden method is annotated with __attribute__((noescape))}}
+@end
+
+@implementation C0
+-(void) m0:(int*)__attribute__((noescape)) p {}
+@end
+
+@interface C1 : C0
+-(void) m0:(int*)__attribute__((noescape)) p;
+@end
+
+@implementation C1 : C0
+-(void) m0:(int*)__attribute__((noescape)) p {}
+@end
+
+@interface C2 : C0
+-(void) m0:(int*) p; // expected-warning {{parameter of overriding method should be annotated with __attribute__((noescape))}}
+@end
+
+@implementation C2 : C0
+-(void) m0:(int*) p {}
+@end
+
+void func0(int *);
+void (*fnptr0)(int *);
+void (*fnptr1)(__attribute__((noescape)) int *);
+template struct S4 {};
+template struct S5 {};
+
+#if __cplusplus < 201406
+  // expected-note@-4 {{template parameter is declared here}}
+  // expected-note@-4 {{template parameter is declared here}}
+#endif
+
+void test0() {
+  fnptr0 = 
+  fnptr0 = 
+  fnptr1 =  // expected-error {{assigning to 'void (*)(__attribute__((noescape)) int *)' from incompatible type 'void (*)(int *)'}}
+  fnptr1 = 
+  S4<> e0;
+  S4<> e1;
+  S5<> ne0;
+
+#if __cplusplus < 201406
+  // expected-error@-4 {{non-type template argument of type 'void (*)(__attribute__((noescape)) int *)' cannot be converted to a value of type 'void (*)(int *)'}}
+  // expected-error@-4 {{non-type template argument of type 'void (*)(int *)' cannot be converted to a value of type 'void (*)(__attribute__((noescape)) int *)'}}
+#else
+  // expected-error@-6 {{value of type 'void (*)(int *)' is not implicitly convertible to 'void (*)(__attribute__((noescape)) int *)'}}
+#endif
+
+  S5<> ne1;
+}
Index: test/SemaObjC/arc-nsconsumed-errors.m
===
--- test/SemaObjC/arc-nsconsumed-errors.m
+++ test/SemaObjC/arc-nsconsumed-errors.m
@@ -1,6 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -verify -fblocks -triple x86_64-apple-darwin10.0.0 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -verify -fblocks -triple x86_64-apple-darwin10.0.0 -DOBJCARC %s
+// RUN: 

[clang-tools-extra] r310643 - [clang-tidy] Fix a buildbot.

[Yan Wang via cfe-commits]

Author: yawanng
Date: Thu Aug 10 11:19:40 2017
New Revision: 310643

URL: http://llvm.org/viewvc/llvm-project?rev=310643=rev
Log:
[clang-tidy] Fix a buildbot.

Fix format in ReleaseNotes.rst.


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

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=310643=310642=310643=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Thu Aug 10 11:19:40 2017
@@ -73,8 +73,8 @@ Improvements to clang-tidy
 - New `android-cloexec-memfd_create
 
`_
 check
 
-Checks if the required file flag ``MFD_CLOEXEC`` is present in the 
argument of
-  ``memfd_create()``.
+  Checks if the required file flag ``MFD_CLOEXEC`` is present in the argument
+  of ``memfd_create()``.
 
 - New `bugprone-integer-division
   
`_
 check


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

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via cfe-commits]

On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I really believe this has way too many deps to live in the clang repro, as
> said on the review already.
>

I don't have a very strong opinion here and would be happy to move if I see
more support for Nico's opinion
(I haven't seen it on the review, and you didn't object further, so we
proceeded).
Again, my rational is that the simpler it is to use the more likely other
researchers will extend this work.

BTW, I am going to commit a Dockerfile that will make experimenting with
this trivial.
My current (dirty) version looks like this. Not too much trouble.

FROM ubuntu:16.04
RUN apt-get update -y && apt-get install -y autoconf automake libtool curl
make g++ unzip
RUN apt-get install -y wget
RUN apt-get install -y git binutils liblzma-dev libz-dev
RUN apt-get install -y python-all
RUN apt-get install -y cmake ninja-build
RUN apt-get install -y subversion

WORKDIR /root
RUN wget -qO-
https://github.com/google/protobuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz
| tar zxf -
RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc) &&
make check -j $(nproc) && make install && ldconfig
RUN apt-get install -y pkg-config
RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk
clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
RUN cd llvm/projects && svn co
http://llvm.org/svn/llvm-project/compiler-rt/trunk clang -r $(cd ../ && svn
info | grep Revision | awk '{print $2}')
RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
../llvm && ninja
RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
../llvm -DLLVM_ENABLE_ASSERTIONS=ON
 -DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang
-DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++
-DLLVM_USE_SANITIZE_COVERAGE=YES -DLLVM_USE_SANITIZER=Address
-DCLANG_ENABLE_PROTO_FUZZER=ON
RUN cd build1 && ninja clang-fuzzer
RUN cd build1 && ninja clang-proto-fuzzer
#RUN cd build1 && ninja clang-proto-to-cxx



> Maybe this could live in clang-extra instead?
>

clang-extra?
That's a separate repo, right?
It may require more cmake trickery, and we'll also have to share  the
clang-fuzzer-specific code between two repos.
I do want the original clang-fuzzer to remain where it was, and both
(clang-fuzzer and clang-proto-fuzzer) share the code.




>
> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: morehouse
>> Date: Tue Aug  8 13:15:04 2017
>> New Revision: 310408
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
>> Log:
>> Integrate Kostya's clang-proto-fuzzer with LLVM.
>>
>> Summary:
>> The clang-proto-fuzzer models a subset of C++ as a protobuf and
>> uses libprotobuf-mutator to generate interesting mutations of C++
>> programs.  Clang-proto-fuzzer has already found several bugs in
>> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
>> https://bugs.llvm.org/show_bug.cgi?id=33749).
>>
>> As with clang-fuzzer, clang-proto-fuzzer requires the following
>> cmake flags:
>> - CMAKE_C_COMPILER=clang
>> - CMAKE_CXX_COMPILER=clang++
>> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
>> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>>
>> In addition, clang-proto-fuzzer requires:
>> - CLANG_ENABLE_PROTO_FUZZER=ON
>>
>> clang-proto-fuzzer also requires the following dependencies:
>> - binutils  // needed for libprotobuf-mutator
>> - liblzma-dev  // needed for libprotobuf-mutator
>> - libz-dev  // needed for libprotobuf-mutator
>> - docbook2x  // needed for libprotobuf-mutator
>> - Recent version of protobuf [3.3.0 is known to work]
>>
>> A working version of libprotobuf-mutator will automatically be
>> downloaded and built as an external project.
>>
>> Implementation of clang-proto-fuzzer provided by Kostya
>> Serebryany.
>>
>> https://bugs.llvm.org/show_bug.cgi?id=33829
>>
>> Reviewers: kcc, vitalybuka, bogner
>>
>> Reviewed By: kcc, vitalybuka
>>
>> Subscribers: thakis, mgorny, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D36324
>>
>> Added:
>> cfe/trunk/cmake/modules/ProtobufMutator.cmake
>> cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
>> cfe/trunk/tools/clang-fuzzer/README.txt
>> cfe/trunk/tools/clang-fuzzer/cxx_proto.proto
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
>> Modified:
>> 

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Matt Morehouse via cfe-commits]

+ Kostya

The project isn't built by default, so the dependencies aren't needed
unless you build the fuzzer specifically.

On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber  wrote:

> I really believe this has way too many deps to live in the clang repro, as
> said on the review already. Maybe this could live in clang-extra instead?
>
> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: morehouse
>> Date: Tue Aug  8 13:15:04 2017
>> New Revision: 310408
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
>> Log:
>> Integrate Kostya's clang-proto-fuzzer with LLVM.
>>
>> Summary:
>> The clang-proto-fuzzer models a subset of C++ as a protobuf and
>> uses libprotobuf-mutator to generate interesting mutations of C++
>> programs.  Clang-proto-fuzzer has already found several bugs in
>> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
>> https://bugs.llvm.org/show_bug.cgi?id=33749).
>>
>> As with clang-fuzzer, clang-proto-fuzzer requires the following
>> cmake flags:
>> - CMAKE_C_COMPILER=clang
>> - CMAKE_CXX_COMPILER=clang++
>> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
>> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>>
>> In addition, clang-proto-fuzzer requires:
>> - CLANG_ENABLE_PROTO_FUZZER=ON
>>
>> clang-proto-fuzzer also requires the following dependencies:
>> - binutils  // needed for libprotobuf-mutator
>> - liblzma-dev  // needed for libprotobuf-mutator
>> - libz-dev  // needed for libprotobuf-mutator
>> - docbook2x  // needed for libprotobuf-mutator
>> - Recent version of protobuf [3.3.0 is known to work]
>>
>> A working version of libprotobuf-mutator will automatically be
>> downloaded and built as an external project.
>>
>> Implementation of clang-proto-fuzzer provided by Kostya
>> Serebryany.
>>
>> https://bugs.llvm.org/show_bug.cgi?id=33829
>>
>> Reviewers: kcc, vitalybuka, bogner
>>
>> Reviewed By: kcc, vitalybuka
>>
>> Subscribers: thakis, mgorny, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D36324
>>
>> Added:
>> cfe/trunk/cmake/modules/ProtobufMutator.cmake
>> cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
>> cfe/trunk/tools/clang-fuzzer/README.txt
>> cfe/trunk/tools/clang-fuzzer/cxx_proto.proto
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
>> Modified:
>> cfe/trunk/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
>>
>> Modified: cfe/trunk/CMakeLists.txt
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt
>> ?rev=310408=310407=310408=diff
>> 
>> ==
>> --- cfe/trunk/CMakeLists.txt (original)
>> +++ cfe/trunk/CMakeLists.txt Tue Aug  8 13:15:04 2017
>> @@ -377,6 +377,8 @@ option(CLANG_ENABLE_STATIC_ANALYZER "Bui
>>  option(CLANG_ANALYZER_BUILD_Z3
>>"Build the static analyzer with the Z3 constraint manager." OFF)
>>
>> +option(CLANG_ENABLE_PROTO_FUZZER "Build Clang protobuf fuzzer." OFF)
>> +
>>  if(NOT CLANG_ENABLE_STATIC_ANALYZER AND (CLANG_ENABLE_ARCMT OR
>> CLANG_ANALYZER_BUILD_Z3))
>>message(FATAL_ERROR "Cannot disable static analyzer while enabling
>> ARCMT or Z3")
>>  endif()
>>
>> Added: cfe/trunk/cmake/modules/ProtobufMutator.cmake
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/
>> ProtobufMutator.cmake?rev=310408=auto
>> 
>> ==
>> --- cfe/trunk/cmake/modules/ProtobufMutator.cmake (added)
>> +++ cfe/trunk/cmake/modules/ProtobufMutator.cmake Tue Aug  8 13:15:04
>> 2017
>> @@ -0,0 +1,24 @@
>> +set(PBM_PREFIX protobuf_mutator)
>> +set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${
>> PBM_PREFIX}/src/${PBM_PREFIX})
>> +set(PBM_LIB_PATH ${PBM_PATH}/src/libprotobuf-mutator.a)
>> +set(PBM_FUZZ_LIB_PATH ${PBM_PATH}/src/libfuzzer/libp
>> rotobuf-mutator-libfuzzer.a)
>> +
>> +ExternalProject_Add(${PBM_PREFIX}
>> +  PREFIX ${PBM_PREFIX}
>> +  GIT_REPOSITORY https://github.com/google/libprotobuf-mutator.git
>> +  GIT_TAG 34287f8
>> +  CONFIGURE_COMMAND ${CMAKE_COMMAND} -G${CMAKE_GENERATOR}
>> +-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
>> +-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
>> +-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>> +  BUILD_COMMAND ${CMAKE_MAKE_PROGRAM}
>> +  BUILD_BYPRODUCTS ${PBM_LIB_PATH} ${PBM_FUZZ_LIB_PATH}
>> +  BUILD_IN_SOURCE 1
>> +  INSTALL_COMMAND ""
>> +  

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Aleksey Shlyapnikov via Phabricator via cfe-commits]

alekseyshl added a comment.

In https://reviews.llvm.org/D29660#838305, @alekseyshl wrote:

> In https://reviews.llvm.org/D29660#838219, @gtbercea wrote:
>
> > In https://reviews.llvm.org/D29660#838194, @arphaman wrote:
> >
> > > The failures were very widespread, e.g. there's a linux buildbot that was 
> > > red until the revert: http://bb.pgr.jp/builders/test-clang-i686-linux-RA. 
> > > If you have access to a linux machine you should be able to reproduce the 
> > > failures that the bot experienced by using the same cmake arguments (I 
> > > don't know the exact ones, but judging from the bot you should be able to 
> > > reproduce them using 32 bit release build with assertions enabled). I 
> > > don't know what GPU that buildbot has.
> >
> >
> > Thanks Alex, I will try to reproduce it locally.
> >
> > > I'll try to get the detailed test output for my local machine today as 
> > > well.
> >
> > Oh that would be great! Thanks a lot! :)
>
>
>
>
> In https://reviews.llvm.org/D29660#838262, @gtbercea wrote:
>
> > In https://reviews.llvm.org/D29660#838185, @alekseyshl wrote:
> >
> > > In https://reviews.llvm.org/D29660#838150, @gtbercea wrote:
> > >
> > > > First of all, I apologize if I've upset you with my previous post. I am 
> > > > actively working on understanding what is causing these issues. It is 
> > > > not my intention to write tests that work on local configurations only. 
> > > > I am upset to see that these tests keep failing for your and maybe 
> > > > other configurations. Without knowing the actual reason of the failures 
> > > > I can only speculate what is going wrong with them hence the flurry of 
> > > > changes.
> > >
> > >
> > > Thank you, apology accepted. That was exactly my point, not to start a 
> > > fight, but to emphasize that depending on local configuration is never 
> > > going to work, you will never be able to see and test all of them. Please 
> > > disable the test ASAP and until the better way to handle it is determined.
> >
> >
> > I have disabled all the offloading tests apart from the ones that pertain 
> > to the patch previous to the one introducing Cubin integration into host 
> > bin.
> >  Please let me know if you see any more failures on your side. If you do 
> > feel free to revert all the patches up to and including: 
> > https://reviews.llvm.org/D29654
> >
> > 310625
>
>
> Our bots still fai after this changel: 
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7085


r310640 disables this test on Linux


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



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

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

[Nico Weber via cfe-commits]

I really believe this has way too many deps to live in the clang repro, as
said on the review already. Maybe this could live in clang-extra instead?

On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> Author: morehouse
> Date: Tue Aug  8 13:15:04 2017
> New Revision: 310408
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310408=rev
> Log:
> Integrate Kostya's clang-proto-fuzzer with LLVM.
>
> Summary:
> The clang-proto-fuzzer models a subset of C++ as a protobuf and
> uses libprotobuf-mutator to generate interesting mutations of C++
> programs.  Clang-proto-fuzzer has already found several bugs in
> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
> https://bugs.llvm.org/show_bug.cgi?id=33749).
>
> As with clang-fuzzer, clang-proto-fuzzer requires the following
> cmake flags:
> - CMAKE_C_COMPILER=clang
> - CMAKE_CXX_COMPILER=clang++
> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>
> In addition, clang-proto-fuzzer requires:
> - CLANG_ENABLE_PROTO_FUZZER=ON
>
> clang-proto-fuzzer also requires the following dependencies:
> - binutils  // needed for libprotobuf-mutator
> - liblzma-dev  // needed for libprotobuf-mutator
> - libz-dev  // needed for libprotobuf-mutator
> - docbook2x  // needed for libprotobuf-mutator
> - Recent version of protobuf [3.3.0 is known to work]
>
> A working version of libprotobuf-mutator will automatically be
> downloaded and built as an external project.
>
> Implementation of clang-proto-fuzzer provided by Kostya
> Serebryany.
>
> https://bugs.llvm.org/show_bug.cgi?id=33829
>
> Reviewers: kcc, vitalybuka, bogner
>
> Reviewed By: kcc, vitalybuka
>
> Subscribers: thakis, mgorny, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D36324
>
> Added:
> cfe/trunk/cmake/modules/ProtobufMutator.cmake
> cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
> cfe/trunk/tools/clang-fuzzer/README.txt
> cfe/trunk/tools/clang-fuzzer/cxx_proto.proto
> cfe/trunk/tools/clang-fuzzer/handle-cxx/
> cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.cpp
> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.h
> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/
> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt
> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/tools/clang-fuzzer/CMakeLists.txt
> cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
>
> Modified: cfe/trunk/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.
> txt?rev=310408=310407=310408=diff
> 
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Tue Aug  8 13:15:04 2017
> @@ -377,6 +377,8 @@ option(CLANG_ENABLE_STATIC_ANALYZER "Bui
>  option(CLANG_ANALYZER_BUILD_Z3
>"Build the static analyzer with the Z3 constraint manager." OFF)
>
> +option(CLANG_ENABLE_PROTO_FUZZER "Build Clang protobuf fuzzer." OFF)
> +
>  if(NOT CLANG_ENABLE_STATIC_ANALYZER AND (CLANG_ENABLE_ARCMT OR
> CLANG_ANALYZER_BUILD_Z3))
>message(FATAL_ERROR "Cannot disable static analyzer while enabling
> ARCMT or Z3")
>  endif()
>
> Added: cfe/trunk/cmake/modules/ProtobufMutator.cmake
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/
> modules/ProtobufMutator.cmake?rev=310408=auto
> 
> ==
> --- cfe/trunk/cmake/modules/ProtobufMutator.cmake (added)
> +++ cfe/trunk/cmake/modules/ProtobufMutator.cmake Tue Aug  8 13:15:04 2017
> @@ -0,0 +1,24 @@
> +set(PBM_PREFIX protobuf_mutator)
> +set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${PBM_PREFIX}/src/${PBM_PREFIX})
> +set(PBM_LIB_PATH ${PBM_PATH}/src/libprotobuf-mutator.a)
> +set(PBM_FUZZ_LIB_PATH ${PBM_PATH}/src/libfuzzer/
> libprotobuf-mutator-libfuzzer.a)
> +
> +ExternalProject_Add(${PBM_PREFIX}
> +  PREFIX ${PBM_PREFIX}
> +  GIT_REPOSITORY https://github.com/google/libprotobuf-mutator.git
> +  GIT_TAG 34287f8
> +  CONFIGURE_COMMAND ${CMAKE_COMMAND} -G${CMAKE_GENERATOR}
> +-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
> +-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
> +-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
> +  BUILD_COMMAND ${CMAKE_MAKE_PROGRAM}
> +  BUILD_BYPRODUCTS ${PBM_LIB_PATH} ${PBM_FUZZ_LIB_PATH}
> +  BUILD_IN_SOURCE 1
> +  INSTALL_COMMAND ""
> +  LOG_DOWNLOAD 1
> +  LOG_CONFIGURE 1
> +  LOG_BUILD 1
> +  )
> +
> +set(ProtobufMutator_INCLUDE_DIRS ${PBM_PATH})
> +set(ProtobufMutator_LIBRARIES ${PBM_FUZZ_LIB_PATH} ${PBM_LIB_PATH})
>
> Modified: cfe/trunk/tools/clang-fuzzer/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-
> 

r310640 - Disabling openmp-offload.c on linux until it is stabilized on all local configurations.

[Alex Shlyapnikov via cfe-commits]

Author: alekseyshl
Date: Thu Aug 10 10:55:01 2017
New Revision: 310640

URL: http://llvm.org/viewvc/llvm-project?rev=310640=rev
Log:
Disabling openmp-offload.c on linux until it is stabilized on all local 
configurations.

Modified:
cfe/trunk/test/Driver/openmp-offload.c

Modified: cfe/trunk/test/Driver/openmp-offload.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/openmp-offload.c?rev=310640=310639=310640=diff
==
--- cfe/trunk/test/Driver/openmp-offload.c (original)
+++ cfe/trunk/test/Driver/openmp-offload.c Thu Aug 10 10:55:01 2017
@@ -2,6 +2,9 @@
 /// Perform several driver tests for OpenMP offloading
 ///
 
+// Until this test is stabilized on all local configurations.
+// UNSUPPORTED: linux
+
 // REQUIRES: clang-driver
 // REQUIRES: x86-registered-target
 // REQUIRES: powerpc-registered-target


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

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Aleksey Shlyapnikov via Phabricator via cfe-commits]

alekseyshl added a comment.

In https://reviews.llvm.org/D29660#838219, @gtbercea wrote:

> In https://reviews.llvm.org/D29660#838194, @arphaman wrote:
>
> > The failures were very widespread, e.g. there's a linux buildbot that was 
> > red until the revert: http://bb.pgr.jp/builders/test-clang-i686-linux-RA. 
> > If you have access to a linux machine you should be able to reproduce the 
> > failures that the bot experienced by using the same cmake arguments (I 
> > don't know the exact ones, but judging from the bot you should be able to 
> > reproduce them using 32 bit release build with assertions enabled). I don't 
> > know what GPU that buildbot has.
>
>
> Thanks Alex, I will try to reproduce it locally.
>
> > I'll try to get the detailed test output for my local machine today as well.
>
> Oh that would be great! Thanks a lot! :)




In https://reviews.llvm.org/D29660#838262, @gtbercea wrote:

> In https://reviews.llvm.org/D29660#838185, @alekseyshl wrote:
>
> > In https://reviews.llvm.org/D29660#838150, @gtbercea wrote:
> >
> > > First of all, I apologize if I've upset you with my previous post. I am 
> > > actively working on understanding what is causing these issues. It is not 
> > > my intention to write tests that work on local configurations only. I am 
> > > upset to see that these tests keep failing for your and maybe other 
> > > configurations. Without knowing the actual reason of the failures I can 
> > > only speculate what is going wrong with them hence the flurry of changes.
> >
> >
> > Thank you, apology accepted. That was exactly my point, not to start a 
> > fight, but to emphasize that depending on local configuration is never 
> > going to work, you will never be able to see and test all of them. Please 
> > disable the test ASAP and until the better way to handle it is determined.
>
>
> I have disabled all the offloading tests apart from the ones that pertain to 
> the patch previous to the one introducing Cubin integration into host bin.
>  Please let me know if you see any more failures on your side. If you do feel 
> free to revert all the patches up to and including: 
> https://reviews.llvm.org/D29654
>
> 310625


Our bots still fai after this changel: 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7085


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



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

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

In https://reviews.llvm.org/D34158#837444, @jyknight wrote:

> Now, the "/tmp/foo-XXX.sh" also has a line labeled "Driver args: " with the 
> original command-line on it. If I understand correctly, you then like to take 
> this
>  simpler Driver command-line, and edit it manually: add -save-temps, and 
> change the input filename  to the "/tmp/foo-XXX.c" file, and run that, instead
>  of actually invoking the reproducer foo-XXX.sh.


It's not so much that it is simpler, but the only reasonable easy way for 
forcing preprocessor output to written. That one is much nicer for passing to 
creduce for example (after stripping the remaining # lines).

> Since stdc-predef.h is included automatically, it will now be present twice 
> -- first, it will read the one from your system's /usr/include, and then the 
> copy inlined into the
>  /tmp/foo-XXX.c file. That's not what you desired. You wanted nothing from 
> your /usr/include to be used.

Correct. Worse, the include may file depending on the host system and give 
different results from the original build, resulting in annoying debugging 
seasons.

> The fix for the end-user here is easy: you can add -nostdinc which will 
> suppress all the default include paths, and thus it will not find this predef 
> file from your system include dir.

Yeah, except you have to remember that when it was never needed before.

> I'll note that you'd also have had an issue if the original driver 
> command-line had a "-include" option in it, which you would have needed to 
> edit out
>  manually as well. (But I understand that is less common.)

Yes, -include is rarely used in the wild.

> Have I correctly described the situation? I guess my feeling here is that 
> this is somewhat of an edge-case, and that the workaround (-nostdinc) is a 
> sufficient fix.
> 
 (3) It seems to me that the GNU userland (and maybe Windows) is the 
 exception to a well integrated tool chain. Most other platforms have a 
 single canonical
  libc, libm and libpthread implementation and can as such directly define 
 all the relevant macros directly in the driver.
>>> 
>>> I don't think this is accurate. There's many platforms out there, and for 
>>> almost none of them do we have exact knowledge of the features of the libc 
>>> encoded
>>>  into the compiler. I'd note that not only do you need this for every (OS, 
>>> libc) combination, you'd need it for every (OS, libc-VERSION) combination.
>> 
>> Not really. The feature set is rarely changing and generally will have only 
>> a cut-off version.
> 
> Yes, but this is information that the compiler has no real need to know, and 
> that for many platforms would be difficult and problematic to coordinate.

That's kind of my point. There is little coordination involved for almost all 
platforms since they provide a consistent user environment as a single package. 
Pushing the changes into Clang (or GCC for that matter) is trivial if you do 
not have to deal with multiple different versions of libc, the kernel and 
whatever in a mix-and-match scenario.


https://reviews.llvm.org/D34158



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

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

In https://reviews.llvm.org/D34158#837281, @hfinkel wrote:

> In https://reviews.llvm.org/D34158#837130, @joerg wrote:
>
> > In https://reviews.llvm.org/D34158#836026, @jyknight wrote:
> >
> > > In https://reviews.llvm.org/D34158#827178, @joerg wrote:
> > >
> > > > (2) It adds magic behavior that can make debugging more difficult. 
> > > > Partially preprocessed sources for example could be compiled with plain 
> > > > -c before, now they need a different command line.
> > >
> > >
> > > If this is a problem, making it be Linux-only does _nothing_ to solve it. 
> > > But I don't actually see how this is a substantively new problem? 
> > > Compiling with plain -c before
> > >  would get #defines for those predefined macros that the compiler sets, 
> > > even though you may not have wanted those. Is this fundamentally 
> > > different?
> >
> >
> > It makes it a linux-only problem. As such, it is something *I* only care 
> > about secondary. A typical use case I care about a lot is pulling the crash 
> > report sources from my (NetBSD) build machine,
> >  extracting the original command line to rerun the normal compilation with 
> > -save-temps. I don't necessarily have the (same) system headers on the 
> > machine I use for debugging and that's exactly
> >  the kind of use case this change breaks. All other predefined macros are 
> > driven by the target triple and remain stable.
>
>
> Don't you use preprocessed source files from a crash?


The crash rewrite tool creates semi-preprocessed output. It resolves includes 
along all code branches, but keeps macros and CPP conditionals alone.


https://reviews.llvm.org/D34158



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

Re: r310605 - [Modules] Prevent #import to reenter header if not building a module.

[Hans Wennborg via cfe-commits]

Sounds good to me.

Richard, what do you think?

On Thu, Aug 10, 2017 at 9:38 AM, Bruno Cardoso Lopes
 wrote:
> Hi Hans, can we please get this merged into 5.0?
>
> Thanks,
>
> On Thu, Aug 10, 2017 at 12:16 PM, Bruno Cardoso Lopes via cfe-commits
>  wrote:
>> Author: bruno
>> Date: Thu Aug 10 08:16:24 2017
>> New Revision: 310605
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310605=rev
>> Log:
>> [Modules] Prevent #import to reenter header if not building a module.
>>
>> When non-modular headers are imported while not building a module but
>> in -fmodules mode, be conservative and preserve the default #import
>> semantic: do not reenter headers.
>>
>> rdar://problem/33745031
>>
>> Added:
>> cfe/trunk/test/Modules/Inputs/import-textual/x.h
>> cfe/trunk/test/Modules/import-textual-nomodules.m
>> Modified:
>> cfe/trunk/lib/Lex/HeaderSearch.cpp
>>
>> Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=310605=310604=310605=diff
>> ==
>> --- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
>> +++ cfe/trunk/lib/Lex/HeaderSearch.cpp Thu Aug 10 08:16:24 2017
>> @@ -1143,7 +1143,7 @@ bool HeaderSearch::ShouldEnterIncludeFil
>>  // headers find in the wild might rely only on #import and do not 
>> contain
>>  // controlling macros, be conservative and only try to enter textual 
>> headers
>>  // if such macro is present.
>> -if (!FileInfo.isModuleHeader &&
>> +if (FileInfo.isCompilingModuleHeader && !FileInfo.isModuleHeader &&
>>  FileInfo.getControllingMacro(ExternalLookup))
>>TryEnterHdr = true;
>>  return TryEnterHdr;
>>
>> Added: cfe/trunk/test/Modules/Inputs/import-textual/x.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/import-textual/x.h?rev=310605=auto
>> ==
>> --- cfe/trunk/test/Modules/Inputs/import-textual/x.h (added)
>> +++ cfe/trunk/test/Modules/Inputs/import-textual/x.h Thu Aug 10 08:16:24 2017
>> @@ -0,0 +1,6 @@
>> +#ifndef RANDOM_DEP
>> +
>> +@interface X
>> +@end
>> +
>> +#endif // RANDOM_DEP
>>
>> Added: cfe/trunk/test/Modules/import-textual-nomodules.m
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/import-textual-nomodules.m?rev=310605=auto
>> ==
>> --- cfe/trunk/test/Modules/import-textual-nomodules.m (added)
>> +++ cfe/trunk/test/Modules/import-textual-nomodules.m Thu Aug 10 08:16:24 
>> 2017
>> @@ -0,0 +1,8 @@
>> +// RUN: rm -rf %t
>> +// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps 
>> -I%S/Inputs/import-textual -fmodules-cache-path=%t %s -verify
>> +
>> +// expected-no-diagnostics
>> +
>> +#import "x.h"
>> +#import "x.h"
>> +
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36185: [clang-diff] Fix similarity computation

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: tools/clang-diff/ClangDiff.cpp:436
+else if (StopAfter != "bottomup") {
+  llvm::errs() << "Error: Invalid argument for -stop-after";
+  return 1;

Add a newline to the string as well.


https://reviews.llvm.org/D36185



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

[PATCH] D36184: [clang-diff] Filter AST nodes

[Johannes Altmanninger via Phabricator via cfe-commits]

johannes added inline comments.



Comment at: test/Tooling/clang-diff-ast.cpp:68
+// nodes from other files are excluded
+// CHECK-NOT {{.}}
+#include "clang-diff-ast.cpp"

arphaman wrote:
> 1) Missing ':'
> 2) What exactly does this regex accomplish? Right now it will match any 
> character which doesn't look correct
I want to assert that there is no output here, because other files are 
excluded, there may be a better way..


https://reviews.llvm.org/D36184



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

[PATCH] D36184: [clang-diff] Filter AST nodes

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: test/Tooling/clang-diff-ast.cpp:68
+// nodes from other files are excluded
+// CHECK-NOT {{.}}
+#include "clang-diff-ast.cpp"

1) Missing ':'
2) What exactly does this regex accomplish? Right now it will match any 
character which doesn't look correct


https://reviews.llvm.org/D36184



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

[PATCH] D36179: [clang-diff] Move printing of matches and changes to clang-diff

[Johannes Altmanninger via Phabricator via cfe-commits]

johannes updated this revision to Diff 110608.
johannes added a comment.

initialize Node::Shift


https://reviews.llvm.org/D36179

Files:
  include/clang/Tooling/ASTDiff/ASTDiff.h
  include/clang/Tooling/ASTDiff/ASTDiffInternal.h
  lib/Tooling/ASTDiff/ASTDiff.cpp
  test/Tooling/clang-diff-basic.cpp
  tools/clang-diff/ClangDiff.cpp

Index: tools/clang-diff/ClangDiff.cpp
===
--- tools/clang-diff/ClangDiff.cpp
+++ tools/clang-diff/ClangDiff.cpp
@@ -129,7 +129,7 @@
   auto Offsets = Tree.getSourceRangeOffsets(N);
   OS << R"(,"begin":)" << Offsets.first;
   OS << R"(,"end":)" << Offsets.second;
-  std::string Value = Tree.getNodeValue(N.ASTNode);
+  std::string Value = Tree.getNodeValue(N);
   if (!Value.empty()) {
 OS << R"(,"value":")";
 printJsonString(OS, Value);
@@ -153,6 +153,52 @@
   OS << "]}";
 }
 
+static void printNode(raw_ostream , diff::SyntaxTree ,
+  diff::NodeId Id) {
+  if (Id.isInvalid()) {
+OS << "None";
+return;
+  }
+  OS << Tree.getNode(Id).getTypeLabel();
+  std::string Value = Tree.getNodeValue(Id);
+  if (!Value.empty())
+OS << ": " << Value;
+  OS << "(" << Id << ")";
+}
+
+static void printDstChange(raw_ostream , diff::ASTDiff ,
+   diff::SyntaxTree , diff::SyntaxTree ,
+   diff::NodeId Dst) {
+  const diff::Node  = DstTree.getNode(Dst);
+  diff::NodeId Src = Diff.getMapped(DstTree, Dst);
+  switch (DstNode.ChangeKind) {
+  case diff::None:
+break;
+  case diff::Delete:
+llvm_unreachable("The destination tree can't have deletions.");
+  case diff::Update:
+OS << "Update ";
+printNode(OS, SrcTree, Src);
+OS << " to " << DstTree.getNodeValue(Dst) << "\n";
+break;
+  case diff::Insert:
+  case diff::Move:
+  case diff::UpdateMove:
+if (DstNode.ChangeKind == diff::Insert)
+  OS << "Insert";
+else if (DstNode.ChangeKind == diff::Move)
+  OS << "Move";
+else if (DstNode.ChangeKind == diff::UpdateMove)
+  OS << "Update and Move";
+OS << " ";
+printNode(OS, DstTree, Dst);
+OS << " into ";
+printNode(OS, DstTree, DstNode.Parent);
+OS << " at " << DstTree.findPositionInParent(Dst) << "\n";
+break;
+  }
+}
+
 int main(int argc, const char **argv) {
   std::string ErrorMessage;
   std::unique_ptr CommonCompilations =
@@ -199,11 +245,26 @@
 Options.MaxSize = MaxSize;
   diff::SyntaxTree SrcTree(Src->getASTContext());
   diff::SyntaxTree DstTree(Dst->getASTContext());
-  diff::ASTDiff DiffTool(SrcTree, DstTree, Options);
-  for (const auto  : DiffTool.getMatches())
-DiffTool.printMatch(llvm::outs(), Match);
-  for (const auto  : DiffTool.getChanges())
-DiffTool.printChange(llvm::outs(), Change);
+  diff::ASTDiff Diff(SrcTree, DstTree, Options);
+
+  for (diff::NodeId Dst : DstTree) {
+diff::NodeId Src = Diff.getMapped(DstTree, Dst);
+if (Src.isValid()) {
+  llvm::outs() << "Match ";
+  printNode(llvm::outs(), SrcTree, Src);
+  llvm::outs() << " to ";
+  printNode(llvm::outs(), DstTree, Dst);
+  llvm::outs() << "\n";
+}
+printDstChange(llvm::outs(), Diff, SrcTree, DstTree, Dst);
+  }
+  for (diff::NodeId Src : SrcTree) {
+if (Diff.getMapped(SrcTree, Src).isInvalid()) {
+  llvm::outs() << "Delete ";
+  printNode(llvm::outs(), SrcTree, Src);
+  llvm::outs() << "\n";
+}
+  }
 
   return 0;
 }
Index: test/Tooling/clang-diff-basic.cpp
===
--- test/Tooling/clang-diff-basic.cpp
+++ test/Tooling/clang-diff-basic.cpp
@@ -31,6 +31,10 @@
   int id(int i) { return i; }
 };
 }
+
+void m() { int x = 0 + 0 + 0; }
+int um = 1 + 2 + 3;
+
 #else
 // CHECK: Match TranslationUnitDecl{{.*}} to TranslationUnitDecl
 // CHECK: Match NamespaceDecl: src{{.*}} to NamespaceDecl: dst
@@ -54,8 +58,8 @@
 typedef unsigned nat;
 
 // CHECK: Match VarDecl: p(int){{.*}} to VarDecl: prod(double)
-// CHECK: Match BinaryOperator: *{{.*}} to BinaryOperator: *
 // CHECK: Update VarDecl: p(int){{.*}} to prod(double)
+// CHECK: Match BinaryOperator: *{{.*}} to BinaryOperator: *
 double prod = 1 * 2 * 10;
 // CHECK: Update DeclRefExpr
 int squared = prod * prod;
@@ -70,9 +74,15 @@
   return "foo";
 return 0;
   }
-  // CHECK: Delete AccessSpecDecl: public
-  X(){};
-  // CHECK: Delete CXXMethodDecl
+  X(){}
 };
 }
+
+// CHECK: Move DeclStmt{{.*}} into CompoundStmt
+void m() { { int x = 0 + 0 + 0; } }
+// CHECK: Update and Move IntegerLiteral: 7{{.*}} into BinaryOperator: +({{.*}}) at 1
+int um = 1 + 7;
 #endif
+
+// CHECK: Delete AccessSpecDecl: public
+// CHECK: Delete CXXMethodDecl
Index: lib/Tooling/ASTDiff/ASTDiff.cpp
===
--- lib/Tooling/ASTDiff/ASTDiff.cpp
+++ lib/Tooling/ASTDiff/ASTDiff.cpp
@@ -82,26 +82,23 @@
 class ASTDiff::Impl {
 public:
   SyntaxTree::Impl , 
-  bool IsMappingDone = false;
   Mapping 

[clang-tools-extra] r310630 - [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Yan Wang via cfe-commits]

Author: yawanng
Date: Thu Aug 10 10:18:10 2017
New Revision: 310630

URL: http://llvm.org/viewvc/llvm-project?rev=310630=rev
Log:
[clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() 
in Android module.

Summary:
1. Refactor the structure of the code by adding a base class for all 
close-on-exec checks, which implements most of the needed functions.
2. memfd_create() is better to set MFD_CLOEXEC flag to avoid file descriptor 
leakage.

Reviewers: alexfh, aaron.ballman, hokein

Reviewed By: alexfh, hokein

Subscribers: Eugene.Zelenko, chh, cfe-commits, srhines, mgorny, JDevlieghere, 
xazax.hun

Tags: #clang-tools-extra

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

Added:
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecMemfdCreateCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-memfd-create.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-memfd-create.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310630=310629=310630=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Thu Aug 10 
10:18:10 2017
@@ -12,6 +12,7 @@
 #include "../ClangTidyModuleRegistry.h"
 #include "CloexecCreatCheck.h"
 #include "CloexecFopenCheck.h"
+#include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
 #include "CloexecSocketCheck.h"
 
@@ -27,6 +28,8 @@ public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
 CheckFactories.registerCheck("android-cloexec-creat");
 CheckFactories.registerCheck("android-cloexec-fopen");
+CheckFactories.registerCheck(
+"android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");
 CheckFactories.registerCheck("android-cloexec-socket");
   }

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310630=310629=310630=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Thu Aug 10 
10:18:10 2017
@@ -2,8 +2,10 @@ set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyAndroidModule
   AndroidTidyModule.cpp
+  CloexecCheck.cpp
   CloexecCreatCheck.cpp
   CloexecFopenCheck.cpp
+  CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp
   CloexecSocketCheck.cpp
 

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp?rev=310630=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp Thu Aug 10 
10:18:10 2017
@@ -0,0 +1,105 @@
+//===--- CloexecCheck.cpp - 
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecCheck.h"
+#include "../utils/ASTUtils.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+namespace {
+
+const char *const FuncDeclBindingStr = "funcDecl";
+const char *const FuncBindingStr = "func";
+
+// Helper function to form the correct string mode for Type3.
+// Build the replace text. If it's string constant, add  directly in the
+// end of the string. Else, add .
+std::string buildFixMsgForStringFlag(const Expr *Arg, const SourceManager ,
+ const LangOptions , char Mode) {
+  if (Arg->getLocStart().isMacroID())
+return (Lexer::getSourceText(
+CharSourceRange::getTokenRange(Arg->getSourceRange()), SM,
+LangOpts) +
+" \"" + Twine(Mode) + "\"")
+.str();
+
+  StringRef SR = 

[PATCH] D36183: [clang-diff] Simplify mapping

[Alex Lorenz via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D36183



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

[PATCH] D35372: [clang-tidy] Refactor the code and add a close-on-exec check on memfd_create() in Android module.

[Yan Wang via Phabricator via cfe-commits]

yawanng updated this revision to Diff 110606.
yawanng marked 3 inline comments as done.

https://reviews.llvm.org/D35372

Files:
  clang-tidy/android/AndroidTidyModule.cpp
  clang-tidy/android/CMakeLists.txt
  clang-tidy/android/CloexecCheck.cpp
  clang-tidy/android/CloexecCheck.h
  clang-tidy/android/CloexecMemfdCreateCheck.cpp
  clang-tidy/android/CloexecMemfdCreateCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/android-cloexec-memfd-create.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/android-cloexec-memfd-create.cpp

Index: test/clang-tidy/android-cloexec-memfd-create.cpp
===
--- /dev/null
+++ test/clang-tidy/android-cloexec-memfd-create.cpp
@@ -0,0 +1,63 @@
+// RUN: %check_clang_tidy %s android-cloexec-memfd-create %t
+
+#define MFD_ALLOW_SEALING 1
+#define __O_CLOEXEC 3
+#define MFD_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+#define NULL 0
+
+extern "C" int memfd_create(const char *name, unsigned int flags);
+
+void a() {
+  memfd_create(NULL, MFD_ALLOW_SEALING);
+  // CHECK-MESSAGES: :[[@LINE-1]]:39: warning: 'memfd_create' should use MFD_CLOEXEC where possible [android-cloexec-memfd-create]
+  // CHECK-FIXES: memfd_create(NULL, MFD_ALLOW_SEALING | MFD_CLOEXEC)
+  TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_ALLOW_SEALING));
+  // CHECK-MESSAGES: :[[@LINE-1]]:58: warning: 'memfd_create'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_ALLOW_SEALING | MFD_CLOEXEC))
+}
+
+void f() {
+  memfd_create(NULL, 3);
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: 'memfd_create'
+  // CHECK-FIXES: memfd_create(NULL, 3 | MFD_CLOEXEC)
+  TEMP_FAILURE_RETRY(memfd_create(NULL, 3));
+  // CHECK-MESSAGES: :[[@LINE-1]]:42: warning: 'memfd_create'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(memfd_create(NULL, 3 | MFD_CLOEXEC))
+
+  int flag = 3;
+  memfd_create(NULL, flag);
+  TEMP_FAILURE_RETRY(memfd_create(NULL, flag));
+}
+
+namespace i {
+int memfd_create(const char *name, unsigned int flags);
+
+void d() {
+  memfd_create(NULL, MFD_ALLOW_SEALING);
+  TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_ALLOW_SEALING));
+}
+
+} // namespace i
+
+void e() {
+  memfd_create(NULL, MFD_CLOEXEC);
+  TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_CLOEXEC));
+  memfd_create(NULL, MFD_ALLOW_SEALING | MFD_CLOEXEC);
+  TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_ALLOW_SEALING | MFD_CLOEXEC));
+}
+
+class G {
+public:
+  int memfd_create(const char *name, unsigned int flags);
+  void d() {
+memfd_create(NULL, MFD_ALLOW_SEALING);
+TEMP_FAILURE_RETRY(memfd_create(NULL, MFD_ALLOW_SEALING));
+  }
+};
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -6,6 +6,7 @@
 .. toctree::
android-cloexec-creat
android-cloexec-fopen
+   android-cloexec-memfd-create
android-cloexec-open
android-cloexec-socket
boost-use-to-string
Index: docs/clang-tidy/checks/android-cloexec-memfd-create.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/android-cloexec-memfd-create.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-memfd-create
+
+android-cloexec-memfd-create
+
+
+``memfd_create()`` should include ``MFD_CLOEXEC`` in its type argument to avoid
+the file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  memfd_create(name, MFD_ALLOW_SEALING);
+
+  // becomes
+
+  memfd_create(name, MFD_ALLOW_SEALING | MFD_CLOEXEC);
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -73,6 +73,12 @@
 
   Checks if the required mode ``e`` exists in the mode argument of ``fopen()``.
 
+- New `android-cloexec-memfd_create
+  `_ check
+
+  Checks if the required file flag ``MFD_CLOEXEC`` is present in the argument of
+  ``memfd_create()``.
+
 - New `android-cloexec-socket
   `_ check
 
Index: clang-tidy/android/CloexecMemfdCreateCheck.h
===
--- /dev/null
+++ clang-tidy/android/CloexecMemfdCreateCheck.h
@@ -0,0 +1,35 @@
+//===--- CloexecMemfdCreateCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//

[PATCH] D36179: [clang-diff] Move printing of matches and changes to clang-diff

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: include/clang/Tooling/ASTDiff/ASTDiff.h:40
   NodeId Parent, LeftMostDescendant, RightMostDescendant;
-  int Depth, Height;
+  int Depth, Height, Shift;
   ast_type_traits::DynTypedNode ASTNode;

Looks like `Shift` isn't initialized anywhere.


https://reviews.llvm.org/D36179



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

[PATCH] D36531: [Parse] Document Parser::SkipFunctionBodies

[Brian Gesiak via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL310627: [Parse] Document Parser::SkipFunctionBodies 
(authored by modocache).

Repository:
  rL LLVM

https://reviews.llvm.org/D36531

Files:
  cfe/trunk/include/clang/Parse/Parser.h


Index: cfe/trunk/include/clang/Parse/Parser.h
===
--- cfe/trunk/include/clang/Parse/Parser.h
+++ cfe/trunk/include/clang/Parse/Parser.h
@@ -253,6 +253,10 @@
   /// be NULL.
   bool ParsingInObjCContainer;
 
+  /// Whether to skip parsing of function bodies.
+  ///
+  /// This option can be used, for example, to speed up searches for
+  /// delcarations/definitions when indexing.
   bool SkipFunctionBodies;
 
   /// The location of the expression statement that is being parsed right now.


Index: cfe/trunk/include/clang/Parse/Parser.h
===
--- cfe/trunk/include/clang/Parse/Parser.h
+++ cfe/trunk/include/clang/Parse/Parser.h
@@ -253,6 +253,10 @@
   /// be NULL.
   bool ParsingInObjCContainer;
 
+  /// Whether to skip parsing of function bodies.
+  ///
+  /// This option can be used, for example, to speed up searches for
+  /// delcarations/definitions when indexing.
   bool SkipFunctionBodies;
 
   /// The location of the expression statement that is being parsed right now.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r310627 - [Parse] Document Parser::SkipFunctionBodies

[Brian Gesiak via cfe-commits]

Author: modocache
Date: Thu Aug 10 10:02:04 2017
New Revision: 310627

URL: http://llvm.org/viewvc/llvm-project?rev=310627=rev
Log:
[Parse] Document Parser::SkipFunctionBodies

Reviewers: erikjv, doug.gregor

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Parse/Parser.h

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=310627=310626=310627=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Thu Aug 10 10:02:04 2017
@@ -253,6 +253,10 @@ class Parser : public CodeCompletionHand
   /// be NULL.
   bool ParsingInObjCContainer;
 
+  /// Whether to skip parsing of function bodies.
+  ///
+  /// This option can be used, for example, to speed up searches for
+  /// delcarations/definitions when indexing.
   bool SkipFunctionBodies;
 
   /// The location of the expression statement that is being parsed right now.


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

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

In https://reviews.llvm.org/D29660#838185, @alekseyshl wrote:

> In https://reviews.llvm.org/D29660#838150, @gtbercea wrote:
>
> > First of all, I apologize if I've upset you with my previous post. I am 
> > actively working on understanding what is causing these issues. It is not 
> > my intention to write tests that work on local configurations only. I am 
> > upset to see that these tests keep failing for your and maybe other 
> > configurations. Without knowing the actual reason of the failures I can 
> > only speculate what is going wrong with them hence the flurry of changes.
>
>
> Thank you, apology accepted. That was exactly my point, not to start a fight, 
> but to emphasize that depending on local configuration is never going to 
> work, you will never be able to see and test all of them. Please disable the 
> test ASAP and until the better way to handle it is determined.


I have disabled all the offloading tests apart from the ones that pertain to 
the patch previous to the one introducing Cubin integration into host bin.
Please let me know if you see any more failures on your side. If you do feel 
free to revert all the patches up to and including: 
https://reviews.llvm.org/D29654

310625


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



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

[PATCH] D35955: clang-format: Add preprocessor directive indentation

[Erik Uhlmann via Phabricator via cfe-commits]

euhlmann updated this revision to Diff 110602.
euhlmann edited the summary of this revision.
euhlmann added a comment.

The patch now uses `PPBranchLevel` to track indent level. It allows 
`PPBranchLevel` to go back down to -1. The existing `PPBranchLevel >= 0` checks 
appear to prevent indexing into structures when `PPBranchLevel` is -1.


https://reviews.llvm.org/D35955

Files:
  docs/ClangFormatStyleOptions.rst
  include/clang/Format/Format.h
  lib/Format/ContinuationIndenter.cpp
  lib/Format/Format.cpp
  lib/Format/UnwrappedLineFormatter.cpp
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -2286,8 +2286,158 @@
getLLVMStyleWithColumns(11));
 }
 
-TEST_F(FormatTest, IndentPreprocessorDirectivesAtZero) {
-  EXPECT_EQ("{\n  {\n#define A\n  }\n}", format("{{\n#define A\n}}"));
+TEST_F(FormatTest, IndentPreprocessorDirectives) {
+  FormatStyle Style = getLLVMStyle();
+  Style.IndentPPDirectives = FormatStyle::PPDIS_None;
+  verifyFormat("#ifdef _WIN32\n"
+   "#define A 0\n"
+   "#ifdef VAR2\n"
+   "#define B 1\n"
+   "#include \n"
+   "#define MACRO  "
+   "\\\n"
+   "  some_very_long_func_a"
+   "a();\n"
+   "#endif\n"
+   "#else\n"
+   "#define A 1\n"
+   "#endif",
+   Style);
+
+  Style.IndentPPDirectives = FormatStyle::PPDIS_AfterHash;
+  verifyFormat("#ifdef _WIN32\n"
+   "#  define A 0\n"
+   "#  ifdef VAR2\n"
+   "#define B 1\n"
+   "#include \n"
+   "#define MACRO  "
+   "\\\n"
+   "  some_very_long_func_a"
+   "a();\n"
+   "#  endif\n"
+   "#else\n"
+   "#  define A 1\n"
+   "#endif",
+   Style);
+  // Test with include guards.
+  EXPECT_EQ("#ifndef _SOMEFILE_H\n"
+"#define _SOMEFILE_H\n"
+"code();\n"
+"#endif",
+format("#ifndef _SOMEFILE_H\n"
+   "#define _SOMEFILE_H\n"
+   "code();\n"
+   "#endif",
+   Style));
+  // Include guards must have a #define with the same variable immediately
+  // after #ifndef.
+  EXPECT_EQ("#ifndef NOT_GUARD\n"
+"#  define FOO\n"
+"code();\n"
+"#endif",
+format("#ifndef NOT_GUARD\n"
+   "#  define FOO\n"
+   "code();\n"
+   "#endif",
+   Style));
+
+  // Include guards must cover the entire file.
+  EXPECT_EQ("code();\n"
+"#ifndef NOT_GUARD\n"
+"#  define NOT_GUARD\n"
+"code();\n"
+"#endif",
+format("code();\n"
+   "#ifndef NOT_GUARD\n"
+   "#  define NOT_GUARD\n"
+   "code();\n"
+   "#endif",
+   Style));
+  EXPECT_EQ("#ifndef NOT_GUARD\n"
+"#  define NOT_GUARD\n"
+"code();\n"
+"#endif\n"
+"code();",
+format("#ifndef NOT_GUARD\n"
+   "#  define NOT_GUARD\n"
+   "code();\n"
+   "#endif\n"
+   "code();",
+   Style));
+  // Include guards don't have #else.
+  EXPECT_EQ("#ifndef NOT_GUARD\n"
+"#  define NOT_GUARD\n"
+"code();\n"
+"#else\n"
+"#endif",
+format("#ifndef NOT_GUARD\n"
+   "#  define NOT_GUARD\n"
+   "code();\n"
+   "#else\n"
+   "#endif",
+   Style));
+  EXPECT_EQ("#ifndef NOT_GUARD\n"
+"#  define NOT_GUARD\n"
+"code();\n"
+"#elif FOO\n"
+"#endif",
+format("#ifndef NOT_GUARD\n"
+   "#  define NOT_GUARD\n"
+   "code();\n"
+   "#elif FOO\n"
+   "#endif",
+   Style));
+  // Defect: We currently do not deal with the case where there's code between
+  // the #ifndef and #define but all other conditions hold. This is because when
+  // the #define line is parsed, UnwrappedLineParser::Lines doesn't hold the
+  // previous code line yet, so we can't detect it.
+  EXPECT_NE("#ifndef NOT_GUARD\n"
+"code();\n"
+"#  define NOT_GUARD\n"
+"code();\n"
+"#endif",
+  

[PATCH] D36251: [analyzer] Suppress warning when bug path contains noreturn function or return from main in MagentaHandleChecker

[Haowei Wu via Phabricator via cfe-commits]

haowei added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp:483-498
+void MagentaHandleChecker::checkPreStmt(const ReturnStmt *RS,
+CheckerContext ) const {
+  ProgramStateRef State = Ctx.getState();
+  const StackFrameContext *SFCtx = Ctx.getStackFrame();
+  if (!SFCtx || !SFCtx->inTopFrame())
+return;
+  const FunctionDecl *FD = dyn_cast_or_null(SFCtx->getDecl());

NoQ wrote:
> xazax.hun wrote:
> > NoQ wrote:
> > > I think the analyzer core should do this. This code already has a global 
> > > effect on the analysis - it's enough for one checker to generate the 
> > > sink. Additionally, there's also the CFG-based variant of 
> > > suppress-on-sink, which would need to be extended to support this as well 
> > > - this other variant kicks in when the analysis was interrupted before 
> > > reaching the sink (see D35673 and D35674).
> > Do we want to do this unconditionally? Are all of the resources cleaned up 
> > on all of the supported OSes, or maybe for some leak issues it still makes 
> > sense to warn in these cases? Or we simply favor false negatives over false 
> > positives in this case (might make sense)? 
> We could add a flag to `setSuppressOnSink()` as an orthogonal change if it 
> turns out that we need it; i'm not aware of any stuff that badly needs to be 
> cleaned up before normal program termination in the existing checkers.
I also think this should be done in a separate checker like 
NoReturnFunctionChecker or within the analyzer as some other resource leak 
checkers might need this. I am also thinking D36475 should be in a separate 
checker as well. That annotation support really helps us a lot in analyzing 
unit test code and it might be useful for others if someone run into similar 
situation like us. But I cannot decide if we should use the annotate attribute 
or define a new attribute just for the analyzer.


https://reviews.llvm.org/D36251



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

[PATCH] D36584: Implemented P0704R1 - Fixing const-qualified pointers to members

[Hamza Sood via Phabricator via cfe-commits]

hamzasood created this revision.

This patch provides an implementation for P0704R1 .

I also made it work pre-C++2a as an extension (with a warning) since that's how 
Clang seems to deal with small additions like this. Hopefully someone more 
knowledgable on the matter can clarify whether that's appropriate.


https://reviews.llvm.org/D36584

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaExprCXX.cpp
  test/CXX/expr/expr.mptr.oper/p6-0x.cpp
  test/CXX/expr/expr.mptr.oper/p6-2a.cpp
  www/cxx_status.html

Index: www/cxx_status.html
===
--- www/cxx_status.html
+++ www/cxx_status.html
@@ -777,13 +777,12 @@
 
 C++2a implementation status
 
-Clang does not yet support any of the proposed features of
-
+Clang has experimental support for some proposed features of
 the C++ standard following C++17, provisionally named C++2a.
 Note that support for these features may change or be removed without notice,
 as the draft C++2a standard evolves.
 
-
+You can use Clang in C++2a mode with the -std=c++2a option.
 
 
 List of features and minimum Clang version with support
@@ -803,7 +802,7 @@
 
   const-qualified pointers to members
   http://wg21.link/p0704r1;>P0704R1
-  No
+  SVN
 
 
   Allow lambda-capture [=, this]
Index: test/CXX/expr/expr.mptr.oper/p6-2a.cpp
===
--- test/CXX/expr/expr.mptr.oper/p6-2a.cpp
+++ test/CXX/expr/expr.mptr.oper/p6-2a.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -std=c++2a -verify %s
+// expected-no-diagnostics
+
+struct X { void foo() const&; };
+
+void test() {
+  // Example from P0704R1.
+  X{}.foo();
+  (X{}.*::foo)();
+}
Index: test/CXX/expr/expr.mptr.oper/p6-0x.cpp
===
--- test/CXX/expr/expr.mptr.oper/p6-0x.cpp
+++ test/CXX/expr/expr.mptr.oper/p6-0x.cpp
@@ -12,14 +12,20 @@
 // expression whose object expression is an lvalue, the program is
 // ill-formed if the second operand is a pointer to member function
 // with ref-qualifier &&.
-void test(X *xp, int (X::*pmf)(int), int (X::*l_pmf)(int) &, 
-  int (X::*r_pmf)(int) &&) {
+void test(X *xp, int (X::*pmf)(int), int (X::*const_l_pmf)(int) const&,
+  int (X::*l_pmf)(int) &, int (X::*r_pmf)(int) &&) {
   // No ref-qualifier.
   (lvalue().*pmf)(17);
   (xvalue().*pmf)(17);
   (prvalue().*pmf)(17);
   (xp->*pmf)(17);
 
+  // Const Lvalue ref-qualifier.
+  (lvalue().*const_l_pmf)(17);
+  (xvalue().*const_l_pmf)(17); // expected-warning {{C++2a extension}}
+  (prvalue().*const_l_pmf)(17); // expected-warning {{C++2a extension}}
+  (xp->*const_l_pmf)(17);
+
   // Lvalue ref-qualifier.
   (lvalue().*l_pmf)(17);
   (xvalue().*l_pmf)(17); // expected-error-re{{pointer-to-member function type 'int (X::*)(int){{( __attribute__\(\(thiscall\)\))?}} &' can only be called on an lvalue}}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -5162,22 +5162,32 @@
   QualType Result = MemPtr->getPointeeType();
   Result = Context.getCVRQualifiedType(Result, LHSType.getCVRQualifiers());
 
-  // C++0x [expr.mptr.oper]p6:
+  // C++2a [expr.mptr.oper]p6:
   //   In a .* expression whose object expression is an rvalue, the program is
-  //   ill-formed if the second operand is a pointer to member function with
-  //   ref-qualifier &. In a ->* expression or in a .* expression whose object
-  //   expression is an lvalue, the program is ill-formed if the second operand
-  //   is a pointer to member function with ref-qualifier &&.
+  //   ill-formed if the second operand is a pointer to member function whose
+  //   ref-qualifier is &, unless its cv-qualifier-seq is const. In an ->*
+  //   expression or in a .* expression whose object expression is an lvalue,
+  //   the program is ill-formed if the second operand is a pointer to member
+  //   function with ref-qualifier &&.
   if (const FunctionProtoType *Proto = Result->getAs()) {
 switch (Proto->getRefQualifier()) {
 case RQ_None:
   // Do nothing
   break;
 
 case RQ_LValue:
-  if (!isIndirect && !LHS.get()->Classify(Context).isLValue())
-Diag(Loc, diag::err_pointer_to_member_oper_value_classify)
-  << RHSType << 1 << LHS.get()->getSourceRange();
+  if (!isIndirect && !LHS.get()->Classify(Context).isLValue()) {
+if (Proto->isConst() && !Proto->isVolatile())
+  Diag(Loc,
+   !getLangOpts().CPlusPlus2a
+   ? diag::
+ ext_const_amp_pointer_to_member_on_rvalue_cxx2a
+   : diag::
+ warn_cxx1z_compat_const_amp_pointer_to_member_on_rvalue);
+else
+  Diag(Loc, diag::err_pointer_to_member_oper_value_classify)
+<< RHSType 

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

I've traced the output across all the reverted commits:

F5233517: testFailures.md 

Note that after r310549 the last 9 RUN lines started failing because of the 
same crash:

  clang version 6.0.0  (http://llvm.org/git/llvm.git 
00708415fb45c18f9871def78647dd555c253e0b)
  Target: x86_64-apple-darwin17.0.0
  Thread model: posix
  InstalledDir: /Users/alex/bisect/b/./bin
  no libdevice exists.
  UNREACHABLE executed at 
/Users/alex/bisect/llvm/tools/clang/lib/Driver/ToolChains/Cuda.h:88!
  0  clang0x00010799795c 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
  1  clang0x000107997f59 
PrintStackTraceSignalHandler(void*) + 25
  2  clang0x000107993969 llvm::sys::RunSignalHandlers() 
+ 425
  3  clang0x0001079982e2 SignalHandler(int) + 354
  4  libsystem_platform.dylib 0x7fffc35cfefa _sigtramp + 26
  5  libsystem_platform.dylib 0x7fff5b10b6a8 _sigtramp + 2545137608
  6  libsystem_c.dylib0x7fffc341014a abort + 127
  7  clang0x000107872cf0 LLVMInstallFatalErrorHandler + 0
  8  clang0x00010856c51c 
clang::driver::CudaInstallationDetector::getLowestExistingArch() const + 1644
  9  clang0x00010856acfb 
clang::driver::toolchains::CudaToolChain::TranslateArgs(llvm::opt::DerivedArgList
 const&, llvm::StringRef, clang::driver::Action::OffloadKind) const + 1291
  10 clang0x00010843ce37 
clang::driver::Compilation::getArgsForToolChain(clang::driver::ToolChain 
const*, llvm::StringRef, clang::driver::Action::OffloadKind) + 295
  11 clang0x0001084768c0 
clang::driver::Driver::BuildJobsForActionNoCache(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 4064
  12 clang0x000108475541 
clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 1393
  13 clang0x0001084765e3 
clang::driver::Driver::BuildJobsForActionNoCache(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 3331
  14 clang0x000108475541 
clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 1393
  15 clang0x0001084765e3 
clang::driver::Driver::BuildJobsForActionNoCache(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 3331
  16 clang0x000108475541 
clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, 
clang::driver::Action const*, clang::driver::ToolChain const*, llvm::StringRef, 
bool, bool, char const*, std::__1::map >, clang::driver::InputInfo, 
std::__1::less > >, 
std::__1::allocator > const, clang::driver::InputInfo> > >&, 
clang::driver::Action::OffloadKind) const + 1393
  17 clang0x0001084765e3 

[PATCH] D36563: Add a getName accessor for ModuleMacros

[Bob Wilson via Phabricator via cfe-commits]

bob.wilson added a comment.

Committed in r310622


https://reviews.llvm.org/D36563



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

r310622 - Add a getName accessor for ModuleMacros.

[Bob Wilson via cfe-commits]

Author: bwilson
Date: Thu Aug 10 09:42:46 2017
New Revision: 310622

URL: http://llvm.org/viewvc/llvm-project?rev=310622=rev
Log:
Add a getName accessor for ModuleMacros.

Swift would like to be able to access the name of a ModuleMacro.
There was some discussion of this in
https://github.com/apple/swift-clang/pull/93, suggesting that it makes
sense to have this accessor in Clang.

Modified:
cfe/trunk/include/clang/Lex/MacroInfo.h

Modified: cfe/trunk/include/clang/Lex/MacroInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/MacroInfo.h?rev=310622=310621=310622=diff
==
--- cfe/trunk/include/clang/Lex/MacroInfo.h (original)
+++ cfe/trunk/include/clang/Lex/MacroInfo.h Thu Aug 10 09:42:46 2017
@@ -510,6 +510,9 @@ public:
 ID.AddPointer(II);
   }
 
+  /// Get the name of the macro.
+  IdentifierInfo *getName() const { return II; }
+
   /// Get the ID of the module that exports this macro.
   Module *getOwningModule() const { return OwningModule; }
 


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

Re: r310605 - [Modules] Prevent #import to reenter header if not building a module.

[Bruno Cardoso Lopes via cfe-commits]

Hi Hans, can we please get this merged into 5.0?

Thanks,

On Thu, Aug 10, 2017 at 12:16 PM, Bruno Cardoso Lopes via cfe-commits
 wrote:
> Author: bruno
> Date: Thu Aug 10 08:16:24 2017
> New Revision: 310605
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310605=rev
> Log:
> [Modules] Prevent #import to reenter header if not building a module.
>
> When non-modular headers are imported while not building a module but
> in -fmodules mode, be conservative and preserve the default #import
> semantic: do not reenter headers.
>
> rdar://problem/33745031
>
> Added:
> cfe/trunk/test/Modules/Inputs/import-textual/x.h
> cfe/trunk/test/Modules/import-textual-nomodules.m
> Modified:
> cfe/trunk/lib/Lex/HeaderSearch.cpp
>
> Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=310605=310604=310605=diff
> ==
> --- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
> +++ cfe/trunk/lib/Lex/HeaderSearch.cpp Thu Aug 10 08:16:24 2017
> @@ -1143,7 +1143,7 @@ bool HeaderSearch::ShouldEnterIncludeFil
>  // headers find in the wild might rely only on #import and do not contain
>  // controlling macros, be conservative and only try to enter textual 
> headers
>  // if such macro is present.
> -if (!FileInfo.isModuleHeader &&
> +if (FileInfo.isCompilingModuleHeader && !FileInfo.isModuleHeader &&
>  FileInfo.getControllingMacro(ExternalLookup))
>TryEnterHdr = true;
>  return TryEnterHdr;
>
> Added: cfe/trunk/test/Modules/Inputs/import-textual/x.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/import-textual/x.h?rev=310605=auto
> ==
> --- cfe/trunk/test/Modules/Inputs/import-textual/x.h (added)
> +++ cfe/trunk/test/Modules/Inputs/import-textual/x.h Thu Aug 10 08:16:24 2017
> @@ -0,0 +1,6 @@
> +#ifndef RANDOM_DEP
> +
> +@interface X
> +@end
> +
> +#endif // RANDOM_DEP
>
> Added: cfe/trunk/test/Modules/import-textual-nomodules.m
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/import-textual-nomodules.m?rev=310605=auto
> ==
> --- cfe/trunk/test/Modules/import-textual-nomodules.m (added)
> +++ cfe/trunk/test/Modules/import-textual-nomodules.m Thu Aug 10 08:16:24 2017
> @@ -0,0 +1,8 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps 
> -I%S/Inputs/import-textual -fmodules-cache-path=%t %s -verify
> +
> +// expected-no-diagnostics
> +
> +#import "x.h"
> +#import "x.h"
> +
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



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

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

In https://reviews.llvm.org/D29660#838194, @arphaman wrote:

> The failures were very widespread, e.g. there's a linux buildbot that was red 
> until the revert: http://bb.pgr.jp/builders/test-clang-i686-linux-RA. If you 
> have access to a linux machine you should be able to reproduce the failures 
> that the bot experienced by using the same cmake arguments (I don't know the 
> exact ones, but judging from the bot you should be able to reproduce them 
> using 32 bit release build with assertions enabled). I don't know what GPU 
> that buildbot has.


Thanks Alex, I will try to reproduce it locally.

> I'll try to get the detailed test output for my local machine today as well.

Oh that would be great! Thanks a lot! :)


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



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

[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

[Jacob Bandes-Storch via Phabricator via cfe-commits]

jtbandes added a comment.

@gtbercea Hi, I just saw your comment on my gist. (Unfortunately github does 
not send email notifications about gist comments; commenting here is probably 
better.) If you have Docker installed, it should be easy to get whatever output 
you like — just change the Dockerfile to use `-DCMAKE_BUILD_TYPE=Debug`, then 
run `docker build -t llvm-test .` and `docker run -it llvm-test /bin/bash`.


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



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

[PATCH] D36529: Fixed a race condition in PrecompiledPreamble.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL310618: Fixed a race condition in PrecompiledPreamble. 
(authored by ibiryukov).

Repository:
  rL LLVM

https://reviews.llvm.org/D36529

Files:
  cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp


Index: cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
===
--- cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
+++ cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Mutex.h"
 #include "llvm/Support/MutexGuard.h"
+#include "llvm/Support/Process.h"
 
 using namespace clang;
 
@@ -462,9 +463,16 @@
 PrecompiledPreamble::TempPCHFile::createInSystemTempDir(const Twine ,
 StringRef Suffix) {
   llvm::SmallString<64> File;
-  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ File);
+  // Using a version of createTemporaryFile with a file descriptor guarantees
+  // that we would never get a race condition in a multi-threaded setting 
(i.e.,
+  // multiple threads getting the same temporary path).
+  int FD;
+  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ FD,
+   /*ref*/ File);
   if (EC)
 return EC;
+  // We only needed to make sure the file exists, close the file right away.
+  llvm::sys::Process::SafelyCloseFileDescriptor(FD);
   return TempPCHFile(std::move(File).str());
 }
 


Index: cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
===
--- cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
+++ cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Mutex.h"
 #include "llvm/Support/MutexGuard.h"
+#include "llvm/Support/Process.h"
 
 using namespace clang;
 
@@ -462,9 +463,16 @@
 PrecompiledPreamble::TempPCHFile::createInSystemTempDir(const Twine ,
 StringRef Suffix) {
   llvm::SmallString<64> File;
-  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ File);
+  // Using a version of createTemporaryFile with a file descriptor guarantees
+  // that we would never get a race condition in a multi-threaded setting (i.e.,
+  // multiple threads getting the same temporary path).
+  int FD;
+  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ FD,
+   /*ref*/ File);
   if (EC)
 return EC;
+  // We only needed to make sure the file exists, close the file right away.
+  llvm::sys::Process::SafelyCloseFileDescriptor(FD);
   return TempPCHFile(std::move(File).str());
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r310618 - Fixed a race condition in PrecompiledPreamble.

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Thu Aug 10 09:10:40 2017
New Revision: 310618

URL: http://llvm.org/viewvc/llvm-project?rev=310618=rev
Log:
Fixed a race condition in PrecompiledPreamble.

Summary:
Two PrecompiledPreambles, used in parallel on separate threads,
could be writing preamble to the same temporary file.

Reviewers: bkramer, krasimir, klimek

Reviewed By: klimek

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp

Modified: cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp?rev=310618=310617=310618=diff
==
--- cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp (original)
+++ cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp Thu Aug 10 09:10:40 2017
@@ -28,6 +28,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Mutex.h"
 #include "llvm/Support/MutexGuard.h"
+#include "llvm/Support/Process.h"
 
 using namespace clang;
 
@@ -462,9 +463,16 @@ llvm::ErrorOr File;
-  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ File);
+  // Using a version of createTemporaryFile with a file descriptor guarantees
+  // that we would never get a race condition in a multi-threaded setting 
(i.e.,
+  // multiple threads getting the same temporary path).
+  int FD;
+  auto EC = llvm::sys::fs::createTemporaryFile(Prefix, Suffix, /*ref*/ FD,
+   /*ref*/ File);
   if (EC)
 return EC;
+  // We only needed to make sure the file exists, close the file right away.
+  llvm::sys::Process::SafelyCloseFileDescriptor(FD);
   return TempPCHFile(std::move(File).str());
 }
 


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