clang/win: Enable most of -Wmicrosoft.

clang/win: Enable most of -Wmicrosoft.

-Wmicrosoft-unqualified-friend still fires in one place in ICU,
I'll enable it once I've fixed that.

-Wno-microsoft-enum-value doesn't look like a very useful
warning, maybe we should improve the warning instead of
enabling it.

BUG=505296
R=rnk@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/c3c872b12c094d27d5044f49d735099f54c188ea

[Nico, 2015-08-24 15:09:31]

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

[Nico, 2015-08-24 15:09:31]

The try job for patch set 1 shows where this warning still fires (
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang_dbg/bui...
)

[Reid Kleckner, 2015-08-24 15:47:32]

lgtm

I don't think there's much we can improve about the enum warning, other than
turning it off by default. It's pointing out that this enum *will* have a
different sign in other compilers, but in practice that never appears to be an
issue.

[Nico, 2015-08-24 15:58:31]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-08-24 15:58:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1311693002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1311693002/20001

[Nico, 2015-08-24 15:59:31]

On 2015/08/24 15:47:32, Reid Kleckner wrote:
> lgtm
> 
> I don't think there's much we can improve about the enum warning, other than
> turning it off by default. It's pointing out that this enum *will* have a
> different sign in other compilers, but in practice that never appears to be an
> issue.

I thought we could emit it when enums that contain such values are compared, not
when they're defined. Then it'd only fire when it's actually a problem. (I
haven't tried that or thought much about it though; maybe it won't work for some
reason.)

[Reid Kleckner, 2015-08-24 16:15:44]

On 2015/08/24 15:59:31, Nico wrote:
> I thought we could emit it when enums that contain such values are compared,
not
> when they're defined. Then it'd only fire when it's actually a problem. (I
> haven't tried that or thought much about it though; maybe it won't work for
some
> reason.)

Sounds good to me. :)

[Nico, 2015-08-24 16:34:29]

Committed patchset #2 (id:20001) manually as
c3c872b12c094d27d5044f49d735099f54c188ea (presubmit successful).