Resolve another collision between Win32 and atomicops MemoryBarrier
Windows defines a MemoryBarrier macro which clashes with a MemoryBarrier
construct in base/atomicops.h. Depending on the order of includes,
various code can be affected. Currently the Windows jumbo builder is broken
in ppapi/proxy because of a sequence of
1. include base/atomicops.h (undefs Memorybarrier which does nothing)
2. include ppapi_messages.h -> base/sync_socket.h -> windows.h
(Now MemoryBarrier is a macro)
3. include gpu/command_buffer/common/command_buffer_shared.h ->
3a -> include base/atomicops.h (does nothing because include guards)
3b -> uses base::subtle::MemoryBarrier which is a macro and poof.
Normally the undef MemoryBarrier is near the Windows.h include but
it's tricky to put in base since there is also code that needs the
macro so undeffing it in too generic code can make things worse.
Technically this was triggered by the removal of the PPB_compositor
APIs but only because the jumbo chunks changed when files were deleted.
Reviewed-by: Antoine Labour <email@example.com>
Reviewed-by: Kinuko Yasuda <firstname.lastname@example.org>
Commit-Queue: Daniel Bratell <email@example.com>
1 file changed