Crossbeam channel v0.3.7 fails to compile

[LivingInSyn]

including Crossbeam channel v0.3.7 fails to compile with the error:

  Downloaded crossbeam-channel v0.3.7
  Downloaded crossbeam-utils v0.6.1
   Compiling quote v0.6.11
   Compiling crossbeam-channel v0.3.7
error[E0432]: unresolved import `crossbeam_utils::Backoff`

this appears to be because of a mismatch between channel and utils

Gah, it's because it requires the latest version of crossbeam-utils. :(
You can fix the problem with cargo update -p crossbeam-utils.

I'll publish a new minor version with a fix.

[BurntSushi]

@stjepang You might find testing with minimal versions to be helpful. For example: https://github.com/rust-lang/regex/blob/60d087a23025e045ae754a345b04003c31d83d93/ci/script.sh#L53-L56

Ok, I've published 0.3.8 that bumps the crossbeam-utils dependency.

@BurntSushi Thank you, that's exactly what I'm looking for! :)

[LivingInSyn]

Thanks, all!

[jhpratt]

@stjepang Works for me! Looks like this can be closed.

@BurntSushi Transitive dependencies break under -Z minimal-versions:

    Checking void v1.0.0
error[E0259]: the name `core` is defined multiple times
  --> /home/stjepan/.cargo/registry/src/github.zerozr99.workers.dev-1ecc6299db9ec823/void-1.0.0/src/lib.rs:14:1
   |
14 | extern crate core;
   | ^^^^^^^^^^^^^^^^^^ `core` reimported here
   |
   = note: `core` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
14 | extern crate core as other_core;
   |

error: aborting due to previous error

Lots of other folks reported similar problems with - it looks like the whole crates ecosystem is broken in this aspect because no one cares about minimal versions. :( Did you have better luck with -Z minimal-versions?

[BurntSushi]

Yes. I ran into the same problem. This was the PR that added the check to regex, and this was the PR that removed the dependency on unreachable. Given that the unreachable and void crates are effectively micro-crates that are also, in practice, unmaintained, I would suggest lobbying the maintainers of smallvec to drop them as dependencies. It's probably a good idea to do that regardless of the minimal version check. cc @mbrubeck

It looks like this was discussed in servo/rust-smallvec#128, but we don't need to bump the MSRV to do this. They can just inline what they need from unreachable directly since there's so little code. In the process, they'll drop two dependencies from a very large number of crates in the ecosystem.

[BurntSushi]

It looks like smallvec 0.6.9 no longer depends on unreachable (and void), courtesy of @mbrubeck <3. So this might work now!

Thanks for the update! Unfortunately, building with minimal dependencies still doesn't work:

error: expected identifier, found `"std"`
  --> /home/stjepan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.1.1/rust/src/liblibc/lib.rs:79:46
   |
79 | #[cfg(feature = "cargo-build")] extern crate "std" as core;
   |                                              ^^^^^ expected identifier

error: aborting due to previous error

error: Could not compile `libc`.
warning: build failed, waiting for other jobs to finish...
error[E0407]: method `seed_from_u64` is not a member of trait `SeedableRng`
   --> /home/stjepan/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_isaac-0.1.0/src/isaac.rs:126:5
    |
126 | /     fn seed_from_u64(seed: u64) -> Self {
127 | |         IsaacRng(BlockRng::<IsaacCore>::seed_from_u64(seed))
128 | |     }
    | |_____^ not a member of trait `SeedableRng`

error[E0407]: method `seed_from_u64` is not a member of trait `SeedableRng`
   --> /home/stjepan/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_isaac-0.1.0/src/isaac.rs:331:5
    |
331 | /     fn seed_from_u64(seed: u64) -> Self {
332 | |         let mut key = [w(0); RAND_SIZE];
333 | |         key[0] = w(seed as u32);
334 | |         key[1] = w((seed >> 32) as u32);
...   |
341 | |         Self::init(key, 1)
342 | |     }
    | |_____^ not a member of trait `SeedableRng`

There are many more errors after that. We could manually require higher minimal versions of broken packages by adding them as dependencies to crossbeam-channel, but it's not as easy as it sounds. As such, I don't think we can easily add this check to CI, at least not yet... :(