Creating release_30 branch

git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142038 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142113:
------------------------------------------------------------------------
r142113 | void | 2011-10-15 23:43:18 -0700 (Sat, 15 Oct 2011) | 1 line

Enable CREATE_SUBDIRS for a performance win, because there are a lot of files being generated.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142115 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142133:
------------------------------------------------------------------------
r142133 | chandlerc | 2011-10-16 03:54:30 -0700 (Sun, 16 Oct 2011) | 30 lines

Clean up some cruft in the library path searching logic by making
'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.

Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.

Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:

  /lib/../../lib32
  /usr/lib/../../lib32
  /usr/lib/x86_64-linux-gnu/../..lib32

Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.

I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142174 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142134:
------------------------------------------------------------------------
r142134 | chandlerc | 2011-10-16 04:05:04 -0700 (Sun, 16 Oct 2011) | 1 line

Fix a silly bug introduced in r142133.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142175 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142349:
------------------------------------------------------------------------
r142349 | d0k | 2011-10-18 03:10:08 -0700 (Tue, 18 Oct 2011) | 4 lines

Use llvm::Triple's methods to parse FreeBSD version numbers.

Who could've thought that FreeBSD would ever reach version 10!
Patch from Dimitry Andric.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142366 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142187:
------------------------------------------------------------------------
r142187 | dgregor | 2011-10-17 07:55:37 -0700 (Mon, 17 Oct 2011) | 6 lines

When building a module, use the macro definitions on the command line
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142428 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142474:
------------------------------------------------------------------------
r142474 | dgregor | 2011-10-18 22:47:46 -0700 (Tue, 18 Oct 2011) | 5 lines

This new field was introduced in clang-c in r141277

Python needs this in its structure definition so it allocates enough
memory. From Anders Waldenborg!

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142722 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142476:
------------------------------------------------------------------------
r142476 | dgregor | 2011-10-18 22:50:34 -0700 (Tue, 18 Oct 2011) | 2 lines

Add TypeKind.CONSTANTARRAY, from  Anders Waldenborg!

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142723 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r142918:
------------------------------------------------------------------------
r142918 | theraven | 2011-10-25 03:12:21 -0700 (Tue, 25 Oct 2011) | 3 lines

Change an int64_t to an intptr_t so that we don't end up with crashes in the back end on large classes on 32-bit.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@142953 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes an intermittent bug that I finally got a good test case for in GNU ObjC.
Patch by David Chisnall.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143270 91177308-0d34-0410-b5e6-96231b3b80d8
Patch for PR9614. By Rafael Espindola.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143301 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143344:
------------------------------------------------------------------------
r143344 | chandlerc | 2011-10-31 01:42:24 -0700 (Mon, 31 Oct 2011) | 14 lines

Fix part of PR11223 and probably a few dups as well. This teaches the
library search logic to "properly" handle multiarch installations. I've
tested this on both Debian unstable and the latest Ubuntu which both use
this setup, and this appears to work largely the same way as GCC does.
It isn't exactly the same, but it is close enough and more principled in
its behavior where it differs. This should resolve any failures to find
'crt1.o' etc on Debian-based Linux distributions. If folks find more
cases where we fail, please file bugs and CC me.

Test cases for all of the debian silliness are waiting both to simplify
the process of merging these down into the 3.0 release, and because
they're so crazy I haven't yet been able to really produce a fake tree
that represents what we need to test for. I'll eventually add them
though.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143432 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143345:
------------------------------------------------------------------------
r143345 | chandlerc | 2011-10-31 01:42:27 -0700 (Mon, 31 Oct 2011) | 7 lines

Add "just one more" include path to the monstrosity that is our header
search logic. The Debian multiarch seems to have completely changed from
when these were originally added, and I'd like to remove a bunch of
them, but I'll be lazy and delay that until this logic is hoisted into
the driver where it belongs.

This should resolve PR11223.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143433 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r143684 | chandlerc | 2011-11-04 00:12:53 -0700 (Fri, 04 Nov 2011) | 7 lines

Add a system include management interface to the toolchain, and call it
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.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143926 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143686:
------------------------------------------------------------------------
r143686 | chandlerc | 2011-11-04 00:34:47 -0700 (Fri, 04 Nov 2011) | 4 lines

Sink the handling of -fobjc-arc-cxxlib to live with the other -fobjc-arc
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.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143927 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143687:
------------------------------------------------------------------------
r143687 | chandlerc | 2011-11-04 00:43:33 -0700 (Fri, 04 Nov 2011) | 16 lines

Sink the strange '-stdlib=...' flag handling into the C++ include
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.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143928 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143751:
------------------------------------------------------------------------
r143751 | chandlerc | 2011-11-04 16:49:01 -0700 (Fri, 04 Nov 2011) | 3 lines

Switch the C++ include interface in the ToolChain to use the same naming
as the system include interface before I start adding implementations of
it to individual ToolChain implementations.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143929 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143752:
------------------------------------------------------------------------
r143752 | chandlerc | 2011-11-04 16:49:05 -0700 (Fri, 04 Nov 2011) | 5 lines

Begin the migration of header search logic to the driver, starting with
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.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143930 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143798:
------------------------------------------------------------------------
r143798 | chandlerc | 2011-11-05 01:30:29 -0700 (Sat, 05 Nov 2011) | 16 lines

Add two flags to the CC1 layer that I was hoping to avoid. We need to
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.

There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.

Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_30@143931 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r143801:
------------------------------------------------------------------------
r143801 | chandlerc | 2011-11-05 02:24:44 -0700 (Sat, 05 Nov 2011) | 20 lines

Fix a significant oversight in my move of MSVC includes to the driver:
actually manage the builtin header file includes as well as the system
ones.

This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.

Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.

Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
------------------------------------------------------------------------


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