Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async-io now fails to compile on 1.46 #93

Closed
notgull opened this issue Sep 21, 2022 · 7 comments · Fixed by #95
Closed

async-io now fails to compile on 1.46 #93

notgull opened this issue Sep 21, 2022 · 7 comments · Fixed by #95

Comments

@notgull
Copy link
Member

notgull commented Sep 21, 2022

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
Copy link

sehz commented Sep 21, 2022

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

@notgull
Copy link
Member Author

notgull commented Sep 21, 2022

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

@matklad
Copy link

matklad commented Sep 21, 2022

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
Copy link
Member Author

notgull commented Sep 22, 2022

  • 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
Copy link
Member

zeenix commented Sep 22, 2022

My personal vote is for bumping the MSRV.

👍

@taiki-e
Copy link
Collaborator

taiki-e commented Sep 23, 2022

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
Copy link
Member Author

notgull commented Sep 23, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

5 participants