Cargo-slice ignores members property of cargo workspaces

[criemen]

Cargo-slice seems to ignore the members property of cargo workspaces.
You can see the behavior on this branch if you run bazel run //misc/bazel/3rdparty:vendor_rust_deps.

I'm getting the output

Error: Failed to splice workspace

Caused by:
    Some manifests are not being tracked.
    Please add the following labels to the `manifests` key:
     //rust:ql/integration-tests/hello-project/Cargo.toml
     //rust:ql/integration-tests/hello-workspace/Cargo.toml
     //rust:ql/integration-tests/hello-workspace/exe/Cargo.toml
     //rust:ql/integration-tests/hello-workspace/lib/Cargo.toml
     //rust:ql/integration-tests/options/cfg/Cargo.toml
     //rust:ql/integration-tests/options/features/Cargo.toml
     //rust:ql/integration-tests/options/target/Cargo.toml.

despite the workspaces Cargo.toml file explicitly listing which members belong to this workspace, and the listed Cargo.toml files in the error message don't.

[idekker]

We're experiencing the same issue. In our Bazel workspace we have a different Bazel 'output' directory (.bazel) where we make the Rust toolchain available (to be able to use cargo for Rust-only development; the Bazel workspace contains much more). Next to that there are other directories which are extracted from cached archives (e.g. an sdk). Due to legacy reasons they are inside the workspace / not in the .bazel directory.

In both cargo-bazel finds Cargo.toml files which we do not list in our manifest because we're not interested in them. They are also not part of our cargo workspace.

Before cargo-bazel got to finding these cargo files I had to patch cargo-bazel to (eventually) ignore these directories altogether. Both of these contain symlink cycles that the workspace discoverer doesn't like. Maybe what we really need is a way to ignore paths for the workspace discoverer, just like it is possible to ignore paths for Bazel with .bazelignore: https://bazel.build/run/bazelrc#bazelignore

This issue was introduced with the 0.55 release.

[illicitonion]

These should be addressed by #3102 and #3103 - sorry for the breakage here!

[idekker]

Tested 0.56.0 which contains #3103, but it seems that doesn't work for us. For us --symlink_prefix is set to .bazel/ubuntu- (where ubuntu is something different for other configurations, so .bazel is just a regular directory.

The result is that it is still failing over the symlink loop .bazel/ubuntu-workspace/.bazel indirectly linking back to .bazel.