unable to compile futures v0.3.31 with unstable write-all-vectored feature enabled with Rust < 1.81 with RUSTC_BOOTSTRAP=1

[decathorpe]

I'm trying to update futures-rs crates in Fedora Linux to version 0.3.31, but I'm hitting a problem that I can't compile them with Rust 1.75 (for EPEL on RHEL 9). futures v0.3.30 with the same features enabled compiles fine on Rust 1.75 and 1.79, but v0.3.31 now fails with:

error[E0658]: use of unstable library feature 'io_slice_advance'
  --> /usr/share/cargo/registry/futures-util-0.3.31/src/io/write_all_vectored.rs:22:9
   |
22 |         IoSlice::advance_slices(&mut bufs, 0);
   |         ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #62726 <https://github.com/rust-lang/rust/issues/62726> for more information
   = help: add `#![feature(io_slice_advance)]` to the crate attributes to enable

error[E0658]: use of unstable library feature 'io_slice_advance'
  --> /usr/share/cargo/registry/futures-util-0.3.31/src/io/write_all_vectored.rs:37:17
   |
37 |                 IoSlice::advance_slices(&mut this.bufs, n);
   |                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #62726 <https://github.com/rust-lang/rust/issues/62726> for more information
   = help: add `#![feature(io_slice_advance)]` to the crate attributes to enable

As far as I can tell, the code in futures_util hasn't changed since v0.3.30, and IoSlice in futures_io::IoSlice is a reexport of std::io::IoSlice in both v0.3.30 and v0.3.31, so I have no idea why this would suddenly break (or why it previously worked? the IoSlice::advance_slices method was unstable for years and this worked...)

And, well, I can't reproduce this "upstream" with crates from crates.io, because futures-util v0.3.30 was yanked from crates.io, and cargo won't let me pick that version to compare with.

[decathorpe]

Ah, after bisecting git history between 1.80 and 1.81, I found the issue.

We build our packages with RUSTC_BOOTSTRAP=1 (for various reasons not worth going into here), and this commit from PR #2885 is what broke things: 31ae9d9

The feature is only stable on Rust 1.81+, but does require the #![feature] attribute on earlier versions. So removing it unconditionally breaks compiling this crate with Rust < 1.81 - but only when using RUSTC_BOOTSTRAP=1 to enable nightly-only features.

This is likely a very niche edge case, and I understand if you don't want to add this cfg_attr back, but I'll likely need to patch it in for our builds downstream to un-break stuff until RHEL 9 ships Rust 1.81 or later (in like ... a year 😫 ).

[taiki-e]

First, write-all-vectored is unstable and any breakage in patch versions is allowed.

futures-rs/futures/Cargo.toml

Lines 44 to 49 in 7211cb7

	# Unstable features
	# These features are outside of the normal semver guarantees and require the
	# `unstable` feature as an explicit opt-in to unstable API.
	unstable = ["futures-io/unstable", "futures-util/unstable"]
	bilock = ["futures-util/bilock"]
	write-all-vectored = ["futures-util/write-all-vectored"]

futures-rs/futures-util/Cargo.toml

Lines 26 to 31 in 7211cb7

	# Unstable features
	# These features are outside of the normal semver guarantees and require the
	# `unstable` feature as an explicit opt-in to unstable API.
	unstable = []
	bilock = []
	write-all-vectored = ["io"]

And using RUSTC_BOOTSTRAP=1 is to opt out of the various Rust stability guarantees. RUSTC_BOOTSTRAP has never been officially recommended to users, and there is no possibility of preferring users who use it over those who wish to use the opt-in feature in the latest stable Rust.

In this case it could probably work by just passing -Z crate-attr=feature(io_slice_advance) via RUSTFLAGS, but otherwise I think you have to use rustup toolchain or apply patch.

[taiki-e]

Also, when sticking with a particular older Rust, I strongly recommend that you commit the lockfile to prevent newer versions of dependencies from being automatically obtained.

This issue's case is a bit of a special case that depends on an unstable feature, but usually, in Rust ecosystem, increasing the minimum supported compiler version is not considered a breaking change.

[decathorpe]

Yup, that's usually good advice, but not something we can do in our particular circumstances. And we're not sticking with older rust voluntarily, we just need to use the one that is shipped by Red Hat "Enterprise" Linux :D