async-io
async-io copied to clipboard
async-io now fails to compile on 1.46
With the new release of once_cell
1.15, the MSRV had been increased to 1.56 and the edition has been bumped to 2021. This means async-io
, which depends on once_cell
, no longer builds on 1.46:
$ cargo +1.46 check
warning: unused manifest key: package.rust-version
Updating crates.io index
Downloaded once_cell v1.15.0
error: failed to parse manifest at `/home/jtnunley/.cargo/registry/src/github.com-1ecc6299db9ec823/once_cell-1.15.0/Cargo.toml`
Caused by:
failed to parse the `edition` key
Caused by:
this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.
I see two options:
- Pin our
once_cell
version to1.14.x
. This would keep our MSRV at 1.46, but prevent us from receiving any newonce_cell
updates. - Bump our MSRV to 1.56. However, we would no longer be able to build this project on unmodified Debian.
See also: matklad/once_cell#201
Pinning once_cell would force us to maintain multiple versions of once_cell.
The third option is vendoring our own version of once_cell
, but that has many of the same problems as just pinning it.
An alternative solution is to:
- Commit Cargo.lock.msrv file
- Use that lockfile when testing MSRV
- Ask users who need older MSRV to pin once_cell to an older version in their lockfile by using
cargo update —-precise
once_cell itself uses this approach:
https://github.com/matklad/once_cell/blob/97edd07e0ac05fb8e4b994e9a53ba187d8fa17fc/xtask/src/main.rs#L44
Commit Cargo.lock.msrv file
Use that lockfile when testing MSRV
Ask users who need older MSRV to pin once_cell to an older version in their lockfile by using
cargo update —-precise
I'd be fine with this solution, although in practice it means bumping the MSRV and having users on lower rustc versions have to hack their files to get things working.
My personal vote is for bumping the MSRV. It's the direction that the rest of the ecosystem is headed in; IIRC libc is planning to bump to a 1.5x version soon. In addition, the next Debian stable version won't be out for another year or so, and I don't think that we should wait for that to bump up. As the rest of the ecosystem continues to evolve, sticking to older versions will quickly cause us to become out of date.
@smol-rs/admins What are your thoughts on this? blocking
is affected by this as well, and I think async-executor
and smol
also directly use once_cell
.
My personal vote is for bumping the MSRV.
:+1:
I would like to switch to Once
or blocking method of async OnceCell
recently added to async-lock, etc. if possible. However, if it is difficult, let's bump MSRV.
The approach proposed by @matklad (Cargo.lock.msrv) looks fine from a maintenance cost point of view, but looks bad from the user's point of view because it is not clear which dependencies' latest versions have higher MSRVs. (In other words, it is difficult for a user to actually build that crate on MSRV because it is not clear what action is required for the user to get the MSRV that the crate claims. Even if we add docs on the cargo update —-precise
, CI doesn't check that it works, so we won't catch MSRV breaks due to MSRV bumps on other dependencies.)
That's actually a better idea. We already maintain our own version of once_cell
as-is. We should use it. Although I'd personally prefer to set up smol-rs/event-listener#30 first.