llvm-svn: 129541

Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::".

Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro.

llvm-svn: 129540

statement, and expression pointers. While these shouldn't happen, it's
better to be safe in libclang.

llvm-svn: 129539

// rdar://9208404

llvm-svn: 129536

completion, look through block pointer and function pointer types to the
result type of the block/function. Fixes <rdar://problem/9282583>.

llvm-svn: 129535

AAPCS+VFP), similar to fastcall / stdcall / whatevercall seen on x86.

In particular, all library functions should always be AAPCS regardless of floating point ABI used.

llvm-svn: 129534

Name mangling of late-specified return types doesn't work if the return type references the argument types:

  template<typename T> auto f(T a) -> decltype(a.foo());

Since this is the primary reason for the introduction of this feature, downgrade implementation status to "Some examples work".

llvm-svn: 129533

llvm-svn: 129525

diagnosing it as an error rather than looping infinitely. Also,
explicitly disallow @defs in Objective-C++. Fixes <rdar://problem/9260136>.

llvm-svn: 129521

Chained PCH: Remember when additional specializations are added to a function template from a previous PCH. Fixes the only crasher when using massive chains on Clang's Sema component. We still have some incomplete codegen there.

llvm-svn: 129516

llvm-svn: 129515

llvm-svn: 129514

The ASTReader created by -chain-include used the generated PCH buffers in the wrong order. The effect was that all but the first chain-include files was ignored for subsequent compilations.

llvm-svn: 129513

llvm-svn: 129499

functionality intended.

llvm-svn: 129496

DiagnosticBuilder::AddFixItHint: they will be dropped along with any
other (possibly valid) fixits later.

llvm-svn: 129495

named by the nested-name-specifier is same or base of the class in which the member expression appears.

It seems we also had an ill-formed test case, mon dieu! Fixes rdar://8576107.

llvm-svn: 129493

in functionality intended.

llvm-svn: 129491

is 1 element smaller than the string, because we can just strip off the last
null character. This matches GCC.

llvm-svn: 129490

llvm-svn: 129488

llvm-svn: 129486

built clang binary that is used by the test. Build systems that use
symlinks for build outputs will fail these assertions otherwise.

llvm-svn: 129482

// rdar://9091893

llvm-svn: 129481

llvm-svn: 129475

llvm-svn: 129473

defined in a macro. // rdar://9091893

llvm-svn: 129465

Removing the unaligned load tests from builtins-x86.c since they're generated by a regular 'load' now.

llvm-svn: 129464

From Vassil Vassilev: Give external source's last resort lookup a chance, even if an identifier could resolve to a builtin.

llvm-svn: 129438

llvm-svn: 129434

llvm-svn: 129433

evaluated and unevaluated contexts. Add some testing of sizeof and
typeid.

Both of the typeid tests added here were triggering warnings previously.
Now the one false positive is suppressed without suppressing the warning
on actually buggy code.

llvm-svn: 129431

llvm-svn: 129430

take it!

I wasn't able to get __builtin_ia32_loaddqu to transform into an unaligned
load...I'll have to look into it further.

llvm-svn: 129427

llvm-svn: 129426

In Microsoft mode, within class scope, if a CXXScopeSpec's type is equal to the type of one of the base classes then downgrade the missing typename error to a warning. Up to now this is the only case I found where MSVC doesn't require "typename" at class scope. Really strange!
This fixes 1 error when parsing the MSVC 2008 header files.
Example:

template<class T> class A {
public:
  typedef int TYPE;
};
template<class T> class B : public A<T> {
public:
  A<T>::TYPE a; // no typename required because A<T> is a base class.
};

llvm-svn: 129425

llvm-svn: 129424

llvm-svn: 129420

undergoes preprocessing.

llvm-svn: 129414

objective-c instead of crashing in IRgen.
// rdar://9154582.

llvm-svn: 129412

there is no reason to align them higher.
 - This roughly matches llvm-gcc's r126913.
 - It is an open question whether or not we should do this for cstring's in
   general (code size vs optimization potential), for now we just match llvm-gcc
   until someone wants to run some experiments.

llvm-svn: 129410