r296843 - Fix msc-version.c test to handle _MSC_VER=1910

2017-03-02 Thread Dave Bartolomeo via cfe-commits
Author: dbartol
Date: Thu Mar  2 18:08:55 2017
New Revision: 296843

URL: http://llvm.org/viewvc/llvm-project?rev=296843=rev
Log:
Fix msc-version.c test to handle _MSC_VER=1910

Previously, VC++ has always set _MSC_VER to a four-digit value with the two 
least significant digits set to zero. Visual Studio 2017, however, sets 
_MSC_VER=1910, and we expect to update the least significant digit as we 
release major updates for VS 2017. This patch fixes the msc-version.c test to 
handle non-zero values in the two least significant digits of _MSC_VER.

Modified:
cfe/trunk/test/Driver/msc-version.c

Modified: cfe/trunk/test/Driver/msc-version.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/msc-version.c?rev=296843=296842=296843=diff
==
--- cfe/trunk/test/Driver/msc-version.c (original)
+++ cfe/trunk/test/Driver/msc-version.c Thu Mar  2 18:08:55 2017
@@ -63,4 +63,4 @@
 
 // CHECK-MS-EXTENSIONS: _MSC_BUILD 1
 // CHECK-MS-EXTENSIONS: _MSC_FULL_VER {{.+}}
-// CHECK-MS-EXTENSIONS: _MSC_VER {{..}}00
+// CHECK-MS-EXTENSIONS: _MSC_VER {{}}


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


Re: [PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

2016-07-26 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo updated this revision to Diff 65633.
DaveBartolomeo added a comment.
Herald added a subscriber: samparker.

Updated the selection algorithm based on review feedback. Now, if clang.exe 
itself is x64-hosted, we'll look for the x64-hosted MSVC toolset if it exists. 
If clang.exe is not x64-hosted, or if the x64-hosted MSVC toolset is not found, 
we fall back to x86-hosted MSVC toolset.


https://reviews.llvm.org/D22426

Files:
  lib/Driver/MSVCToolChain.cpp

Index: lib/Driver/MSVCToolChain.cpp
===
--- lib/Driver/MSVCToolChain.cpp
+++ lib/Driver/MSVCToolChain.cpp
@@ -454,19 +454,33 @@
   if (BinDir.empty())
 return false;
 
+  SmallString<128> X64BinDir = BinDir;
   switch (getArch()) {
   case llvm::Triple::x86:
+llvm::sys::path::append(X64BinDir, "amd64_x86");
 break;
   case llvm::Triple::x86_64:
-llvm::sys::path::append(BinDir, "amd64");
+llvm::sys::path::append(BinDir, "x86_amd64");
+llvm::sys::path::append(X64BinDir, "amd64");
 break;
   case llvm::Triple::arm:
-llvm::sys::path::append(BinDir, "arm");
+llvm::sys::path::append(BinDir, "x86_arm");
+llvm::sys::path::append(X64BinDir, "amd64_arm");
 break;
   default:
 // Whatever this is, Visual Studio doesn't have a toolchain for it.
 return false;
   }
+
+#if defined(_M_X64)
+  // If running x64-hosted Clang, choose the x64-hosted version of the MSVC
+  // toolset, if it exists.
+  if (llvm::sys::fs::exists(X64BinDir)) {
+path = X64BinDir.str();
+return true;
+  }
+#endif
+
   path = BinDir.str();
   return true;
 }


Index: lib/Driver/MSVCToolChain.cpp
===
--- lib/Driver/MSVCToolChain.cpp
+++ lib/Driver/MSVCToolChain.cpp
@@ -454,19 +454,33 @@
   if (BinDir.empty())
 return false;
 
+  SmallString<128> X64BinDir = BinDir;
   switch (getArch()) {
   case llvm::Triple::x86:
+llvm::sys::path::append(X64BinDir, "amd64_x86");
 break;
   case llvm::Triple::x86_64:
-llvm::sys::path::append(BinDir, "amd64");
+llvm::sys::path::append(BinDir, "x86_amd64");
+llvm::sys::path::append(X64BinDir, "amd64");
 break;
   case llvm::Triple::arm:
-llvm::sys::path::append(BinDir, "arm");
+llvm::sys::path::append(BinDir, "x86_arm");
+llvm::sys::path::append(X64BinDir, "amd64_arm");
 break;
   default:
 // Whatever this is, Visual Studio doesn't have a toolchain for it.
 return false;
   }
