target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793

-Disable -pedantic-errors when migrating per Jordan's suggestion.
-Use llvm_move() per John's suggestion.

llvm-svn: 158785

The default global placement new just returns the pointer it is given.
Note that other custom 'new' implementations with placement args are not
guaranteed to do this.

In addition, we need to invalidate placement args, since they may be updated by
the allocator function. (Also, right now we don't properly handle the
constructor inside a CXXNewExpr, so we need to invalidate the placement args
just so that callers know something changed!)

This invalidation is not perfect because CallOrObjCMessage doesn't support
CXXNewExpr, and all of our invalidation callbacks expect that if there's no
CallOrObjCMessage, the invalidation is happening manually (e.g. by a direct
assignment) and shouldn't affect checker-specific metadata (like malloc state);
hence the malloc test case in new-fail.cpp. But region values are now
properly invalidated, at least.

The long-term solution to this problem is to rework CallOrObjCMessage into
something more general, rather than the morass of branches it is today.

<rdar://problem/11679031>

llvm-svn: 158784

[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires a cast

to something like:

[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires casting 'bool' to 'double'

This is way better to fully understand the warning.
rdar://11705106

llvm-svn: 158783

llvm-svn: 158782

for "hard" ARC errors, not warnings.

rdar://11691437

llvm-svn: 158781

Unbreak GCC build: GCC doesn't like clang::Parser::CommentHandler and class clang::CommentHandler to have same name.

llvm-svn: 158780

llvm-svn: 158778

llvm-svn: 158777

* Escaped # and < characters in Doxygen comments as needed;
* Removed a Doxygen comment in HeaderSearch.cpp that was redundant with
  the corresponding comment in the header file.

llvm-svn: 158776

Also add a couple of unit tests to check the invalid-PCH error messages
to satisfy PR4568 and for the assertion (introduced in r149918 and fixed
in r158769) that would cause clang to crash when given an empty PCH.

llvm-svn: 158772

* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang

llvm-svn: 158771

llvm-svn: 158768

caused a crash in an obscure case. On the plus side, it caused me to catch
another bug by inspection.

llvm-svn: 158767

llvm-svn: 158763

attributes into the ThreadSafetyAttributes group, where the other
warnings currently live.

llvm-svn: 158761

Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.

llvm-svn: 158759

name as an existing ivar since this is common source of error
when people remove @synthesize to take advantage of autosynthesis. 
// rdar://11671080

llvm-svn: 158756

Reapplying the changes from r158717 as they were rolled back to avoid merge conflicts from a separate problematic patch.

llvm-svn: 158750

The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.

llvm-svn: 158749

types to actually includes the value, rather than saying <uninitialized>.

llvm-svn: 158745

llvm-svn: 158744

llvm-svn: 158741

llvm-svn: 158740

also being sufficiently conformant to LLVM's coding standards.

llvm-svn: 158739

initializer need be null initialized before initializer takes
hold, just like any other initialized retainable object pointer. 
// rdar://11016025

llvm-svn: 158738

rdar://11684107

llvm-svn: 158734

llvm-svn: 158733

r158085 added some logic to track predefined declarations.  The main reason we
had predefined declarations in the input was because the __builtin_va_list
declarations were injected into the preprocessor input.  As of r158592 we 
explicitly build the __builtin_va_list declarations.  Therefore the predefined
decl tracking is no longer needed.

llvm-svn: 158732

llvm-svn: 158729

filed, but still missing the preprocessed source and associated run script.
rdar://11684107

llvm-svn: 158727

Improves parsing and semantic analysis for MS __declspec attributes.  This includes support for the align (which fixes PR12631).

llvm-svn: 158717

(Fixes radar://11691035 PR13140)

llvm-svn: 158703

Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.

Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.

I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.

llvm-svn: 158700

It turns out SourceManager treating the "one-past-the-end" location as invalid,
but then failing to set the invalid flag properly.

llvm-svn: 158699

ObjCInterfaceDec::lookupInstanceMethod to make sure we check categories as well
and update related tests.

rdar://11695288

llvm-svn: 158697

option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.

llvm-svn: 158694

because it expects a reference and receives a non-l-value.

For example, given:

  int foo(int &);
  template<int x> void b() { foo(x); }

clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.

llvm-svn: 158691

the compiler predefines buffer.  These are essentially part of
the Objective-C language.

llvm-svn: 158690

Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).

This removes the warning entirely from uses in the main source file in C++.

llvm-svn: 158689