rayon-rs / rayon

Rayon: A data parallelism library for Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

rayon-core tests fail to build.

plugwash opened this issue · comments

Hi.

While trying to update the rayon-core crate in Debian, I discovered that it's tests failed to build, I was able to reproduce the issue with the latest git version as well, by running "cargo test" in the rayon-core subdirectory of a git checkout.

error[E0277]: `Sender<usize>` cannot be shared between threads safely
  --> rayon-core/src/broadcast/test.rs:19:28
   |
19 |     crate::spawn_broadcast(move |ctx| tx.send(ctx.index()).unwrap());
   |     ---------------------- ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |                      |
   |     |                      `Sender<usize>` cannot be shared between threads safely
   |     |                      within this `[closure@rayon-core/src/broadcast/test.rs:19:28: 19:38]`
   |     required by a bound introduced by this call
   |
   = help: within `[closure@rayon-core/src/broadcast/test.rs:19:28: 19:38]`, the trait `Sync` is not implemented for `Sender<usize>`

I bisected this issue and it seems to have been introduced in 191ade2

mpsc::Sender gained Sync in Rust 1.72. Rayon supports Rust 1.63 for the library itself, but that doesn't include its tests.

I see that even Debian sid only has Rust 1.70, which is now 4 versions old -- I wonder why?

Yeah, we are a bit behind on rustc and cargo in Debian at the moment, I'm not 100% sure, but I think we need to get cargo caught up to a cargo version that corresponds to our current rustc before we push rustc further forward.

Thanks for the feedback, I've just taken another look at the commit in question and done some testing and I have successfully reverted the changes to the test in question, without touching the rest of the code, and the tests now pass. That's good enough for me.

OK -- I guess part of what you would have needed to revert is the crossbeam-channel dependency, but if you're only changing the test, you can move that to a dev-dependency so it's not included in the normal build. Up to you!

but if you're only changing the test, you can move that to a dev-dependency so its not included in the normal build

This might not help as IIRC Debian usually runs the tests as part of the packaging to increase the confidence that e.g. porting a package to a different architecture actually works (in contrast to just compiling).

Surely they would still build dev-dependencies when running tests? That's the point of those...

Ah sorry, I misread your post as the point was not to get the normal build working by avoiding the dev-dependency. Just that crossbeam-channel suffices as a dev-dependency if only the test is modified. Sorry for noise.