+
+#if defined(_M_X64)
+  // If running x64-hosted Clang, choose the x64-hosted version of the MSVC
+  // toolset, if it exists.
+  if (llvm::sys::fs::exists(X64BinDir)) {
+path = X64BinDir.str();
+return true;
+  }
+#endif
+
   path = BinDir.str();
   return true;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

2016-07-20 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo added a comment.

Just to make sure I'm clear on the consensus, the new plan is:

If clang.exe is x64-hosted and an x64-hosted MSVC toolchain is available, use 
the x64-hosted MSVC toolchain. Otherwise, use the x86-hosted MSVC toolchain.

Right?


https://reviews.llvm.org/D22426



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


Re: [PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

2016-07-15 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo added a comment.

In https://reviews.llvm.org/D22426#486100, @compnerd wrote:

> I imagine that at this point, most usage is still based around the x86 
> toolchain rather than x64 (I didnt even notice the x64 tools until recently). 
>  That is, any reason that we shouldnt be using x64 for x64, x64_x86 for x86, 
> and x64_arm for ARM?


Most usage is indeed x86-hosted. While the x64-hosted x64-targeting compiler 
has been available from the beginning of MSVC's x64 support, the x64-hosted 
x86-targeting toolset is relatively recent (VS 2102 or VS 2013, I think). In 
general, the x86-hosted compilers are marginally faster than the equivalent 
x64-hosted compiler, and since x86-hosted has always been the default, most 
developers don't switch to the x64-hosted toolset unless they run into code 
that won't compile or link without running out of memory space on the 
x86-hosted toolset. Also, the x64-hosted toolset won't run on machines running 
a 32-bit OS, which are more rare these days, but still exist. The existing 
Clang behavior would have failed on a 32-bit OS when targeting x64, though, so 
if we've gotten away with it this long, we're probably OK.

One reasonable solution would be to choose the toolset that is hosted on the 
same architecture as the host of clang.exe (e.g. x64-hosted Clang looks for 
x64-hosted MSVC). If this sounds good, I can make that change in a follow-up 
commit.


https://reviews.llvm.org/D22426



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


[PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

2016-07-15 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, majnemer, cfe-commits.
Herald added subscribers: rengolin, aemerson.

Clang was failing to find the ARM version of the MSVC link.exe, even though it 
could correctly find link.exe for x86 and x64. Clang looks in the 
%VCINSTALLDIR%\VC\bin directory for link.exe when targeting x86 (finding the 
x86-hosted, x86-targeting tools), the VC\bin\amd64 directory when targeting x64 
(finding the x64-hosted, x64-targeting tools), and the non-existent VC\bin\arm 
directory when targeting ARM (which is where the ARM-hosted tools would be if 
they existed). I just switched it to always look for the x86-hosted tools for 
all targets, in VC\bin\x86, VC\bin\x86_amd64, or VC\bin\x86_arm.


https://reviews.llvm.org/D22426

Files:
  lib/Driver/MSVCToolChain.cpp

Index: lib/Driver/MSVCToolChain.cpp
===
--- lib/Driver/MSVCToolChain.cpp
+++ lib/Driver/MSVCToolChain.cpp
@@ -457,10 +457,10 @@
   case llvm::Triple::x86:
 break;
   case llvm::Triple::x86_64:
-llvm::sys::path::append(BinDir, "amd64");
+llvm::sys::path::append(BinDir, "x86_amd64");
 break;
   case llvm::Triple::arm:
-llvm::sys::path::append(BinDir, "arm");
+llvm::sys::path::append(BinDir, "x86_arm");
 break;
   default:
 // Whatever this is, Visual Studio doesn't have a toolchain for it.


Index: lib/Driver/MSVCToolChain.cpp
===
--- lib/Driver/MSVCToolChain.cpp
+++ lib/Driver/MSVCToolChain.cpp
@@ -457,10 +457,10 @@
   case llvm::Triple::x86:
 break;
   case llvm::Triple::x86_64:
-llvm::sys::path::append(BinDir, "amd64");
+llvm::sys::path::append(BinDir, "x86_amd64");
 break;
   case llvm::Triple::arm:
-llvm::sys::path::append(BinDir, "arm");
+llvm::sys::path::append(BinDir, "x86_arm");
 break;
   default:
 // Whatever this is, Visual Studio doesn't have a toolchain for it.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D22293: Fix MSVC mangling of consecutive pack template arguments

2016-07-12 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, majnemer, cfe-commits.

When mangling a template specialization where two consecutive template 
arguments are both packs, MSVC inserts the separator "$$Z" between the two 
arguments to disambiguate between the case of { { int, int }, { int } } and { { 
int }, { int, int } }. I've updated Clang's MSVC mangler to do the same, and 
added a test case to check that the separator is inserted correctly.


http://reviews.llvm.org/D22293

Files:
  lib/AST/MicrosoftMangle.cpp
  test/CodeGenCXX/mangle-ms-cxx11.cpp

Index: test/CodeGenCXX/mangle-ms-cxx11.cpp
===
--- test/CodeGenCXX/mangle-ms-cxx11.cpp
+++ test/CodeGenCXX/mangle-ms-cxx11.cpp
@@ -318,3 +318,16 @@
 
 // CHECK-DAG: @"\01?unaligned_foo8@unaligned_foo8_S@@QFCEXXZ"
 
+template
+struct my_tuple {};
+
+template
+void print_tuples(const my_tuple& a, const my_tuple& b);
+
+void f() {
+  print_tuples(my_tuple(), my_tuple());
+  print_tuples(my_tuple(), my_tuple());
+}
+
+// CHECK-DAG: 
@"\01??$print_tuples@H$$ZHH@@YAXABU?$my_tuple@H@@ABU?$my_tuple@HH@@@Z"
+// CHECK-DAG: 
@"\01??$print_tuples@HH$$ZH@@YAXABU?$my_tuple@HH@@ABU?$my_tuple@H@@@Z"
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -357,7 +357,7 @@
   void mangleTemplateArgs(const TemplateDecl *TD,
   const TemplateArgumentList );
   void mangleTemplateArg(const TemplateDecl *TD, const TemplateArgument ,
- const NamedDecl *Parm);
+ const NamedDecl *Parm, bool );
 };
 }
 
