Specified features are silently ignored when building from the root of a workspace with default-members

[jdm]

Given a workspace with default members, not only does cargo build --features nonexistent from the workspace root report no errors if the nonexistent feature is not a feature supported by any of the workspace members, but any real feature names that are passed are silently ignored. -v shows that the members of the workspace that are built use their default set of features instead.

[alexcrichton]

I believe this was first handled in #5390, later reverted in #5430, and currently being discussed at #5364. @matklad may have more to say though!

[matklad]

@jdm yep, we've tried fix that a while back, and it actually broke the Servo's build, so we've rollbacked the change.

I'd rather say that the current semantics of --features with workspaces is completely wrong, rather than that it has a finite number of bugs :-)

We probably should fix features in Cargo holistically, both at the level of resolve and at the level of CLI flags. At this point it is clear that this needs to be a coordinated explicit effort with warnings and opt-in.

[SimonSapin]

I agree that the current semantics in how features and workspaces interact are broken and could use a complete redesign. But other than it needing to be opt-in somehow (`edition = "2018" could have been it, but maybe it’s a bit late now) to avoid breaking existing projects I haven’t yet sat down to think about what the details of what the new design should be.

[ehuss]

The --features flag in a virtual workspace now returns an error. Closing, since there are several other issues tracking feature selection in a workspace (linked above).