[fidl] 32 to 64 bits Ordinals: propagate gen_ords
When a `Call` is made, we need to propagate the alternative ordinals
since the response may use another ordinal. Say client is using the new
64b scheme, it may emit a call with that ordinal, which the server is
able to match (has both ord and gen), but then responds with the ord.
Test: no behavior change, this is not used by bindings yet
Change-Id: I33b7ec4c717e58e83ce16591122f6ad5c8fb6179
diff --git a/src/syscall/zx/fidl/interface.go b/src/syscall/zx/fidl/interface.go
index 359cf8a..239293e 100644
--- a/src/syscall/zx/fidl/interface.go
+++ b/src/syscall/zx/fidl/interface.go
@@ -46,7 +46,7 @@
Send(ordinal uint64, req Message) error
// TODO(FIDL-524): Remove `gen_ordinal` post-ordinal migration.
Recv(ordinal uint64, resp Message, gen_ordinal ...uint64) error
- Call(ordinal uint64, req Message, resp Message) error
+ Call(ordinal uint64, req Message, resp Message, gen_ordinal ...uint64) error
}
// Stub represents a generated type which wraps the server-side implementation of a
@@ -167,7 +167,7 @@
// Call sends the request over the channel with the specified ordinal
// and synchronously waits for a response. It then writes the response into the
// response.
-func (p *ChannelProxy) Call(ordinal uint64, req Message, resp Message) error {
+func (p *ChannelProxy) Call(ordinal uint64, req Message, resp Message, gen_ordinal ...uint64) error {
respb := messageBytesPool.Get().([]byte)
resph := messageHandlesPool.Get().([]zx.Handle)
@@ -189,5 +189,5 @@
return err
}
- return unmarshalForOrdinal(ordinal, respb[:cnb], resph[:cnh], resp)
+ return unmarshalForOrdinal(ordinal, respb[:cnb], resph[:cnh], resp, gen_ordinal...)
}
