workspace.exclude disregarded for crate in subdir of workspace.member

[Enselic]

Problem

It seems as if cargo does not always notice that a package is part of workspace.exclude . This happens when the excluded package is in a subdir of a package which is in workspace.members, and e.g. cargo check is invoked directly on the excluded package.

Step-by-step

1. Cherry-pick this commit to the cargo repo which adds the following test:

#[cargo_test]
fn excluded_subcrate_of_workspace_member() {
    let p = project()
        .file(
            "Cargo.toml",
            r#"
                [workspace]
                members = [
                    "member",
                ]
                exclude = [
                    "member/excluded",
                ]
            "#,
        )
        .file("member/src/main.rs", "fn main() {}")
        .file("member/Cargo.toml", &basic_manifest("member", "0.1.0"))
        .file("member/excluded/src/main.rs", "fn main() {}")
        .file(
            "member/excluded/Cargo.toml",
            &basic_manifest("excluded", "0.1.0"),
        );
    let p = p.build();

    p.cargo("check").cwd("member/excluded").run();
}

2. cargo test excluded_subcrate_of_workspace_member

Expected

Test passes

Actual

The test fails with

--- stderr
error: current package believes it's in a workspace when it's not:
current:   /home/martin/src/cargo/target/tmp/cit/t0/foo/member/excluded/Cargo.toml
workspace: /home/martin/src/cargo/target/tmp/cit/t0/foo/Cargo.toml

this may be fixable by adding `member/excluded` to the `workspace.members` array of the manifest located at: /home/martin/src/cargo/target/tmp/cit/t0/foo/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

which is strange, since the package is already in the workspace.exclude array. But it does not seem to be noticed by cargo.

Version

git master branch of cargo

[ehuss]

Thanks for the report! I believe this is a duplicate of #6745, so closing in favor of that.