Bump MSRV to 1.31

[joshlf]

This permits Cargo.toml to include optional dependencies. On toolchains earlier than 1.31, the optional dependency syntax is not supported. With the MSRV at 1.31, any optional dependency may be supported even if its MSRV is higher than our MSRV since only users using a more recent toolchain will enable that dependency.

In particular, this paves the way for adding an optional zerocopy dependency (prototyped in #3407 and #3914; see also google/zerocopy#557), which permits many uses of libc to no longer require unsafe code.

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[joshlf]

r? @Amanieu

[tgross35]

We won't be bumping MSRV on libc 0.2, the main branch already has 1.0. Any new features should target that - but we need to discuss and make sure that ecosystem traits are something we even want here, has this been discussed?

[joshlf]

We won't be bumping MSRV on libc 0.2, the main branch already has 1.0. Any new features should target that - but we need to discuss and make sure that ecosystem traits are something we even want here, has this been discussed?

Re: 1.0: Our concern is that 1.0 may take an arbitrary amount of time to finalize and publish (I say that as the author of zerocopy 0.8, which we originally estimated would land in January 😛 ).

As for the discussion, I've discussed it informally with a few folks, but nothing official. We were hoping that an optional dependency would be relatively uncontroversial since it's opt-in and so it doesn't impose a cost on users who don't care about it. I'd be happy to discuss in more detail why zerocopy support from libc is important for our users.

[bors]

☔ The latest upstream changes (presumably #3931) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

As for the discussion, I've discussed it informally with a few folks, but nothing official. We were hoping that an optional dependency would be relatively uncontroversial since it's opt-in and so it doesn't impose a cost on users who don't care about it. I'd be happy to discuss in more detail why zerocopy support from libc is important for our users.

The reasoning makes enough sense to me. We just need some team feedback since this is effectively endorsing a library crate - mind opening a Zulip thread?

Re: 1.0: Our concern is that 1.0 may take an arbitrary amount of time to finalize and publish (I say that as the author of zerocopy 0.8, which we originally estimated would land in January 😛 ).

Yeah, I know this is a problem we are already facing. However, 0.2 should be considered on a major features freeze; I don't want to effectively delay 1.0 further by increasing the maintenance demand of our stable version, keeping 0.2 up to date is already pretty painful.

With that in mind, I am going to close this and the zerocopy PR targeting 0.2. I appreciate the effort, but anything this large needs to target main (which I see you already have).