[Solved] stream::Fuse and futures::Fuse type confusion from tokio_core::Receiver

help
1

I've run into another issue while converting to Futures. I'm getting a conflict in types, possibly because of mixed usage of Streams and Futures, but I'm not sure.

https://github.com/bluejekyll/trust-dns/blob/bfry/futures/src/client/client_future.rs#L48

Is causing this error in nightly (I switched from stable for the excellent error messages):

error[E0308]: mismatched types
  --> src/client/client_future.rs:48:84
   |
48 |       let fuse: StreamFuse<Receiver<(Message, Complete<ClientResult<Message>>)>> = receiver.fuse();
   |                                                                                    ^^^^^^^^^^^^^^^ expected struct `futures::stream::Fuse`, found struct `futures::Fuse`
   |
   = note: expected type `futures::stream::Fuse<tokio_core::Receiver<(op::message::Message, futures::Complete<std::result::Result<op::message::Message, error::client_error::Error>>)>>`
   = note:    found type `futures::Fuse<Box<futures::Future<Error=std::io::Error, Item=tokio_core::Receiver<(op::message::Message, futures::Complete<std::result::Result<op::message::Message, error::client_error::Error>>)>> + Send>>`

I've been pedantic in my type usage to make sure everything is clear. What is very confusing is that tokio_core::Receiver should return a stream::Fuse, but claims to be returning a futures::Fuse.

I have an example from a different piece of code, doing something similar and compiles no problem:

https://github.com/bluejekyll/trust-dns/blob/bfry/futures/src/udp/udp_client_stream.rs#L59

the type of the one working is:

stream::Fuse<Receiver<Vec<u8>>>

and the one that is not:

stream::Fuse<Receiver<(Message, Complete<ClientResult<Message>>)>>

both are established through similar calls to LoopHandle::channel. I am up to date with the futures and tokio_core repos.

cc: @alexcrichton

2

FYI, because I want to clean up the send section of this code I wrapped this in a Peekable, and then the type error went away. That doesn't seem like it should have fixed anything though...

3

Looks like the "receiver" and "rx" names may have gotten mixed up? It looks like the closure may want to call "rx.fuse" instead of "receiver.fuse"

1 Like
4

One case of not using shadowing where I should. I looked at this for so long and kept assuming the wrong thing was the issue.

After changing that everything works as expected. Thanks for the time on such a basic error :blush: