It's not the default with older Apple clang builds
and without it c++11 features don't work on at least OS X 10.7:
./src/core/lib/gprpp/ref_counted.h:28:10: fatal error: 'atomic' file not found
#include <atomic>
^~~~~~~~
I manually tested it on macOS 10.11 image and there was not a
regression.
This should fix the "Artifact Build MacOS (internal CI)" test failure.
There was a sub-optimality in the CAS operation. vjpai@ and
I decided to move to std::atomic.
This commit basically moves CQ data to C++ structures, and
makes grpc_cq_event_queue a proper c++ class called CQEventQueue.
Makes the public UserState property non-virtual and adds a protected
virtual UserStateCore that can be overridden. This follows the pattern
of the other members.
GCC allows this, but notably clang does not. Other systems,
like FreeBSD and some Linux distros ship with clang as default
compiler. While here, switch the approach to filtering out std
flag since the make workaround relies on GNU make syntax and
'make' binary could be bmake and/or gmake could be absent.
The idea to filter the flags was taken from an answer to this
Stack Overflow question:
https://stackoverflow.com/questions/15527611/how-do-i-specify-different-compiler-flags-in-distutils-for-just-one-python-c-ext
Bazel recognizes both "darwin" and "darwin_x86_64" as CPU values, and
the Apple Bazel rules currently recommend the latter for building
macOS targets. Until this is cleaned up, this change allows grpc to
build correctly when that configuration is used.
Fixes#17649.
We are planning to enable -Wextra-semi flag in our project but some
header files in gRPC have extra semicolons that violates the check and
blocks us from enabling the flag.
This change removes unnecessary semicolons in the code. Note that having
semicolon after the GRPC_ABSTRACT macro technically also violates the
check, but it's fine for us since they are not used in public headers,
and it will be confusing to have lines ending only with GRPC_ABSTRACT,
so I keep them as-is.