@@ -1219,13 +1219,15 @@
  "size mismatch between args and parms!");
 
   unsigned Idx = 0;
+  bool PrevArgWasPack = false;
   for (const TemplateArgument  : TemplateArgs.asArray())
-mangleTemplateArg(TD, TA, TPL->getParam(Idx++));
+mangleTemplateArg(TD, TA, TPL->getParam(Idx++), PrevArgWasPack);
 }
 
 void MicrosoftCXXNameMangler::mangleTemplateArg(const TemplateDecl *TD,
 const TemplateArgument ,
-const NamedDecl *Parm) {
+const NamedDecl *Parm,
+bool ) {
   //  ::= 
   //::= 
   //::= 
@@ -1235,6 +1237,9 @@
   //::= $0A@
   //::= 
 
+  bool NeedsSeparatorBeforePack = PrevArgWasPack;
+  PrevArgWasPack = false;
+
   switch (TA.getKind()) {
   case TemplateArgument::Null:
 llvm_unreachable("Can't mangle null template arguments!");
@@ -1302,6 +1307,14 @@
 mangleExpression(TA.getAsExpr());
 break;
   case TemplateArgument::Pack: {
+PrevArgWasPack = true;
+if (NeedsSeparatorBeforePack) {
+  // If two consecutive template args are packs, we need to distinguish
+  // between {{int}, {int, int}} and {{int, int}, {int}}. We emit a
+  // separator ("$$Z") between the two packs to mark where one pack ends
+  // and the next begins.
+  Out << "$$Z";
+}
 ArrayRef TemplateArgs = TA.getPackAsArray();
 if (TemplateArgs.empty()) {
   if (isa(Parm) ||
@@ -1317,8 +1330,9 @@
   else
 llvm_unreachable("unexpected template parameter decl!");
 } else {
+  bool PrevArgInPackWasPack = false;
   for (const TemplateArgument  : TemplateArgs)
-mangleTemplateArg(TD, PA, Parm);
+mangleTemplateArg(TD, PA, Parm, PrevArgInPackWasPack);
 }
 break;
   }


Index: test/CodeGenCXX/mangle-ms-cxx11.cpp
===
--- test/CodeGenCXX/mangle-ms-cxx11.cpp
+++ test/CodeGenCXX/mangle-ms-cxx11.cpp
@@ -318,3 +318,16 @@
 
 // CHECK-DAG: @"\01?unaligned_foo8@unaligned_foo8_S@@QFCEXXZ"
 
+template
+struct my_tuple {};
+
+template
+void print_tuples(const my_tuple& a, const my_tuple& b);
+
+void f() {
+  print_tuples(my_tuple(), my_tuple());
+  print_tuples(my_tuple(), my_tuple());
+}
+
+// CHECK-DAG: @"\01??$print_tuples@H$$ZHH@@YAXABU?$my_tuple@H@@ABU?$my_tuple@HH@@@Z"
+// CHECK-DAG: @"\01??$print_tuples@HH$$ZH@@YAXABU?$my_tuple@HH@@ABU?$my_tuple@H@@@Z"
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -357,7 +357,7 @@
   void mangleTemplateArgs(const TemplateDecl *TD,
   const TemplateArgumentList );
   void mangleTemplateArg(const TemplateDecl *TD, const TemplateArgument ,
- const NamedDecl *Parm);
+ const NamedDecl *Parm, bool );
 };
 }
 
