-
Notifications
You must be signed in to change notification settings - Fork 520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change generated functions signatures to remove type parameters #1045
Change generated functions signatures to remove type parameters #1045
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good. Just a one comment: You should add a test to confirm your example works.
@caspermeijn I thought about it, that seem to be a good practice, but this test will only fail if somebody will add the generic type parameter with the same name (e.g. Actually, I think that a comment about this issue near the |
You could at least proof that your problem is addressed. When someone else finds another shadowing issue, then they could extend the test with their case. I would like to see your example as a test. |
@caspermeijn Alright, what is the best place to put this test? I'm not really familiar with the prost project structure, can you help me with that? |
You could do something similar to this: https://github.com/tokio-rs/prost/blob/master/tests/src/no_unused_results.proto If you search for |
The test is
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. This is a breaking change, so it has to wait for the next major release. Thank you for your contribution.
…t of ::prost::Message trait)
@caspermeijn latest commit changes the rest of |
Thank you. I am sorry to keep finding more stuff to do: In I think when doing this breaking change, we should do all of them at once. |
I did try to make these changes within
/// Helper function which abstracts reading a length delimiter prefix followed
/// by decoding values until the length of bytes is exhausted.
pub fn merge_loop<T, M, B>(
value: &mut T,
buf: &mut B,
ctx: DecodeContext,
mut merge: M,
) -> Result<(), DecodeError>
where
M: FnMut(&mut T, &mut B, DecodeContext) -> Result<(), DecodeError>,
B: Buf,
{
...
pub fn merge<M, B>(
wire_type: WireType,
msg: &mut M,
buf: &mut B,
ctx: DecodeContext,
) -> Result<(), DecodeError>
where
M: Message,
B: Buf,
{
check_wire_type(WireType::LengthDelimited, wire_type)?;
ctx.limit_reached()?;
merge_loop(
msg,
buf,
ctx.enter_recursion(),
|msg: &mut M, buf: &mut B, ctx| {
let (tag, wire_type) = decode_key(buf)?;
msg.merge_field(tag, wire_type, buf, ctx)
},
)
} Also, these functions are doing tight-loop decoding and may gain some performance benefits from static dispatch. There are also no way these functions type parameters may shadow user-defined types. You still think to make these changes where it is possible? |
I agree those two complex |
64f64bd
to
4f01b11
Compare
Yes, you're right, for some reason I thought that this will do a dynamic dispatch. I did the changes you wanted; there are 6 more places where the buffer is type parametrized (search for |
That looks good. Thank you for this cleanup. We could always do the |
Fixes #1042