'ready' function for client services clashes with 'ready' rpc method

[rib]

Bug Report

Version

├── tonic v0.1.0-alpha.6
└── tonic-build v0.1.0-alpha.6

Crates

tonic-build

Description

I started looking at using tonic with this Agones SDK protocol today and found that the generated code wouldn't compile because there were multiple 'ready' functions for the service. (ref:

tonic/tonic-build/src/client.rs

Line 33 in 4471a5f

pub async fn ready(&mut self) -> Result<(), tonic::Status> {

)

I guess it's going to be relatively likely for "ready" to conflict with more than just this protocol, so I wonder if it's possible for this to be changed to a less common name?

[LucioFranco]

Do you have an example error message I could see, there should only be one ready generated per struct which as far as I know shouldn't violate rust's model.

[rib]

Yep, here's the original compilation failure I hit:

error[E0201]: duplicate definitions with name `ready`:
   --> /home/rib/src/realfit-server/target/debug/build/realfit-server-808a11d4a9ed943b/out/agones.dev.sdk.rs:133:9
    |
124 | /         pub async fn ready(&mut self) -> Result<(), tonic::Status> {
125 | |             self.inner.ready().await.map_err(|e| {
126 | |                 tonic::Status::new(
127 | |                     tonic::Code::Unknown,
...   |
130 | |             })
131 | |         }
    | |_________- previous definition of `ready` here
132 |           #[doc = " Call when the GameServer is ready"]
133 | /         pub async fn ready(
134 | |             &mut self,
135 | |             request: impl tonic::IntoRequest<super::Empty>,
136 | |         ) -> Result<tonic::Response<super::Empty>, tonic::Status> {
...   |
140 | |             self.inner.unary(request.into_request(), path, codec).await
141 | |         }
    | |_________^ duplicate definition

error: aborting due to previous error

For more information about this error, try `rustc --explain E0201`.
error: could not compile `realfit-server`.

So, the issue is that there can be an rpc method named 'ready' which tonic isn't in control of, which can be in addition to the one generated by tonic.

This is the workaround I'm currently using, which fixes the issue for me:
rib@ee60bc7
(though I didn't give the alternate naming any real thought, or consider if there's maybe a different way of structuring things to better avoid the possibility of clashing)

[LucioFranco]

Ah I see the rpc name is clashing...fun...I'll have to think about this one. It may not be worth it to expose a async fn ready. The solution might be to actually just expose the poll_ready. This is quite unfortunate though :(

[pruthvikar]

Could you put ready in a trait and use the Universal Function Call Syntax to handle clashes?

[LucioFranco]

@pruthvikar that is an interesting idea! That could work, we could also just expose it as poll_ready and then in each async fn just call poll_fn.