no_std support

[leo60228]

This bumps the MSRV to 1.36, since it requires the alloc crate. Closes #94.

[cuviper]

See also #92 -- but you did it without a feature, which avoids the breaking change there.

I would still rather be more conservative about MSRV though, since 1.36 is very recent. Maybe instead we can make this conditional on the version, detected from a build script? My own autocfg crate is useful here, or others like rustc_version work too. Then we could be automatically no_std for 1.36 and later, while still keeping older support.

[leo60228]

Looks like a dependency of rand increased the MSRV upstream.

[cuviper]

Ugh, that's annoying. It may be better for us to commit a safe/compatible Cargo.lock, which we can remove or update in newer CI runs.

[leo60228]

AutoCfg::probe_path doesn't work for crates, I'm going to try and submit a PR for probe_sysroot_crate/emit_sysroot_crate.

[bluss]

Looks interesting.

Can this PR formulate the goals and gains that come from this change? The breaking changes and churn require solid motivation. Thanks 🙂

[leo60228]

@cuviper Wait, no, I just forgot that I switched to Rust 2018 in the initial PR...

[leo60228]

No idea why the doctests aren't compiling...

[bluss]

What does this do? Commit logs don't explain it.

[cuviper]

That would blindly emit a std config value. I suppose they were doing that as a stopgap until the commented crate tests were available -- that's now in autocfg 0.1.6.

[bluss]

Also, there is no reason to require Rust 1.36 for alloc — before Rust 1.36, it should still compile using std.