async-io now fails to compile on 1.46

[notgull]

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 to 1.14.x. This would keep our MSRV at 1.46, but prevent us from receiving any new once_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

[sehz]

Pinning once_cell would force us to maintain multiple versions of once_cell.

[notgull]

The third option is vendoring our own version of once_cell, but that has many of the same problems as just pinning it.

[matklad]

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

[notgull]

• 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.

[zeenix]

My personal vote is for bumping the MSRV.

👍

[taiki-e]

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.)

[notgull]

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.