eclipse / paho.mqtt.rust

paho.mqtt.rust
Other
511 stars 102 forks source link

Dependencies: Bump async-channel to v2.0.0 #227

Open Altair-Bueno opened 2 months ago

Altair-Bueno commented 2 months ago

Changelog: https://github.com/smol-rs/async-channel/blob/master/CHANGELOG.md#version-200

Bumping the dependency manually causes the following errors:

cargo test --features vendored-ssl
   Compiling paho-mqtt v0.13.0-pre.0 (/tmp/paho.mqtt.rust)
error[E0277]: `PhantomPinned` cannot be unpinned
   --> examples/async_subscribe_v5.rs:111:40
    |
111 |         while let Some(msg_opt) = strm.next().await {
    |                                        ^^^^ within `async_channel::_::__Origin<'_, Option<Message>>`, the trait `Unpin` is not implemented for `PhantomPinned`, which is required by `AsyncReceiver<Option<Message>>: Unpin`
    |
    = note: consider using the `pin!` macro
            consider using `Box::pin` if you need to access the pinned value outside of the current scope
note: required because it appears within the type `async_channel::_::__Origin<'_, Option<Message>>`
   --> /home/compux72/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-channel-2.2.1/src/lib.rs:485:1
    |
485 | / pin_project! {
486 | |     /// The receiving side of a channel.
487 | |     ///
488 | |     /// Receivers can be cloned and shared among threads. When all receivers associat...
...   |
515 | |     }
516 | | }
    | |_^
    = note: required for `AsyncReceiver<Option<Message>>` to implement `Unpin`
note: required by a bound in `futures::StreamExt::next`
   --> /home/compux72/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.30/src/stream/stream/mod.rs:275:15
    |
273 |     fn next(&mut self) -> Next<'_, Self>
    |        ---- required by a bound in this associated function
274 |     where
275 |         Self: Unpin,
    |               ^^^^^ required by this bound in `StreamExt::next`
    = note: this error originates in the macro `$crate::__pin_project_make_unpin_impl` which comes from the expansion of the macro `pin_project` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: `PhantomPinned` cannot be unpinned
   --> examples/async_subscribe_v5.rs:111:47
    |
111 |         while let Some(msg_opt) = strm.next().await {
    |                                              -^^^^^
    |                                              ||
    |                                              |within `async_channel::_::__Origin<'_, Option<Message>>`, the trait `Unpin` is not implemented for `PhantomPinned`, which is required by `Next<'_, AsyncReceiver<Option<Message>>>: std::future::IntoFuture`
    |                                              help: remove the `.await`
    |
    = note: consider using the `pin!` macro
            consider using `Box::pin` if you need to access the pinned value outside of the current scope
note: required because it appears within the type `async_channel::_::__Origin<'_, Option<Message>>`
   --> /home/compux72/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-channel-2.2.1/src/lib.rs:485:1
    |
485 | / pin_project! {
486 | |     /// The receiving side of a channel.
487 | |     ///
488 | |     /// Receivers can be cloned and shared among threads. When all receivers associat...
...   |
515 | |     }
516 | | }
    | |_^
    = note: required for `AsyncReceiver<Option<Message>>` to implement `Unpin`
    = note: required for `Next<'_, AsyncReceiver<Option<Message>>>` to implement `futures::Future`
    = note: required for `Next<'_, AsyncReceiver<Option<Message>>>` to implement `std::future::IntoFuture`
    = note: this error originates in the macro `$crate::__pin_project_make_unpin_impl` which comes from the expansion of the macro `pin_project` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `paho-mqtt` (example "async_subscribe_v5") due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
fpagliughi commented 2 months ago

I haven't looked at the async channels past 2.0. But I've started refactoring the options and data structs to be more Rust-y. Get rid of the FFI and self-referential pinning in the structs that the apps use, and convert them to FFI data in the call that sends them down to the C lib. The goal is to make the library's API fully Rust and then eventually replace the internal implementation with 100% Rust, removing the dependency on the C library. With the amount of free time I have, that may take a while, but it's the goal.

Anyway, the initial conversion of the structs may help make them easier to pass through the channels. If that's the problem here.

Altair-Bueno commented 2 months ago

Well, actually the solution is far simpler:

diff --git a/examples/async_subscribe.rs b/examples/async_subscribe.rs
index a3d5050..13712bd 100644
--- a/examples/async_subscribe.rs
+++ b/examples/async_subscribe.rs
@@ -71,7 +71,7 @@ fn main() {

     if let Err(err) = block_on(async {
         // Get message stream before connecting.
-        let mut strm = cli.get_stream(25);
+        let mut strm = std::pin::pin!(cli.get_stream(25));

         // Define the set of options for the connection
         let lwt = mqtt::Message::new(
diff --git a/examples/async_subscribe_v5.rs b/examples/async_subscribe_v5.rs
index 295c0eb..99e30ac 100644
--- a/examples/async_subscribe_v5.rs
+++ b/examples/async_subscribe_v5.rs
@@ -73,7 +73,7 @@ fn main() {

     if let Err(err) = block_on(async {
         // Get message stream before connecting.
-        let mut strm = cli.get_stream(25);
+        let mut strm = std::pin::pin!(cli.get_stream(25));

         // Define the set of options for the connection
         let lwt = mqtt::Message::new(

AsyncChannel now is !Unpin which forces users to pin themselves. Basically is a breaking change for consumers but the library itself is unaffected.

The motivation behind this change is to reduce compile times, dependencies and so on because async-channel gets duplicated with multiple versions when paired with crates like smol

fpagliughi commented 2 months ago

OK. I'll have a look at that. I'll probably maintain parallel paths of the bigger (slowly evolving) changes, and keeping the mainline up to date.