@@ -1219,13 +1219,15 @@
  "size mismatch between args and parms!");
 
   unsigned Idx = 0;
+  bool PrevArgWasPack = false;
   for (const TemplateArgument  : 

[PATCH] D22275: Support -fno-delayed-template-parsing in clang-cl.exe

2016-07-12 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, majnemer, cfe-commits.

This change adds support for the -fno-delayed-template-parsing option in 
clang-cl.exe. This allows developers using clang-cl.exe to opt out of emulation 
of MSVC's non-conformant template instantiation implementation while continuing 
to use clang-cl.exe for its emulation of cl.exe command-line options. The 
default behavior of clang-cl.exe (-fdelayed-template-parsing) is unchanged.

The MSVC Standard Library implementation uses clang-cl.exe with this switch in 
its tests to ensure that the library headers work on compilers with the 
conformant two-phase-lookup behavior.


http://reviews.llvm.org/D22275

Files:
  include/clang/Driver/Options.td

Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -813,7 +813,7 @@
"(default))">;
 def fdelayed_template_parsing : Flag<["-"], "fdelayed-template-parsing">, 
Group,
   HelpText<"Parse templated function definitions at the end of the "
-   "translation unit">,  Flags<[CC1Option]>;
+   "translation unit">,  Flags<[CC1Option, CoreOption]>;
 def fms_memptr_rep_EQ : Joined<["-"], "fms-memptr-rep=">, Group, 
Flags<[CC1Option]>;
 def fmodules_cache_path : Joined<["-"], "fmodules-cache-path=">, 
Group,
   Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
@@ -950,7 +950,7 @@
   Flags<[CoreOption]>;
 def fno_ms_compatibility : Flag<["-"], "fno-ms-compatibility">, Group,
   Flags<[CoreOption]>;
-def fno_delayed_template_parsing : Flag<["-"], 
"fno-delayed-template-parsing">, Group;
+def fno_delayed_template_parsing : Flag<["-"], 
"fno-delayed-template-parsing">, Group, Flags<[CC1Option, CoreOption]>;
 def fno_objc_exceptions: Flag<["-"], "fno-objc-exceptions">, Group;
 def fno_objc_legacy_dispatch : Flag<["-"], "fno-objc-legacy-dispatch">, 
Group;
 def fno_objc_weak : Flag<["-"], "fno-objc-weak">, Group, 
Flags<[CC1Option]>;


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -813,7 +813,7 @@
"(default))">;
 def fdelayed_template_parsing : Flag<["-"], "fdelayed-template-parsing">, Group,
   HelpText<"Parse templated function definitions at the end of the "
-   "translation unit">,  Flags<[CC1Option]>;
+   "translation unit">,  Flags<[CC1Option, CoreOption]>;
 def fms_memptr_rep_EQ : Joined<["-"], "fms-memptr-rep=">, Group, Flags<[CC1Option]>;
 def fmodules_cache_path : Joined<["-"], "fmodules-cache-path=">, Group,
   Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
@@ -950,7 +950,7 @@
   Flags<[CoreOption]>;
 def fno_ms_compatibility : Flag<["-"], "fno-ms-compatibility">, Group,
   Flags<[CoreOption]>;
-def fno_delayed_template_parsing : Flag<["-"], "fno-delayed-template-parsing">, Group;
+def fno_delayed_template_parsing : Flag<["-"], "fno-delayed-template-parsing">, Group, Flags<[CC1Option, CoreOption]>;
 def fno_objc_exceptions: Flag<["-"], "fno-objc-exceptions">, Group;
 def fno_objc_legacy_dispatch : Flag<["-"], "fno-objc-legacy-dispatch">, Group;
 def fno_objc_weak : Flag<["-"], "fno-objc-weak">, Group, Flags<[CC1Option]>;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D22273: Treat enumerator_too_large as an extension in MS ABI mode

2016-07-12 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo created this revision.
DaveBartolomeo added reviewers: rnk, cfe-commits.

When compiling as C targeting the MS ABI, but with -fno-ms-compatibility, an 
enumerator initializer that is not representable as an int is treated as an 
error. This is correct according to the C standard, but Clang already treats it 
as an extension both in -fms-compatibility mode and when compiling as C for 
non-MS ABI targets. It seemed odd that it would be treated as a hard error only 
in this one particular configuration, so I relaxed it to be an extension when 
targeting the MS ABI, regardless of MS compatibility mode.

There are dozens of occurrences of this issue in Windows SDK headers. By 
treating it as an extension, Clang users can include  in a C program 
without having to use -fms-compatibility.


http://reviews.llvm.org/D22273

Files:
  lib/Sema/SemaDecl.cpp

Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -14351,7 +14351,13 @@
   // we perform a non-narrowing conversion as part of converted 
constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (getLangOpts().MSVCCompat ||
+Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+  // Treat as an extension in MSVC compat mode or if using the
+  // MSVC ABI. We already treat the equivalent case in C as an
+  // extension if we're not in Microsoft mode. Several Windows
+  // headers define enums with initializers like 0x8000 and
+  // 0x.
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
   Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
 } else


Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -14351,7 +14351,13 @@
   // we perform a non-narrowing conversion as part of converted constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (getLangOpts().MSVCCompat ||
+Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+  // Treat as an extension in MSVC compat mode or if using the
+  // MSVC ABI. We already treat the equivalent case in C as an
+  // extension if we're not in Microsoft mode. Several Windows
+  // headers define enums with initializers like 0x8000 and
+  // 0x.
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
   Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
 } else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D20492: Clang support for __is_assignable intrinsic

