Bump MSRV to 1.56

[GPHemsley]

RUSTSEC-2021-0023 reported a vulnerability in rand_core < 0.6.2. rand_core is a part of rand. The fix in rand_core 0.6.2 was first included in rand 0.8.4.

phf_generator is a part of phf. phf_generator depends on rand. The first release of phf (including phf_generator) to depend on rand 0.8, and thus be likely to be using rand >= 0.8.4, was phf 0.9.0.

#300 (1e4fe23) updated rust-cssparser to depend on phf 0.10, possibly because the latest phf 0.9 version (0.9.1) was yanked and replaced.

Prior this change, for reasons unclear, rust-cssparser had an apparent MSRV of 1.36. #300 (8ef116b) bumped that up to 1.40 because phf_shared 0.9.0 makes use of #[non_exhaustive].

However, phf 0.9 (and thus 0.10) reports in its changelog that it has an MSRV of 1.41 or 1.46, supposedly due to its dependencies. Thus, it is possible that rust 1.40 could not compile rust-cssparser in certain situations (though this seemingly did not manifest in CI).

In an apparent attempt to fix this, 7cb5206 was committed directly to master without a reviewed PR. This change reverted the phf dependency in a way that allowed the vulnerable phf 0.8 to be used again while also restricting the use of phf >= 0.11 (">=0.8,<=0.10").

#306 (9f936c0) identified this issue, but resolved it simply by bumping the restriction to phf >= 0.12 (">=0.8,<=0.11").

A more flexible version specification, which I use here, is "~0.9", though this again raises the possibility that rust-cssparser does not compile on rust 1.40.

---

Separately, both @tiaanl and I have been attempting in our recent work to make use of f32::clamp, which was not stabilized until rust 1.50.

Additionally, it would be good to explicitly specify the MSRV in Cargo.toml, rather than just in the CI configuration. But that was not supported officially until rust 1.56, which also just so happened to be the first version to support the 2021 edition.

As such, I am proposing that we bump the rust-cssparser MSRV to 1.56.

In checking some packages that depend on rust-cssparser, and comparing the versions of rust available on various platforms, I have not been able to anticipate any downsides to this. I am currently operating under the assumption that it is merely the passage of time that has made the current MSRV so old.

cc @tiaanl @emilio @wusyong @adamreichold

[adamreichold]

But that was not supported officially until rust 1.56,

While Cargo before 1.56 does not parse rust-version, it does not break dependencies, i.e. it will emit warning due to the unknown field and carry on. Hence, usage of rust-version is not really tied to an MSRV of 1.56 or later as the field still has value for human readers.

[emilio]

Bumping seems fine, but can we just use 0.11 here now?

[GPHemsley]

phf 0.11 has an MSRV of 1.60.

[emilio]

That's fine, we can have the lockfile with 0.10 or so.

[emilio]

I decided to not change the PHF requirement. We do use and should be able to use newer PHF versions as needed. Bumping MSRV is fine tho.

[GPHemsley]

I decided to not change the PHF requirement. We do use and should be able to use newer PHF versions as needed.

I don't understand. Without this change, PHF with a security vulnerability is allowed and newer versions of PHF are not allowed.

You also excluded a change from my commit that removes a section from the CI config that is now unnecessary because of the MSRV being bumped to 1.56.

[GPHemsley]

@emilio Can you explain your decision here?

[emilio]

I don't understand. Without this change, PHF with a security vulnerability is allowed and newer versions of PHF are not allowed.

How are they not? Newer as in "arbitrarily newer" versions are not, but that's a feature (because arbitrarily new version of phf can change their API and break the build). What am I missing?