Remove an unneeded Mac include.

Remove an unneeded Mac include.

BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=66136

[Mark Mentovai, 2010-11-15 16:47:07]

non-lgtm

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc
File base/file_path.cc (right):

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc#newcode993
base/file_path.cc:993: CFStringCreateWithBytesNoCopy(
Hello kitty.

[Mark Mentovai, 2010-11-15 16:48:08]

Oh, the include was for CoreServices, not CoreFoundation. You should just change
it.

[TVL, 2010-11-15 17:02:00]

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc
File base/file_path.cc (right):

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc#newcode22
base/file_path.cc:22: #include "base/mac/scoped_cftyperef.h"
fyi - this pulls in corefoundation

[TVL, 2010-11-15 17:08:20]

new diff up

[Mark Mentovai, 2010-11-15 17:11:31]

LGTM

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc
File base/file_path.cc (right):

http://codereview.chromium.org/5017001/diff/1/base/file_path.cc#newcode22
base/file_path.cc:22: #include "base/mac/scoped_cftyperef.h"
TVL wrote:
> fyi - this pulls in corefoundation

I know, but our style is:

“if x.cc depends on y.h, either x.cc or x.h needs to #include y.h.”

It’s not enough for x.cc to #include z.h and for z.h to #include y.h. That’s too
tenuous a relationship, it’s dependent on z.h internals, and it’s likely to
cause trivial changes to z.h’s implementation details to make other things fall
apart.

[TVL, 2010-11-15 17:16:15]

On 2010/11/15 17:11:31, Mark Mentovai wrote:
> LGTM
> 
> http://codereview.chromium.org/5017001/diff/1/base/file_path.cc
> File base/file_path.cc (right):
> 
> http://codereview.chromium.org/5017001/diff/1/base/file_path.cc#newcode22
> base/file_path.cc:22: #include "base/mac/scoped_cftyperef.h"
> TVL wrote:
> > fyi - this pulls in corefoundation
> 
> I know, but our style is:
> 
> “if x.cc depends on y.h, either x.cc or x.h needs to #include y.h.”
> 
> It’s not enough for x.cc to #include z.h and for z.h to #include y.h. That’s
too
> tenuous a relationship, it’s dependent on z.h internals, and it’s likely to
> cause trivial changes to z.h’s implementation details to make other things
fall
> apart.

Agreed.  Was just answering why it hadn't blown up.