Explicit edition and resolver in Cargo.toml

[nsipplswezey]

I'm new to the repo.

When running tests, cargo outputs the following warning and notes about crate editions and specifying an explicit resolver for the workspace.

scylla-rust-driver % cargo test
warning: some crates are on edition 2021 which defaults to `resolver = "2"`, but virtual workspaces default to `resolver = "1"`
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
...

Adding resolver = "2" to cargo.toml addressed the warning and notes. The same tests pass after explicitly specifying the resolver as did before explicitly specifying the resolver.

Was going to open a PR but #833 addresses this.

After taking a closer look at resolvers, I followed the rust edition migration instructions suggested here https://doc.rust-lang.org/edition-guide/rust-2021/default-cargo-resolver.html and ran cargo fix --edition and did the following prompted steps:

If you are trying to migrate from the previous edition (2018), the
process requires following these steps:

1. Start with `edition = "2018"` in `Cargo.toml`
2. Run `cargo fix --edition`
3. Modify `Cargo.toml` to set `edition = "2021"`
4. Run `cargo build` or `cargo test` to verify the fixes worked

cargo fix --edition with edition = "2018" made no modifications to any files in the repo. My guess is that cargo clippy caught any edition migration issues in linting.

The build and tests pass after explicitly specifying edition = "2021" in Cargo.toml as did prior to explicitly specifying edition.

Seems like explicitly adding edition = "2021" to Cargo.toml might also make sense in addition to #833

Small change, but figured I'd open an issue, describe the work, and open a PR. Could just as easily be added to #833

scylla-rust-driver % cargo -V
cargo 1.73.0 (9c4383fb5 2023-08-26)

[cvybhu]

Hi, thanks for opening the issue. I saw the warning and just opened a quick PR (#833), but it's a good idea to dive deeper into what's going on.

I read up on it and it looks like workspaces don't have an edition parameter.

Here's the source code from cargo that keeps workspace toml:
https://github.com/rust-lang/cargo/blob/87f4b1ba07f698e0a30d75ea0c9fbdb1e8655079/src/cargo/util/toml/mod.rs#L1513-L1528

There's a resolver field, but I don't see edition anywhere.

OTOH the parsed toml for packages has an edition field:
https://github.com/rust-lang/cargo/blob/87f4b1ba07f698e0a30d75ea0c9fbdb1e8655079/src/cargo/util/toml/mod.rs#L1660

I think that edition can only be specified in individual packages, not the whole workspace.
We already have edition = "2021" in all the packages e.g:

scylla-rust-driver/scylla/Cargo.toml

Line 4 in 36ade9e

edition = "2021"

That's probably why cargo --fix edition didn't do anything, all the packages are already using 2021.

Because of that I'm against adding an edition field in the workspace Cargo.toml, as it doesn't do anything.

[cvybhu]

One interesting thing I found is "workspace inheritance": https://blog.duyet.net/2022/09/cargo-workspace-inheritance

It's possible to specify package.edition in the workspace Cargo.toml and then every package can say that it wants to inherit the edition from the workspace.

It's a cool feature, but I don't think we really need it. It adds significant complexity for little benefit.

[nsipplswezey]

The cargo source is of course the right place to look! Thanks for the source links and highlighting that edition isn't a workspace parameter at all! Looks like perhaps the cargo fix --edition prompt I was following based on the rust edition guide docs... assumed the command was being run in a package, not a workspace, since the instructions tell you to a modify a parameter that isn't even used! Also very useful to see the "workspace inheritance" feature. Thanks for that.

Big picture totally agree that any form of explicit edition here is of little benefit for the added complexity. Thanks and closing!