Update rand to 0.7, rand_xorshift to 0.2

[silwol]

There are some method calls which require a mutable reference to the
RNG instance. I chose to create the instance and then immediately create
a reference to it which is then used within this scope. If you know a better
solution, feel free to adjust accordingly.

[cuviper]

You'll need to update ci/compat-Cargo.lock for the Rust 1.28 check.

Current versions of rand also use dependency renaming for getrandom, which old Rust doesn't support. It might work well enough to resolve the lock file now that someone added a placeholder getrandom_package, though you probably need to use Rust 1.28 directly to see what happens. I'm wary that this might still cause problems for anyone depending on rayon in general though.

We could also wait for Rust 1.31 to be a year old (December 6th) per our policy on the minimum supported compiler, then the package renaming won't be an issue anymore.

[silwol]

Is there a defined procedure for updating the lock file, or is it just manual editing until it works with the desired crate versions on the target version of the compiler?

[cuviper]

Yeah, we should probably write some instructions for this. It's a somewhat manual process, but not editing the file directly. Copy ci/compat-Cargo.lock over your root Cargo.lock. If you just cargo build from there, it should update as few dependencies as needed, and then you can copy the file back. You might use cargo +1.28.0 build to do this with the older version, assuming you've installed that with rustup. If any dependencies need manual downgrading for compatibility, you can specify that with cargo update -p some_crate --precise 1.2.3.

[silwol]

Ok, then I was on the correct path already. Building works, but I had attempted to run cargo +1.28.0 test which fails due to rand_xorshift (and probably others, but that's the first one it attempts) using the 2018 edition. If the compatibility to at least one year old compilers matters for dev dependencies, we would in deed have to wait for rustc 1.31 being one year old. Otherwise it would work. I pushed a commit with the updated ci/compat-Cargo.lock file.

[cuviper]

I'm inclined to just wait for the anniversary of 1.31 on December 6th, so we can bump our requirement and not worry about the dependencies that use package renaming.

(The one-year compatibility policy is sort of arbitrary, but I feel it's useful to be predictable.)

[cuviper]

I rebased this for conflicts with #712. Thanks again!

bors r+

[bors]

Build succeeded

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push