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 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 removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
Compiling Gecko with libc++ and GCC 4.9 on Android runs into a problem.
The protobuf #includes and libc++ result in preprocessed code that looks
something like:
/* via <iterator> */
namespace std {
namespace __1 {
}
using namespace __1 __attribute__((__strong__));
}
namespace std { namespace __1 {
template <class _Iter>
class __wrap_iter
{
...
template <class _Tp, class _Alloc> friend class vector;
...
};
} // namespace __1
} // namespace std
/* via <vector> */
namespace std { namespace __1 {
template <class _Tp, class _Alloc>
class _LIBCPP_TYPE_VIS_ONLY vector : ...
{ ... };
} // namespace __1
} // namespace std
and the problem is that GCC doesn't understand that the forward
declaration of vector inside __wrap_iter is forward-declaring the actual
vector class; it thinks it's declaring something else.
Hacking <iterator> to include _LIBCPP_TYPE_VIS_ONLY for the forward
declaration doesn't help. What does help is including <vector> earlier
than <iterator>, so the __wrap_iter forward declaration picks up the
correct definition of std::vector, and makes everything happy. It's
possible that there are other places that could get this same treatment,
but this one place was the only one I needed to modify to make things
go.
Use google protocol buffer to handle our package in LayerScope.
Note: LayerScopePacket.pb.h and LayerScopePacket.pb.cc were
generated by version 2.4.1.
