commit 6c88f12e63fd786c7b9de7ccc91fedfa84e7087b
author Yifei Teng <yifeit@google.com> Tue May 17 00:31:41 2022 +0000
committer Fuchsia Internal LUCI <fuchsia-internal-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue May 17 00:31:41 2022 +0000
tree 2b7c4a19954fc673e3c4b57baeef7989f159425f
parent 5bea418ef311043ae1c6457078293c38c22ea3ee

[fidl][cpp] Start of natural sync calls

Adds fidl::SyncClient and fidl::Call following the sketch in
https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/lib/fidl/cpp/docs/structure-of-unified-cpp-fidl-bindings.md#natural-api_synchronous.

We already have two code paths for making a synchronous call, one for
Zircon channel (which requires the caller to provide storage), and
another for driver (whose messages bring along an arena for storage).
Those code paths also automatically decode the message as part of the
call, which doesn't work for natural types with their own decoding
logic.

To not end up with 4 different code paths (whether caller provides
storage X whether decoding is in-place), this CL starts a generalized
storage concept, outlined below:

- OutgoingMessage::Call always takes a MessageStorageViewBase*.
- For a Zircon channel, the caller passes ChannelMessageStorageView,
  which references some buffer span and handle spans.
- For a driver channel, the caller will pass a DriverStorageView,
  which references a |fdf::Arena*| that can hold the received arena
  backing the received message. (To be added in a future CL).
- No more auto-decoding within OutgoingMessage::Call. Both wire types
  and natural types will be symmetrical and each add their own decoding
  logic afterwards.

Because the change cuts across bprosnitz@'s generated code serialization
changes, I did not migrate every existing usage of
OutgoingMessage::Call to the new code path. That will follow once we've
landed the big encoding/decoding changes.

Bug: 60240
Bug: 100472
Change-Id: I6318021ebfe9b677b4801c7ea9d650272ce88a54
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/679151
Reviewed-by: Benjamin Prosnitz <bprosnitz@google.com>
Commit-Queue: Yifei Teng <yifeit@google.com>