Reland "Roll DEPS to class-dump 3.5"

Reland "Roll DEPS to class-dump 3.5"

Removes some build warnings.

Moves the class-dump repo to a github auto-mirror instead of a mirror
that needs to be manually updated.

This also requires that the class-dump.gyp file move from the
third-party repo into the main source tree. Note that the file
structure of the class-dump source changed so the .gyp had to be
updated. For comparison, the old .class-dump.gyp can be found at
https://chromium.googlesource.com/chromium/deps/class-dump/+/master/class-dump.gyp

Original CL: https://codereview.chromium.org/1106993002
This CL ignores some warnings that occur in the Xcode build.

BUG=318160

[lliabraa, 2015-05-21 17:06:10]

lliabraa@chromium.org changed reviewers:
+ justincohen@chromium.org

[justincohen, 2015-05-21 17:10:13]

lgtm

[justincohen, 2015-05-21 17:16:01]

Talked to Lane offline about using   'chromium_code': 0, instead, although it's
unclear why all the other third_party folders don't use this...

[lliabraa, 2015-05-21 18:21:19]

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

[lliabraa, 2015-05-21 18:21:19]

When OS=ios and chromium_code=0 we set TREAT_WARNINGS_AS_ERRORS=NO. However, the
iossim/class-dump code builds with OS=mac, which only sets this flag for
official builds (when chromium_code=0). So just setting chromium_code=0 does not
avoid the warnings.

@thakis - does that mean I should land this as is (i.e. specifically ignoring
warnings in class-dump that we don't care about) or do you have a better
suggestion that would use chromium_code?

In any case, it's not clear to me why this only happens with GYP_GENERATOR=xcode
(and not GYP_GENERATOR=ninja)

[Nico, 2015-05-21 18:32:14]

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

[Nico, 2015-05-21 18:32:15]

On 2015/05/21 18:21:19, lliabraa wrote:
> When OS=ios and chromium_code=0 we set TREAT_WARNINGS_AS_ERRORS=NO. However,
the
> iossim/class-dump code builds with OS=mac, which only sets this flag for
> official builds (when chromium_code=0). So just setting chromium_code=0 does
not
> avoid the warnings.
> 
> @thakis - does that mean I should land this as is (i.e. specifically ignoring
> warnings in class-dump that we don't care about) or do you have a better
> suggestion that would use chromium_code?

* Chromium builds should be warning free. If that's not true in the iOS build,
that's a bug of the iOS build. We shouldn't make it worse.

* Turning off warnings we don't care (i.e. warnings that are harmless) about for
third-party code is fine (see many third_party/*/*.gyp files for examples).
there should be a short comment for each warning saying why it's ok to ignore it
and why it's needed (see examples)

* But making that dependent on the generator doesn't make any sense to me – I'm
guessing you want to check clang_xcode instead?

* Usually we put gyp files next to the project – third_party/class-dump/foo.gyp
would be the gyp file, third_party/class-dump/src the depsed-in code.

Is Wno-arc-bridge-casts-disallowed-in-nonarc really a harmless warning we can
just ignore?

We almost certainly want to keep Wpartial-availability enabled for all targets
(+erikchen)

Wno-objc-missing-super-calls doesn't look super harmless at first sight either –
maybe you could fix the warning upstream instead of suppressing it?

[lliabraa, 2015-05-22 17:57:02]

On 2015/05/21 18:32:15, Nico wrote:
> On 2015/05/21 18:21:19, lliabraa wrote:
> > When OS=ios and chromium_code=0 we set TREAT_WARNINGS_AS_ERRORS=NO. However,
> the
> > iossim/class-dump code builds with OS=mac, which only sets this flag for
> > official builds (when chromium_code=0). So just setting chromium_code=0 does
> not
> > avoid the warnings.
> > 
> > @thakis - does that mean I should land this as is (i.e. specifically
ignoring
> > warnings in class-dump that we don't care about) or do you have a better
> > suggestion that would use chromium_code?
> 
> * Chromium builds should be warning free. If that's not true in the iOS build,
> that's a bug of the iOS build. We shouldn't make it worse.
> 
> * Turning off warnings we don't care (i.e. warnings that are harmless) about
for
> third-party code is fine (see many third_party/*/*.gyp files for examples).
> there should be a short comment for each warning saying why it's ok to ignore
it
> and why it's needed (see examples)
> 
> * But making that dependent on the generator doesn't make any sense to me –
I'm
> guessing you want to check clang_xcode instead?
> 
> * Usually we put gyp files next to the project
– third_party/class-dump/foo.gyp
> would be the gyp file, third_party/class-dump/src the depsed-in code.

Yes - I tried that [1] but the bots were not able to process the change because
of the file structure of the new and old repo. See
https://code.google.com/p/chromium/issues/detail?id=481644

[1] see patch set 2 of original CL:
https://codereview.chromium.org/1106993002/#ps20001

> 
> Is Wno-arc-bridge-casts-disallowed-in-nonarc really a harmless warning we can
> just ignore?
> 
> We almost certainly want to keep Wpartial-availability enabled for all targets
> (+erikchen)

I'm guessing this is because Mac deployment target is set to 10.6 but these APIs
require 10.8. IIRC all the iOS build infra is on 10.9

> 
> Wno-objc-missing-super-calls doesn't look super harmless at first sight either
–
> maybe you could fix the warning upstream instead of suppressing it?

I agree these warnings sound dubious, but they do not affect our use case.

What I don't understand is why building with ninja does not output any warnings
but building with xcode does. The only difference I seen in the clang invocation
is the -Werror