This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016).
Detailed description.
Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate.
This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following:
```python
proto_library(
name = "my_proto",
srcs = ["my.proto"],
)
cc_proto_library(
name = "my_cc_proto",
deps = [":my_proto"]
)
cc_grpc_library(
name = "my_cc_grpc",
srcs = [":my_proto"],
deps = [":my_cc_proto"]
)
```
This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`).
Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs.
The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`).
The `cc_proto_library` is kept backward-compatible with the old version.
In most of the cases, as we hope, RPCs shouldn't have errors.
But, in grpc_error_get_status() we treat GRPC_ERROR_NONE
similar to other errors, and waste quite a few cycles.
This patch is part of a larger performance improvements.
On client side, this particular code path accounts for 0.5%+.
Currently, we keep increasing the slice pointer, and
can run out of the inline space or try to realloc the
non-inline space unncessarily.
Simply set slices back to the start of the base_slices,
when we know the length of the slice_buffer is 0.
Note: This will change the behavior of undo_take_first(),
if user tries to grow the slie_buffer, between take_first()
and undo_take_first() calls. That said, it's not legal
to add something to the buffer in between take_first()
and undo_take_first(). So, we shouldn't have any issue.