Fix copy-pasto in naming of LAST_MS_INHERITANCE[_ATTR]

Richard Smith pointed this out over a month ago.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181830 91177308-0d34-0410-b5e6-96231b3b80d8
Provide operator<< for stream output of DeclarationNames

ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181832 91177308-0d34-0410-b5e6-96231b3b80d8
Fix clang -Werror build due to -Wreorder violation introduced in r181825

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181834 91177308-0d34-0410-b5e6-96231b3b80d8
When computing the size of large arrays, use char units instead of bits.
This prevents an overflow and assertion when the number of bits cannot be
stored in 64-bits.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181839 91177308-0d34-0410-b5e6-96231b3b80d8
Don't mark a type specifier as "owned" if there is no declaration to own.

This simplifies error recovery elsewhere, eliminating the crash in
<rdar://problem/13853540>.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181846 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C [diagnostics] [QOI], when method is not
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181847 91177308-0d34-0410-b5e6-96231b3b80d8
Add static_cast to assertion to silence sign/unsigned comparison warning.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181849 91177308-0d34-0410-b5e6-96231b3b80d8
Unbreaking the MSVC build by adding an include.  It broke with r181832.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181853 91177308-0d34-0410-b5e6-96231b3b80d8
Move a test that requires 64-bit mode to a separate test with a triple in
the run line.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181854 91177308-0d34-0410-b5e6-96231b3b80d8
Use 'env' in tests that set environment variables.

Patch by David Fang!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181861 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: Improve codegen for vget_low_* and vget_high_ intrinsics.

These intrinsics use the __builtin_shuffle() function to extract the
low and high half, respectively, of a 128-bit NEON vector. Currently,
they're defined to use bitcasts to simplify the emitter, so we get code
like:
uint16x4_t vget_low_u32(uint16x8_t __a) {
  return (uint32x2_t) __builtin_shufflevector((int64x2_t) __a,
                                              (int64x2_t) __a,
                                              0);
}

While this works, it results in those bitcasts going all the way through
to the IR, resulting in code like:
  %1 = bitcast <8 x i16> %in to <2 x i64>
  %2 = shufflevector <2 x i64> %1, <2 x i64> undef, <1 x i32>
  %zeroinitializer
  %3 = bitcast <1 x i64> %2 to <4 x i16>

We can instead easily perform the operation directly on the input vector
like:

uint16x4_t vget_low_u16(uint16x8_t __a) {
  return __builtin_shufflevector(__a, __a, 0, 1, 2, 3);
}

Not only is that much easier to read on its own, it also results in
cleaner IR like:

  %1 = shufflevector <8 x i16> %in, <8 x i16> undef,
                     <4 x i32> <i32 0, i32 1, i32 2, i32 3>

This is both easier to read and easier for the back end to reason
about effectively since the operation is obfuscating the source with
bitcasts.

rdar://13894163

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181865 91177308-0d34-0410-b5e6-96231b3b80d8
Use correct types for SPARC v9.

It's an LP64 platform.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181867 91177308-0d34-0410-b5e6-96231b3b80d8
Use only explicit bool conversion operator

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.

One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181869 91177308-0d34-0410-b5e6-96231b3b80d8
Improve formatting of function types.

The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.

Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After:  #define DEREF_AND_CALL_F(parameter) f(*parameter)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181870 91177308-0d34-0410-b5e6-96231b3b80d8
Remove diagnostics from clang-format.

We only ever implemented one and that one is not actually all that
helpful (e.g. gets incorrectly triggered by macros).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181871 91177308-0d34-0410-b5e6-96231b3b80d8
Don't merge one-line functions in weird brace styles.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181872 91177308-0d34-0410-b5e6-96231b3b80d8
Break function declarations after multi-line return types.

Before:
template <typename A>
SomeLoooooooooooooooooooooongType<
    typename some_namespace::SomeOtherType<A>::Type> Function() {}

After:
template <typename A>
SomeLoooooooooooooooooooooongType<
    typename some_namespace::SomeOtherType<A>::Type>
Function() {}

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181877 91177308-0d34-0410-b5e6-96231b3b80d8
Better diagnostics for string initialization.

This commit improves Clang's diagnostics for string initialization.
Where it would previously say:

  /tmp/a.c:3:9: error: array initializer must be an initializer list
  wchar_t s[] = "Hi";
          ^
  /tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
  char t[] = L"Hi";
       ^

It will now say

  /tmp/a.c:3:9: error: initializing wide char array with non-wide string literal
  wchar_t s[] = "Hi";
          ^
  /tmp/a.c:4:6: error: initializing char array with wide string literal
  char t[] = L"Hi";
       ^

As a bonus, it also fixes the fact that Clang would previously reject
this valid C11 code:

  char16_t s[] = u"hi";
  char32_t t[] = U"hi";

because it would only recognize the built-in types for char16_t and
char32_t, which do not exist in C.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181880 91177308-0d34-0410-b5e6-96231b3b80d8
Improve recognition of template definitions.

In the long run, this will probably be better fixed by a proper
expression parser..

Before:
  template <typename F>
  Matcher(const Matcher<F> & Other,
          typename enable_if_c < is_base_of<F, T>::value &&
              !is_same<F, T>::value > ::type * = 0)
      : Implementation(new ImplicitCastMatcher<F>(Other)) {}

After:
  template <typename F>
  Matcher(const Matcher<F> & Other,
          typename enable_if_c<is_base_of<F, T>::value &&
                               !is_same<F, T>::value>::type * = 0)
      : Implementation(new ImplicitCastMatcher<F>(Other)) {}

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181884 91177308-0d34-0410-b5e6-96231b3b80d8
Don't put short namespace on a single line.

Before:
namespace abc { class SomeClass; }
namespace def { void someFunction() {} }

After:
namespace abc {
class Def;
}
namespace def {
void someFunction() {}
}

Rationale:
a) Having anything other than forward declaration on the same line
   as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
   from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
   does not affect readability.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181887 91177308-0d34-0410-b5e6-96231b3b80d8