Prune duplicate crossbeam dependencies

[koushiro]

Signed-off-by: koushiro [email protected]

Motivation

Prune duplicate crossbeam dependencies

Solution

crossbeam-queue v0.1 -> 0.2
crossbeam-utils v0.6 -> v0.7

[dekellum]

Speaking for myself, thanks for trying to fix this! Some notes and suggestions below.

By convention, you might add "v0.1.x: " prefix to this PR title? There also was/is a label but us mortals can't apply it.

For the bug report aspect, I can replicate the duplication:

crossbeam-utils v0.6.6
├── crossbeam-queue v0.1.2
│   └── tokio-threadpool v0.1.16
├── tokio-executor v0.1.8
├── tokio-reactor v0.1.10 (*)
├── tokio-threadpool v0.1.16 (*)
└── tokio-timer v0.2.11 (*)

crossbeam-utils v0.7.0
├── crossbeam-deque v0.7.2
│   └── tokio-threadpool v0.1.16
└── crossbeam-epoch v0.8.0
    └── crossbeam-deque v0.7.2 (*)

This occurs because of the suspect if commmon approach (unfortunately, also applied in tokio 0.1.x) of MINOR upgrades in the crossbeam-deque 0.7.2 PATCH release. Relevant change logs:

crossbeam-deque 0.7.2 (2019-11-6)

• Upgrades to crossbeam-epoch ^0.8, crossbeam-utils ^0.7

crossbeam-epoch 0.8.0 (2019-11-6)

• Bump the minimum required version to 1.28.
• Fix breakage with nightly feature due to Split non-CAS atomic support off into target_has_atomic_load_store rust-lang/rust#65214.
• Make Atomic::null() const function at 1.31+.
• Bump crossbeam-utils to 0.7.

crossbeam-utils 0.7.0 (2019-11-6)

• Bump the minimum required version to 1.28
• Fix breakage with nightly feature due to Split non-CAS atomic support off into target_has_atomic_load_store rust-lang/rust#65214.
• Apply #[repr(transparent)] to AtomicCell.
• Make AtomicCell::new() const function at 1.31+.

The "fix breakage with nightly" (crossbeam-rs/crossbeam#428) sounded like it might be important, but as best I can tell, its only associated with a non-default nightly feature that tokio does not enable.

Another user workaround for duplication, short of these changes, would be:

cargo update -p crossbeam-deque --precise 0.7.1

Or otherwise pinning that version through other means.

It looks like your complete upgrade (current PR) would require (sadly, PATCH) releases to -executor, -reactor, -threadpool, -timer, correct?

Particularly since this is a maintenance branch, there is some precedent for further constraining dependencies to solve various problems like MSRV CI, ex:

[dev-dependencies]
flate2 = { version=">=1.0.2, <1.0.10" }

While constraining the tokio-threadpool dependency to the following is a more conservative change (e.g. only requiring a PATCH release of that single crate) it also potentially exposes us to future breakage that would otherwise be fixed in subsequent upstream PATCH releases. Still IMO worth considering?

crossbeam-deque = { version =">=0.7.0, <0.7.2" }

@taiki-e , as a contributor here as well as crossbeam, may I ask you: do you have any info or opinion on upgrading or constraining?

[koushiro]

@dekellum Thanks for your suggestions :)

It looks like your complete upgrade (current PR) would require (sadly, PATCH) releases to -executor, -reactor, -threadpool, -timer, correct?

Yes

[hawkw]

@taiki-e, do you have any thoughts on @dekellum's comment #1795 (comment)?

[LucioFranco]

Is this PR still active or did this get fixed already? @dekellum

[dekellum]

Still active AFAIK.