Update rand to 0.7.0

[rubdos]

Since a bit, rand has small_rng as a separate feature. I thus had to add it as required feature.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ithinuel (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[rubdos]

There's still an issue with no_std in rand itself.

[therealprof]

@rubdos Indeed. I also noticed that while trying to upgrade some other crates of mine a while ago. Just curious: What's the benefit of this version bump?

[rubdos]

@rubdos Indeed. I also noticed that while trying to upgrade some other crates of mine a while ago. Just curious: What's the benefit of this version bump?

Fair point... I was bumping it because I was trying to get futures + async_await to compile, and I noticed that futures-preview contained 0.7.0. Without the version bump, I'd have multiple versions of the same crate...

It's nothing urgent though, I don't even have my test boards yet :D

[therealprof]

@rubdos The use of rand in this crate is somewhat special and also a bit unfortunate, bumping it to the latest version sounds good to me in general, but it would be even better if we could completely eliminate it. 😅

[rubdos]

Ah, tbqf, I didn't look at why it needed rand at all 😓

It's not lost energy though, since that issue I found in rand itself applies to any no_std environment, and futures-preview uses it too if you enable async-await.

I've had a look at the use, and it's just to generate some unique identifiers with a bunch of macros? I don't get why it'd need to be no_std compatible then, if it's presumably only used on compile time, and not even included in the output?

EDIT: It's already only in dev-dependencies! Why is it still compiled for the target itself then? 😮
EDIT2: It's for the example, then... So in fact, rand is not even ever used!

[therealprof]

@rubdos You can only have one set of dependencies with one set of feature-flags (feature flags are always additive) in your application. So it's normally only used at build time, but in case you want to use it in an application you're stuck with the same one...

[rubdos]

@rubdos You can only have one set of dependencies with one set of feature-flags (feature flags are always additive) in your application. So it's normally only used at build time, but in case you want to use it in an application you're stuck with the same one...

I'd agree, but in this case, there's one rand in the macro's library, and another rand in the root crate. Both were at different versions (and probably features too?) before 7e31e50.

If I remove rand from the main Cargo.toml, everything except the example still compiles, afaict.

[therealprof]

If I remove rand from the main Cargo.toml, everything except the example still compiles, afaict.

Sure.