Regression from 1.39.0 to 1.40.0: --no-default-features is not allowed in the root of a virtual workspace

[jplatte]

Problem

In virtual workspaces, cargo check -p subproject --no-default-features used to work up until 1.39.0 (although AFAICT now it didn't at all do what I intended) and since 1.40.0 results in:

error: --no-default-features is not allowed in the root of a virtual workspace

Probably related to #5364.

Notes

On nightly, this can be worked around by adding -Z package-features. However, I'm testing on stable and if I understand #5364 correctly, 1.39.0 didn't do the right thing anyway*. So I'll update my CI script to cd into the subproject directory and run without -p from there from now on.

* AFAICT it probably enabled the default feature since another workspace package required it even though I passed --no-default-features. This should really have resulted in a warning...

[ehuss]

I'm not sure I understand, this seems to be a duplicate of #5364. Is there something else here?

[jplatte]

#5364 is about changed behavior behind a feature flag AFAICT. This is about a change of behavior from 1.39.0 stable to 1.40.0 stable without any feature flags. Things worked on 1.39.0 (albeit with unexpected semantics, as I figured out when I found and read through #5364) and don't work anymore on 1.40.0.

[ehuss]

The change was intentional. --no-default-features doesn't work without -Zpackage-features. So instead of accepting a flag that doesn't work, it was changed to an error. It could have been transitioned with a warning, but we decided not to.

[jplatte]

Alright. It wasn't clear to me from reading the comments on #5364 that this change was intended. I still think the error message should include something like

note: while this was previously accepted, it didn't actually disable default features for any crate

Should I open a new issue for the error message?

[ehuss]

You can leave this open. If you'd like to add the note, it sounds good to me. Should be a one-line fix here and update the virtual_ws_flags test.

[udoprog]

I'd like to raise that I think this should still count as a regression. Cargo in a workspace root did accept the flag --no-default-features - even if it was a no-op. I.e. builds which used to work due to a set of flags, broke only due to an upgrade.

In contrast to other random flags which were just rejected. A warning when cargo is running in an interactive shell seems more appropriate.