llvm-svn: 143770

llvm-svn: 143769

llvm-svn: 143768

llvm-svn: 143767

llvm-svn: 143766

llvm-svn: 143765

llvm-svn: 143764

Serialized diagnostics: pull category name serialization into diagnostic blocks.  The goal is to remove BLOCK_STRINGS so that the bitcode file can potentially be streamed.

llvm-svn: 143763

llvm-svn: 143762

llvm-svn: 143761

Serialized diagnostics: encode a 24 bit version number as part of the "magic number" of serialized diagnostics.

llvm-svn: 143760

llvm-svn: 143759

llvm-svn: 143758

llvm-svn: 143757

llvm-svn: 143754

Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.

llvm-svn: 143752

as the system include interface before I start adding implementations of
it to individual ToolChain implementations.

llvm-svn: 143751

llvm-svn: 143748

GC managed non-objc object memory.

llvm-svn: 143747

create an attributed type with same type as the original type.

We effectively retain the source info that an ownership attribute was present but the attribute
is ignored by not modifying the type that it was applied to.

llvm-svn: 143736

Enable -flimit-debug-info by default. Now, clang lazily emits debug info for structs. Original behavior can be restored using -fno-limit-debug-info.

llvm-svn: 143733

rdar://10383444

llvm-svn: 143732

llvm-svn: 143725

Fixes a bug where enumerator type is not this
fixed type. // rdar://10381507

llvm-svn: 143724

llvm-svn: 143720

llvm-svn: 143706

llvm-svn: 143704

llvm-svn: 143701

object that it receives in ARC.

llvm-svn: 143700

This allows the migrator to visit and fix them.

llvm-svn: 143699

llvm-svn: 143698

llvm-svn: 143696

handling logic of the generic ToolChain. This flag, despite its name,
has *nothing* to do with the GCC flag '-nostdlib' that relates
(exclusively) to the linking behavior. It is a most unfortunate name in
that regard...

It is used to tell InitHeaderSearch.cpp *which* set of C++ standard
library header search paths to use -- those for libstdc++ from GCC's
installation, or those from a libc++ installation. As this logic is
hoisted out of the Frontend, and into the Driver as part of this
ToolChain, the generic method will be overridden for the platform, where
it can implement this logic directly. As such, hiding the CC1 option
passing in the generic space is a natural fit despite the odd naming.

Also, expand on the comments to clarify whats going on, and tidy up the
Tools.cpp code now that its simpler.

llvm-svn: 143687

implementation in the driver. This cleans up the signature and semantics
of the include flag adding component of the toolchain. Another step to
ready it for holding all the InitHeaderSearch logic.

llvm-svn: 143686

the rest of the mess in InitHeaderSearch.cpp. We could hoist it into the
driver profitably, removing more noise from the driver -> frontend
communication.

llvm-svn: 143685

and the C++ include management routine from the proper place when
forming preprocessor options in the driver. This is the first step to
teaching the driver to manage all of the header search paths. Currently,
these methods remain just stubs in the abstract toolchain. Subsequent
patches will flesh them out with implementations for various toolchains
based on the current code in InitHeaderSearch.cpp.

llvm-svn: 143684

initializations which refer indirectly to elements of the object being
initialized.

llvm-svn: 143680

to allow us to implement the C++11 rule that a non-active union member can't be
read, and use it to implement subobject access for string literals.

llvm-svn: 143677

be at the same address as another object, we do know it won't alias a null
pointer.

llvm-svn: 143674

llvm-svn: 143667