Add `resolver = "2"` to root Cargo.toml

[Darksonn]

Currently by not enabling the new feature resolver, test features are enabled even when building Tokio in non-test mode. This means e.g. that we never build Tokio with only the fs feature in CI because test-util depends on the rt feature, enabling that too.

Adding the resolver = "2" option to our workspace Cargo.toml fixes the issue on new rustc versions, but it causes our MSRV to emit an error when building Tokio.

[taiki-e]

Currently by not enabling the new feature resolver, test features are enabled even when building Tokio in non-test mode. This means e.g. that we never build Tokio with only the fs feature in CI because test-util depends on the rt feature, enabling that too.

This is due to v1 resolver merging the features of normal dependencies and the dev-dependencies
cargo-hack's --no-dev-deps, --remove-dev-deps, cargo's unstable -Zfeatures=all, -Zfeatures=dev-deps, -Zavoid-dev-deps can handle this issue. (cargo-hack is originally designed to handle these problems that occur with v1 resolvers.)
Our CI already uses one of them, so it works correctly.

tokio/.github/workflows/ci.yml

Line 210 in dc18941

run: cargo hack check --all --each-feature -Z avoid-dev-deps

tokio/.github/workflows/ci.yml

Lines 245 to 247 in dc18941

	# Remove dev-dependencies from Cargo.toml to prevent the next `cargo update`
	# from determining minimal versions based on dev-dependencies.
	cargo hack --remove-dev-deps --workspace

---

Adding the resolver = "2" option to our workspace Cargo.toml fixes the issue on new rustc versions, but it causes our MSRV to emit an error when building Tokio.

AFAIK cargo does not provide a stable way to change the resolver version at runtime, but I think it would be easy to add the ability to do that to cargo-hack.

[Darksonn]

Alright, it's good that we are handling it properly. Thanks for verifying.