memchr v2.6.0 broke 1.20/1.25 tokio LTS MSRVs

[TheBlueMatt]

The memchr project's MSRV guidelines mention that MSRVs are only supported across patch versions, not minor versions. Tokio 1.27 switched to libc memchr (in #5558), dropping the dependency, but the 1.20/1.25 LTS releases depend on memchr via simply memchr = "2.2". Thus, the MSRV is liable to be broken on any minor release of memchr, which finally happened today with the memchr 2.6.0 release. I understand this may not be supported and pinning is pretty easy on the building end, but this isn't architecture-specific, and impacts all users of the io-util feature and would be pretty easy to pin the dependency directly in the LTS releases.

[Darksonn]

Pinning has negative impacts on dependency resolution. Switching to libc memchr seems better to me. Thoughts?

[hawkw]

Users who need to compile on Tokio's MSRV may also wish to compile with -Z minimal-versions to avoid potential MSRV breakage from transitive dependencies in the future.

I agree with @Darksonn that pinning in Tokio itself is not great, and that backporting the change to depend on libc's memchr to the LTS releases is probably a better approach.

[carllerche]

I'm a +1 w/ @darkson as well

[sunshowers]

Agreed, pinning breaks cargo in some unfortunate ways. Downstream projects with an old MSRV should check in a Cargo.lock that works with that MSRV (e.g. for one of my projects: https://github.com/sunshowers-code/debug-ignore/blob/47a911cefdba591b75fba4a3c8e208558d11ebfd/Cargo.lock.rust134)

[TheBlueMatt]

Makes sense to me - the change to drop the dependency and use libc was pretty trivial, backporting it should be pretty low-risk.