Infer resolver version from workspace edition

[ehuss]

It would be very helpful to set the resolver version in a virtual workspace based on the edition field being added in RFC 2906. This has been requested several times and has caused some confusion for some users.

That is, if you have:

[workspace]
edition = "2021"
members = ["foo"]

Then this will default workspace.resolver = "2"

The logic for determining the version is here. It should also check the workspace edition. This should also be gated on workspace-inheritance on nightly.

[0xPoe]

@rustbot claim

[Muscraft]

@hi-rustin If you don't mind I would like to claim this. I want to add it to the RFC as something to do before we try to stabilize.

[0xPoe]

I want to add it to the RFC as something to do before we try to stabilize.

I don't quite understand what you mean?

[Muscraft]

I'm currently working on the RFC for workspace inheritance and would like to add this issue to the tracking issue as something to do before trying to stabilize it.

[0xPoe]

You mean we don't need to implement it now? (Or is there something blocking it?)

The logic for determining the version is here. It should also check the workspace edition. This should also be gated on workspace-inheritance on nightly.

This confuses me 😖 I thought we were going to make it happen now.

Unassign myself.

[0xPoe]

If it is now acceptable and achievable. Then I'm happy to implement it :(

[Muscraft]

That's my bad for being confusing. I was just trying to say that I was just going to add it to my todo list before trying for stabilization of workspace inheritance.

If it's something you want to work on you are more than welcome to. There shouldn't be any blockers on it.

[epage]

@ehuss my comment in #5784 used the workspace.edition = "2018" syntax because that is what is in the inheritance RFC, the current inheritance implementation has the syntax as workspace.package.edition = "2018". Should this issue reflect whatever syntax is stablized for inheritance or should it use workspace.edition, regardless of what inheritance does?

Background: there is unresolved thread from the RFC that I think needs revisiting and so #10564 changed the inheritable syntax to workspace.package.edition = "2018" as a proposed change for stablization as recorded in #8415.

[Muscraft]

Another thing to consider is having workspace.edition = true caused #10586 to some degree. By having things to inherit under workspace.package.{key} or [workspace.package], it makes it harder to mix up [workspace] fields and [package] fields.

[ehuss]

Ah, sorry for the confusion. I probably should not have marked this with an E tag as this is indeed part of the RFC 2906 work. @hi-rustin, it looks like you have several open issues assigned to you. I recommend trying to finish some of those off before claiming additional issues. I appreciate the interest in helping, but claiming too many issues at the same time can make coordination more difficult.

@epage Sorry, I did not see that had changed. That indeed puts a wrinkle in this. I wouldn't want those inheritance fields to have no intrinsic meaning, except for edition. But I wouldn't want to add workspace.edition by itself with no meaning other than changing the resolver (or adding implicit inheritance).

Unless anyone has particular ideas on how to deal with that, I'm leaning towards just closing this.