2016-05-20 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo updated this revision to Diff 58014.
DaveBartolomeo added a comment.

Removed unnecessary braces.
Moved BTT_IsAssignable case to a more clear location.


http://reviews.llvm.org/D20492

Files:
  docs/LanguageExtensions.rst
  include/clang/Basic/TokenKinds.def
  include/clang/Basic/TypeTraits.h
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  test/PCH/cxx-traits.cpp
  test/PCH/cxx-traits.h

Index: test/PCH/cxx-traits.h
===
--- test/PCH/cxx-traits.h
+++ test/PCH/cxx-traits.h
@@ -1,69 +1,70 @@
-// Header for PCH test cxx-traits.cpp
-
-namespace n {
-
-template
-struct __is_pod { // expected-warning {{keyword '__is_pod' will be made available as an identifier for the remainder of the translation unit}}
-  enum { __value };
-};
-
-template
-struct __is_empty { // expected-warning {{keyword '__is_empty' will be made available as an identifier for the remainder of the translation unit}}
-  enum { __value };
-};
-
-template
-struct is_trivially_constructible {
-  static const bool value = __is_trivially_constructible(T, Args...);
-};
-
-struct __is_abstract {};  // expected-warning {{made available}}
-struct __is_arithmetic {};  // expected-warning {{made available}}
-struct __is_array {};  // expected-warning {{made available}}
-struct __is_base_of {};  // expected-warning {{made available}}
-struct __is_class {};  // expected-warning {{made available}}
-struct __is_complete_type {};  // expected-warning {{made available}}
-struct __is_compound {};  // expected-warning {{made available}}
-struct __is_const {};  // expected-warning {{made available}}
-struct __is_constructible {};  // expected-warning {{made available}}
-struct __is_convertible {};  // expected-warning {{made available}}
-struct __is_convertible_to {};  // expected-warning {{made available}}
-struct __is_destructible {};  // expected-warning {{made available}}
-struct __is_enum {};  // expected-warning {{made available}}
-struct __is_floating_point {};  // expected-warning {{made available}}
-struct __is_final {};  // expected-warning {{made available}}
-struct __is_function {};  // expected-warning {{made available}}
-struct __is_fundamental {};  // expected-warning {{made available}}
-struct __is_integral {};  // expected-warning {{made available}}
-struct __is_interface_class {};  // expected-warning {{made available}}
-struct __is_literal {};  // expected-warning {{made available}}
-struct __is_lvalue_expr {};  // expected-warning {{made available}}
-struct __is_lvalue_reference {};  // expected-warning {{made available}}
-struct __is_member_function_pointer {};  // expected-warning {{made available}}
-struct __is_member_object_pointer {};  // expected-warning {{made available}}
-struct __is_member_pointer {};  // expected-warning {{made available}}
-struct __is_nothrow_assignable {};  // expected-warning {{made available}}
-struct __is_nothrow_constructible {};  // expected-warning {{made available}}
-struct __is_nothrow_destructible {};  // expected-warning {{made available}}
-struct __is_object {};  // expected-warning {{made available}}
-struct __is_pointer {};  // expected-warning {{made available}}
-struct __is_polymorphic {};  // expected-warning {{made available}}
-struct __is_reference {};  // expected-warning {{made available}}
-struct __is_rvalue_expr {};  // expected-warning {{made available}}
-struct __is_rvalue_reference {};  // expected-warning {{made available}}
-struct __is_same {};  // expected-warning {{made available}}
-struct __is_scalar {};  // expected-warning {{made available}}
-struct __is_sealed {};  // expected-warning {{made available}}
-struct __is_signed {};  // expected-warning {{made available}}
-struct __is_standard_layout {};  // expected-warning {{made available}}
-struct __is_trivial {};  // expected-warning {{made available}}
-struct __is_trivially_assignable {};  // expected-warning {{made available}}
-struct __is_trivially_constructible {};  // expected-warning {{made available}}
-struct __is_trivially_copyable {};  // expected-warning {{made available}}
-struct __is_union {};  // expected-warning {{made available}}
-struct __is_unsigned {};  // expected-warning {{made available}}
-struct __is_void {};  // expected-warning {{made available}}
-struct __is_volatile {};  // expected-warning {{made available}}
-
-
-}
+// Header for PCH test cxx-traits.cpp
+
+namespace n {
+
+template
+struct __is_pod { // expected-warning {{keyword '__is_pod' will be made available as an identifier for the remainder of the translation unit}}
+  enum { __value };
+};
+
+template
+struct __is_empty { // expected-warning {{keyword '__is_empty' will be made available as an identifier for the remainder of the translation unit}}
+  enum { __value };
+};
+
+template
+struct is_trivially_constructible {
+  static const bool value = __is_trivially_constructible(T, Args...);
+};
+
+struct __is_abstract {};  // 

[PATCH] D20492: Clang support for __is_assignable intrinsic

2016-05-20 Thread Dave Bartolomeo via cfe-commits
DaveBartolomeo created this revision.
DaveBartolomeo added a reviewer: rnk.
DaveBartolomeo added a subscriber: cfe-commits.

MSVC now supports the __is_assignable type trait intrinsic, to enable easier 
and more efficient implementation of the Standard Library's is_assignable 
trait. As of Visual Studio 2015 Update 3, the VC Standard Library 
implementation uses the new intrinsic unconditionally. We had already 
implemented this trait for Clang/C2, so we're upstreaming the change so that 
mainline Clang can handle the new intrinsic as well.

The implementation is pretty straightforward, due to the previously existing 
__is_nothrow_assignable and __is_trivially_assignable. We handle 
__is_assignable via the same code as the other two, except that we skip the 
extra checks for nothrow or triviality.

http://reviews.llvm.org/D20492

Files:
  docs/LanguageExtensions.rst
  include/clang/Basic/TokenKinds.def
  include/clang/Basic/TypeTraits.h
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  test/PCH/cxx-traits.cpp
  test/PCH/cxx-traits.h

Index: test/PCH/cxx-traits.h
===
--- test/PCH/cxx-traits.h
+++ test/PCH/cxx-traits.h
@@ -1,69 +1,70 @@
-// Header for PCH test cxx-traits.cpp
-
-namespace n {
-
-template
-struct __is_pod { // expected-warning {{keyword '__is_pod' will be made available as an identifier for the remainder of the translation unit}}
-  enum { __value };
-};
-
-template
-struct __is_empty { // expected-warning {{keyword '__is_empty' will be made available as an identifier for the remainder of the translation unit}}
-  enum { __value };
-};
-
-template
-struct is_trivially_constructible {
-  static const bool value = __is_trivially_constructible(T, Args...);
-};
-
-struct __is_abstract {};  // expected-warning {{made available}}
-struct __is_arithmetic {};  // expected-warning {{made available}}
-struct __is_array {};  // expected-warning {{made available}}
-struct __is_base_of {};  // expected-warning {{made available}}
-struct __is_class {};  // expected-warning {{made available}}
-struct __is_complete_type {};  // expected-warning {{made available}}
-struct __is_compound {};  // expected-warning {{made available}}
-struct __is_const {};  // expected-warning {{made available}}
-struct __is_constructible {};  // expected-warning {{made available}}
-struct __is_convertible {};  // expected-warning {{made available}}
-struct __is_convertible_to {};  // expected-warning {{made available}}
-struct __is_destructible {};  // expected-warning {{made available}}
-struct __is_enum {};  // expected-warning {{made available}}
-struct __is_floating_point {};  // expected-warning {{made available}}
-struct __is_final {};  // expected-warning {{made available}}
-struct __is_function {};  // expected-warning {{made available}}
-struct __is_fundamental {};  // expected-warning {{made available}}
-struct __is_integral {};  // expected-warning {{made available}}
-struct __is_interface_class {};  // expected-warning {{made available}}
-struct __is_literal {};  // expected-warning {{made available}}
-struct __is_lvalue_expr {};  // expected-warning {{made available}}
-struct __is_lvalue_reference {};  // expected-warning {{made available}}
-struct __is_member_function_pointer {};  // expected-warning {{made available}}
-struct __is_member_object_pointer {};  // expected-warning {{made available}}
-struct __is_member_pointer {};  // expected-warning {{made available}}
-struct __is_nothrow_assignable {};  // expected-warning {{made available}}
-struct __is_nothrow_constructible {};  // expected-warning {{made available}}
-struct __is_nothrow_destructible {};  // expected-warning {{made available}}
-struct __is_object {};  // expected-warning {{made available}}
-struct __is_pointer {};  // expected-warning {{made available}}
-struct __is_polymorphic {};  // expected-warning {{made available}}
-struct __is_reference {};  // expected-warning {{made available}}
-struct __is_rvalue_expr {};  // expected-warning {{made available}}
-struct __is_rvalue_reference {};  // expected-warning {{made available}}
-struct __is_same {};  // expected-warning {{made available}}
-struct __is_scalar {};  // expected-warning {{made available}}
-struct __is_sealed {};  // expected-warning {{made available}}
-struct __is_signed {};  // expected-warning {{made available}}
-struct __is_standard_layout {};  // expected-warning {{made available}}
-struct __is_trivial {};  // expected-warning {{made available}}
-struct __is_trivially_assignable {};  // expected-warning {{made available}}
-struct __is_trivially_constructible {};  // expected-warning {{made available}}
-struct __is_trivially_copyable {};  // expected-warning {{made available}}
-struct __is_union {};  // expected-warning {{made available}}
-struct __is_unsigned {};  // expected-warning {{made available}}
-struct __is_void {};  // expected-warning {{made available}}
-struct __is_volatile