Bug 1320179 - Part 3: Define LOGLEVEL_0 unconditionally in protobuf on windows, r=fitzgen

This brings the workaround for the GOOGLE_LOG(ERROR) problem when ERROR is
defined as `0` by wingdi.h in line with our workaround in the chromium sandbox
code. (http://searchfox.org/mozilla-central/rev/381a7b8f8a78b481336cfa384cb0a5536e217e4a/security/sandbox/chromium/base/logging.h#334-346)

The other patches on this bug triggered a build problem where in some situations
ERROR would be undefined when the LogLevel enum is being defined, while ERROR
was defined at a callsite. By unconditionally defining ERROR on windows and
including the LOGLEVEL_0 enum variant, we can avoid this issue and fix the
associated build bustage.

MozReview-Commit-ID: 3XFHf1FqHBr
This commit is contained in:
Michael Layzell 2017-04-05 16:40:58 -04:00
parent df411f4313
commit c21cba1385

View File

@ -588,7 +588,7 @@ enum LogLevel {
LOGLEVEL_DFATAL = LOGLEVEL_FATAL
#endif
#ifdef ERROR
#ifdef _WIN32
// ERROR is defined as 0 on some windows builds, so `GOOGLE_LOG(ERROR, ...)`
// expands into `GOOGLE_LOG(0, ...)` which then expands into
// `someGoogleLogging(LOGLEVEL_0, ...)`. This is not ideal, because the
@ -596,6 +596,10 @@ enum LogLevel {
// `someGoogleLogging(LOGLEVEL_ERROR, ...)` instead. The workaround to get
// everything building is to simply define LOGLEVEL_0 as LOGLEVEL_ERROR and
// move on with our lives.
//
// We also define ERROR the same way that the Windows SDK does for
// consistency.
#define ERROR 0
, LOGLEVEL_0 = LOGLEVEL_ERROR
#endif
};