resolve the ambiguity to determine version of Cargo feature resolver.

[FomalhautWeisszwerg]

About This Pull Request

Summary

• fix version of the Cargo feature resolver to "2".

Details

In helix, multiple edition designations are mixed as following:

$ grep --recursive --line-number "edition" helix-*
helix-core/Cargo.toml:5:edition = "2021"
helix-dap/Cargo.toml:5:edition = "2018"
helix-event/Cargo.toml:5:edition = "2021"
helix-loader/Cargo.toml:6:edition = "2021"
helix-lsp/Cargo.toml:5:edition = "2021"
helix-parsec/Cargo.toml:5:edition = "2021"
helix-term/Cargo.toml:6:edition = "2021"
helix-tui/Cargo.toml:8:edition = "2021"
helix-vcs/Cargo.toml:5:edition = "2021"
helix-view/Cargo.toml:5:edition = "2021"

And each edition implies a different default feature resolver version.

• edition = "2018" implies resolver = "1"
• edition = "2021" implies resolver = "2"

There is one problem. The setting of Cargo feature resolver is a global so only honored at the top-level one (and the others are ignored, the ignored resolver's features are not merged).

Currently, Cargo.toml at the top-level does not specify a feature resolver. This makes it hard for cargo to determine which is the developer's intent to use. In fact, a newer toolchain displays the following warning:

$ cargo --version
cargo 1.74.0 (ecb9851af 2023-10-18)
$ cargo build
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions

This pull request solve the ambiguity by specifying the feature resolver version to "2" in the root's manifest.

[dead10ck]

Hmm, it's probably an oversight that helix-dap is still set to the 2018 edition. We should probably fix that too.

[pascalkuthe]

I would prefer if the rust edition for helix-dap would be fixed instead of using this workaround

[Tudyx]

This is not a workaround, we must specify the resolver manually otherwise it gets ignored. See https://doc.rust-lang.org/cargo/reference/workspaces.html#virtual-workspace . I got bitten by this once, i didn't understand why feature unification wasn't respected.

By the way is setting the edition in the workspace Cargo.toml and then inherite it in child Cargo.toml has been envisaged? Would look like this in the child toml:

[package]
edition.workspace = true

[pascalkuthe]

I wouldn't mind. When these crates were crated workspace inheritance wasn't around yet. Either way I would still like to see the edition fixed in this PR because we will forget otherwise

[FomalhautWeisszwerg]

Thanks for reviewing and feedback.

I fixed Rust editions in ba5001b by using the workspace inheritance. Also license and rust-version.

• build_hx.log
• tests_hx.log

I hope that helps.

[FomalhautWeisszwerg]

@Tudyx

we still need to set the resolver explicitly in the workspace 's Cargo.toml.

This seems wrong. Because the feature resolver setting is global so it must be specified in the root's Cargo.toml only. And the feature resolver setting should be in the [workspace] (not [workspace.package] ).

If a feature resolver were specified in a non-root Cargo.toml, cargo shows warning and ignore them.
For example, resolver = "1" specified in helix-dap/Cargo.toml, cargo shows following warings:

$ cargo build
warning: resolver for the non root package will be ignored, specify resolver at the workspace root:
package:   /mnt/SHPP41-2000GM-2/rustacean/helix_editor/fix/feature_resolver/helix-dap/Cargo.toml
workspace: /mnt/SHPP41-2000GM-2/rustacean/helix_editor/fix/feature_resolver/Cargo.toml

[Tudyx]

Yeah by worspace's Cargo.toml, I meant the Cargo.toml at the root and only this one. Like you have done in your PR so this is fine. Sorry for the unclear terminology

[dead10ck]

Thanks!