Roll Clang 214024:216630 (+216684) and switch to CMake (try 2)

Roll Clang 214024:216630 (+216684) and switch to CMake (try 2)

This updates Chromium's clang version to r216630 with
r216684 cherry-picked to fix an ASan issue.

It also changes the build script for Clang to use CMake
instead of Autoconf. The ASan team say this configuration
is better tested, and it also makes us consistent with
the Windows Clang build which already uses CMake.

BUG=400849
R=thakis@chromium.org
TBR=brettw

Committed: https://chromium.googlesource.com/chromium/src/+/3853ffa861dc43537f23c21a3fc4104c6f08c3a2

[hans, 2014-09-16 17:51:14]

Try 1 (https://codereview.chromium.org/453513004) was reverted due to
-Wundefined-bool-conversion errors in the gn debug build.

Fix is in the BUILD.gn file. Please take a look.

[Nico, 2014-09-16 17:54:27]

thakis@chromium.org changed reviewers:
+ brettw@chromium.org

[Nico, 2014-09-16 17:54:28]

lgtm

(usual technique is to upload the unmodified patch set first, and then the fix
in patch set 2, then it's easy to see the change)

brettw is build/foo/gn owner, so you need his approval too. Since this just
copies something from the gyp build that I understand, it's fine to tbr= him on
this, I think.

[hans, 2014-09-16 17:56:36]

On 2014/09/16 17:54:28, Nico (hiding) wrote:
> lgtm
> 
> (usual technique is to upload the unmodified patch set first, and then the fix
> in patch set 2, then it's easy to see the change)

will keep that in mind for the next time (try 3?)

> 
> brettw is build/foo/gn owner, so you need his approval too. Since this just
> copies something from the gyp build that I understand, it's fine to tbr= him
on
> this, I think.

sgtm.

[commit-bot: I haz the power, 2014-09-16 18:00:47]

Patchset 1 (id:??) landed as
https://crrev.com/3853ffa861dc43537f23c21a3fc4104c6f08c3a2
Cr-Commit-Position: refs/heads/master@{#295099}

[hans, 2014-09-16 18:00:51]

Committed patchset #1 (id:1) manually as 3853ffa (presubmit successful).

[Dirk Pranke, 2014-09-16 19:51:32]

On 2014/09/16 18:00:51, hans wrote:
> Committed patchset #1 (id:1) manually as 3853ffa (presubmit successful).

This CL seems to have broken the Mac 10.6 Tests bot on the chromium.webkit
waterfall:

https://build.chromium.org/p/chromium.webkit/builders/Mac10.6%20Tests/builds/...

so I'm reverting it ... Sorry!

[brettw, 2014-09-16 19:59:29]

This is fine, but if comparison to null happens in asserts, what about when we
compile asserts in release mode a la DCHECK_ALWAYS_ON?

[hans, 2014-09-16 20:05:32]

On 2014/09/16 19:59:29, brettw wrote:
> This is fine, but if comparison to null happens in asserts, what about when we
> compile asserts in release mode a la DCHECK_ALWAYS_ON?

Then I think the warning is correct and useful, as LLVM can optimize the check
away.

In practice, the assert's where this currently fires is in Skia, using their
ASSERT macro. I assume that's only enabled in debug builds.