implementation of std::marker::Send is not general enough

[oroulet]

So I got into that shit.
Just adding to a rather simle async method the lines

    let build = DataTypeTreeBuilder::new(|f| f.namespace <= 10);
    build.build2(&session_clone).await;

lead to the horrible error:

error: implementation of `std::marker::Send` is not general enough
   --> src/grab_motion_io.rs:78:85
    |
78  |       async fn connect(cfg: &config::MotionServiceConfig) -> Result<Self::MotionSelf> {
    |  _____________________________________________________________________________________^
79  | |         tracing::info!("connecting to UA server");
80  | |         let grab_ua = grab_ua::connect(&cfg.robot_connection).await?;
81  | |         tracing::info!("connecting to Force Sensor");
...   |
136 | |         Ok(motion)
137 | |     }
    | |_____^ implementation of `std::marker::Send` is not general enough
    |
    = note: `std::marker::Send` would have to be implemented for the type `&plc_udp_receiver::PlcReceiver`
    = note: ...but `std::marker::Send` is actually implemented for the type `&'0 plc_udp_receiver::PlcReceiver`, for some specific lifetime `'0`

error: implementation of `std::marker::Send` is not general enough
   --> src/grab_motion_io.rs:78:85
    |
78  |       async fn connect(cfg: &config::MotionServiceConfig) -> Result<Self::MotionSelf> {
    |  _____________________________________________________________________________________^
79  | |         tracing::info!("connecting to UA server");
80  | |         let grab_ua = grab_ua::connect(&cfg.robot_connection).await?;
81  | |         tracing::info!("connecting to Force Sensor");
...   |
136 | |         Ok(motion)
137 | |     }
    | |_____^ implementation of `std::marker::Send` is not general enough
    |
    = note: `std::marker::Send` would have to be implemented for the type `&tokio::sync::Mutex<std::option::Option<tokio::task::JoinHandle<std::result::Result<(), anyhow::Error>>>>`
    = note: ...but `std::marker::Send` is actually implemented for the type `&'0 tokio::sync::Mutex<std::option::Option<tokio::task::JoinHandle<std::result::Result<(), anyhow::Error>>>>`, for some specific lifetime `'0`

warning: `rust-motion` (lib) generated 1 warning

googling around this seems to be a rust compiler issue. rust-lang/futures-rs#1451 with no clear bypass.

Debugging a bit more I found out that the issue seems to be the lines: https://github.com/FreeOpcUa/rust-opcua/blob/master/opcua-client/src/custom_types/mod.rs#L123

 futures::pin_mut!(stream);
 stream.try_next().await;

And in that code we read: https://github.com/FreeOpcUa/rust-opcua/blob/master/opcua-client/src/browser/browse.rs#L22

  // Streams are really hard.
        // This code isn't ideal. Ideally most of this would be inside a method in
        // `BrowserExecution`, but that isn't possible due to there being no way
        // to name the future. We could box it, but that hits a compiler bug.
        // This can hopefully be improved once either RTN, TAIT or ATPIT lands.
        
        ` ` `
        
        
 So if anyone has any ideas about what is wrong or simply too hard for the compiler here... it would be great..
 @einarmo seems to be your code

[oroulet]

also I am really unsure how to recreate the situation creating that issue. I have that issue on some proprietary code base I do not own but so far I did not manage to reproduce outside

[einarmo]

Indeed, browser isn't send, but I think you may be vastly overestimating how fixable this is. When I say in that comment I hit a compiler bug, I meant I hit nothing else I failed to make this compile with any amount of cloning and other insanity, it just doesn't compile. I will look into it again, but you may just have to make do without this feature.

[einarmo]

Incredibly I think I found a solution. Turns out the problem is in send_with_retry, I think related to the GAT on UARequest. It frankly makes no sense, but if you box the future returned by send everything works out, at least in my tests.

Try #23 and see if that solves your issue?

[einarmo]

Closed with #23