Migrate rust-lang/rust to rand_core 0.7

[gnzlbg]

Every time a new release of rand happens, it would make sense to migrate rust-lang/rust to use it, since it is a huge user of rand that can discover oversights and design directions that might be problematic.

It is a particularly good place to test "future compatibility"-shims. These are hard to write, but the dependency graph of rustc is big enough to exercise them in many different ways.

[dhardy]

I disagree about it being a good place to test compatibility shims — small examples are quite enough. The issue with rand 0.6.5 is simply that it violates semver rules as you pointed out — I don't believe this is worth fixing now, since doing so would require yanking crate versions already in widespread usage, downgrading to rand_core 0.3.x and would break no_std support for all Rand 0.6.x users (unless we instead pushed a breaking change to rand_core 0.3.x and hoped that caused less damage). Of course, we will try our best not to this again in the future 😉

Edit: of course, #852 is still unexplained.

As for upgrading rustc, I don't have the time myself this week and perhaps also not in the near future. Whoever gets there first I guess.

[gnzlbg]

As for upgrading rustc, I don't have the time myself this week and perhaps also not in the near future. Whoever gets there first I guess.

I am just pointing out that probably nobody is going to try because it is currently already too much work, and this will mean that 0.6.1 and 0.7, newer 0.7.x versions, and in the future 0.8, 0.9, etc. will need to build and work properly in rust-lang/rust dependency graph. The more versions get released the more work it is to update, the harder it is going to be to find a workaround to fix things quickly if things break, etc.

[mati865]

I'll see what I can do about this issue.

[mati865]

Upgrading all Rust crates to rand 0.7 fail with the same error as upgrading to rand 0.6.5 #852

[dhardy]

Thanks @mati865 for addressing this.