Update sha1 to version 0.11.0 and rand to version 0.10.0

[LilithSilver]

The main release version of sha1 has an issue where the deeply-nested dependency generic-array still includes doc_auto_cfg, which is deprecated in rust nightly. Recent docs.rs builds fail when the old version is included. This bumps the version to stop the issue.

rand has a similar issue.

I've managed to request updates from all other upstream nested dependencies; those aren't pre-release versions, so Cargo should be able to update them OK.

[daniel-abramov]

I think I'd rather wait for a stable release should this become necessary. Using the release candidate version is not encouraged, especially in [somewhat popular] libraries.

[LilithSilver]

I think I'd rather wait for a stable release should this become necessary. Using the release candidate version is not encouraged, especially in [somewhat popular] libraries.

I generally agree; but docs.rs will fail to build for any users (or tungstenite itself) until those packages are updated...

Good news, rand released 0.10.0, so I committed that. sha1 hasn't had a major release in over 2 years though, although they do frequently post rc builds.

[daniel-abramov]

I generally agree; but docs.rs will fail to build for any users (or tungstenite itself) until those packages are updated...

Hm... tungstenite builds without any issues with +nightly. Do I miss something? (Perhaps I misunderstood the issue?)

[LilithSilver]

Hm... tungstenite builds without any issues with +nightly. Do I miss something? (Perhaps I misunderstood the issue?)

Apologies, I missed an important thing.

The downstream packages that fail rely on the following rustdoc/rustc args, as described here.

[package.metadata.docs.rs]
all-features = true
rustdoc-args = ["--cfg", "docsrs"]
rustc-args = ["--cfg", "docsrs"]

This can be simulated by putting this inside of Tungstenite's Cargo.toml in the proper location, then run the docs-rs build. (with cargo docs-rs provided by https://github.com/dtolnay/cargo-docs-rs).

Since Tungstenite doesn't use those cfg features, the issue won't present itself on this package's build, only packages that use Tungstenite and rely on those features to build their docs.

[LilithSilver]

Not sure why the cargo check CI is failing due to a rand feature mismatch... cargo check, build, etc runs OK on my machine, and I don't see the getrandom feature mentioned anywhere in tungstenite.

[daniel-abramov]

Yes, the errors were unrelated and fixed in master, you might want to rebase.

I confirm that I can reproduce the error when using the flags. This is an interesting issue; I might need to research how other packages have dealt with it and what's the best way to address it (judging from the linked/mentioned issues the problem must have affected multiple popular crates), . I'm (typically) a bit uncomfortable being dependent on *rc* releases of other crates, though it seems like sha1 is a bit unconventional for releases/tagging. Maybe we could even consider an alternative crate.

[LilithSilver]

@daniel-abramov

Good news, looks like sha1 0.11 finally released, so problem solved! I rebased, squashed, and pushed.

[daniel-abramov]

Yep, thanks for the update. I saw the update in 0.11, the only problem that I see is that MSRV of the 0.11 version is 1.85 (February 2025), which is much newer than the current MSRV of 1.71 (August 2019). I'm usually not against raising our MSRV, but 1.71 -> 1.85 is a very large step that's gonna have implications for downstream crates (for instance, latest axum uses 1.78 and their main is 1.80).