Remove std feature from sha1

[roblabla]

Why does SHA1 have an on-by-default std feature? It seems to merely forward it to digest, which uses it to activate some traits which aren't actually used by SHA-1? This is a bit of a footgun, since many crates in the ecosystem will accidentally leave it enabled, breaking no_std builds. This is especially the case because of stupid cargo bugs like rust-lang/cargo#4664.

As a practical case: I'm currently having my nostd builds broken because pest (which I use in a proc macro) is using sha1 as a build dependency without deactivating the std feature.

[newpavlov]

It's quite common for Rust crates to have an enabled by default std feature (since std users form an overwhelming majority), so any crates which intends to support no_std targets should be careful to disable unneeded features in its dependencies and run CI tests to ensure that crate can be used with no_std targets. Thus I think it has to be fixed on the pest side, especially considering that update will be as simple as updating this one line.

[roblabla]

The problem is, pest doesn't intend to support no_std. But if pest is used as a proc macro in a no_std crate, it might still accidentally toggle the std bit for the no_std crate it's providing the proc macro for.

Ideally, cargo#4664 would just not exist, but it's been years and there's been no progress. Besides, sha-1 doesn't use any of the features digest std provide. If the user needs them, wouldn't they have to provide digest in their Cargo.toml anyways, enabling the std feature at this point?

[roblabla]

(FWIW: I also filed a PR to pest: pest-parser/pest#410)

[newpavlov]

If the user needs them, wouldn't they have to provide digest in their Cargo.toml anyways

No, since all hash crates re-export digest for convenience.

[roblabla]

Aw, shux, forgot about that. Guess removing std would be a breaking change then, and that's probably not worth the effort.

[newpavlov]

Looks like the pest bug got fixed, so I think we can close this issue.