Require 1.26.0 in deque and utils

[ghost]

crossbeam-deque and crossbeam-utils don't really need 1.28.0, we can support 1.26.0

[cuviper]

Ah, the latest published versions (crossbeam-deque-0.7.1 and crossbeam-utils-0.6.5) work fine with 1.26, but crossbeam-utils on master is using #[repr(transparent)].

crossbeam-deque 0.7.0 and 0.7.1 already documented that it required 1.28 though. Will you be bumping semver on the others for the updated requirement?

[ghost]

@cuviper Thanks for tracking this down, I forgot about #[repr(transparent)].

What do you think about introducing legacy feature flag to crossbeam-deque and crossbeam-utils that supports whatever the Rust version is used by Rayon?

[cuviper]

If you're willing to carry such conditions in the code, I'd rather see that auto-detected, so rayon doesn't have to be an inhibitor. It could either use a version check or probing like autocfg, though I don't have an API to probe for attributes yet. Also note that we can't probe crossbeam features from the rayon side, because build scripts can't affect cargo-level features.

If you're open to this, I can take it on myself to make a PR.

[ghost]

@cuviper Yeah, that'd be a cleaner solution because then we wouldn't have to add new features to Cargo.toml.

I'd be happy to accept a PR for this :) Thanks!

[ghost]

@cuviper How about this? https://github.com/dtolnay/select-rustc

[cuviper]

Yeah, select-rustc looks really cool -- but it's a 2018 edition crate, so it needs at least 1.31 itself.

[jeehoonkang]

I'm proposing to revert #360, and support Rust 1.26. #360 is a good improvement, but I think its benefit doesn't outweigh its drawback, which is breaking the compatibility with Rayon.

Further, I'm proposing to stick with the Rust version supported by Rayon in the future as much as possible, and document the policy in e.g. /ci/*.sh.

[ghost]

@jeehoonkang Yeah, maybe we should revert that. In fact, only #[repr(transparent)] bumps the minimum Rust version so it's enough if we just remove that line.