Update gcmole to a more recent clang/llvm.

Update gcmole to a more recent clang/llvm.

* Changes for 2.9:
     * Use CXX in Makefile instead of hardwired g++, we need a more
       modern GCC than 4.6 later, anyway.

* Changes for 3.0:
     * Use llvm namespace.
     * Diagnostic => DiagnosticsEngine.

* Changes for 3.1:
     * The BlockDeclRefExpr AST node is gone.
     * The structure of the CXXNewExpr AST node has changed.
     * Path changed from Release to Release+Asserts.
     * Use clang++ instead of -cc1, otherwise we lose the system include
       paths.

* Changes for 3.2:
     none needed

* Changes for 3.3:
     * Use lookup_iterator::begin/end instead of first/second.

* Changes for 3.4:
     * createItaniumMangleContext => ItaniumMangleContext::create.

* Changes for 3.5:
     * clang uses <type_traits> now, so -std=c++0x is needed.
     * Type-trait-related AST changes.
     * getCustomDiagID signature changed.
     * We must link the C++ library statically now.

R=mstarzinger@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=22972

[Sven Panne, 2014-08-06 13:51:54]

work in progress, just for entertainment... ;-)

[Michael Starzinger, 2014-08-06 13:57:31]

LGTM. But if we land this now I assume it will fail on the GCMole buildbot
because that one still has an outdated binary package. So we need to update the
buildbot first.

[Sven Panne, 2014-08-07 06:38:16]

[ I've put the other Michael onto this, too, confusing... ;-]

As Michi already mentioned, it's a bit unclear if this CL can be landed while
the bots still have their old clang-2.9-based gcmole, because the Lua script has
changed. It's quite possible that it still works, but I can't test this easily.

I think the right way to proceed is to make the bots use their own copy of the
(old) Lua script for now, this would be in sync with using their own copy of
gcmole. As it is, the build system is inconsistent, because the bots don't pick
up the bootstrap.sh/... changes.

To use a new pre-built gcmole, the system gcc on the bots has to match the one
on the build machine, i.e. gcc 4.6.3, otherwise gcmole won't find the system
includes. 2 ways to proceed: Either build gcmole on the bots (note that you'll
need a gcc >= 4.7 in addition to the system gcc, too) or make sure that gcc
versions are in sync.

Now I'll extend this CL to hopefully cover clang-3.5, the one used by Chrome...

[Michael Starzinger, 2014-08-07 08:05:16]

IMHO making the bots use their own copy of gcmole.lua would be a step backwards.
I spent a couple of hours so that they actually used the one in the repository
so that the only thing on the bots not taken from the repository was the clang
binary. The duplicated lua script ran out of sync too often, using the one from
the repo was an improvement for everyone maintaining the GCMole buildbot.

[Michael Starzinger, 2014-08-07 08:42:27]

As per offline investigation: The new Lua script in this CL still works with the
old Clang binary. So this means we can land this CL without changing the Clang
binary package on the buildbot.

[Sven Panne, 2014-08-07 11:51:29]

CL finished: gcmole is based on clang 3.5 now. I think we can land this and
distribute the binary onto our bots... PTAL

[Michael Starzinger, 2014-08-07 12:49:44]

Still LGTM.

[Sven Panne, 2014-08-07 12:57:02]

Committed patchset #2 manually as 22972 (presubmit successful).