cargo fmt --package: not a member of workspace (Implicit workspace)

[kuviman]

Tested both in current stable & nightly

$ rustup run stable cargo fmt --version
<No output: bug?>
$ rustup run stable rustfmt --version
rustfmt 1.2.0-stable (09940a7 2019-03-27)
$ rustup run nightly cargo fmt --version
rustfmt 1.3.0-nightly (d334502 2019-06-09)

Steps to reproduce

1. cargo new cargo-fmt-test && cd cargo-fmt-test
2. cargo new --lib --name dependency-crate-name dependency-dir-name
3. Add dependency-crate-name = { path = "dependency-dir-name" } to dependencies in Cargo.toml

So, we have a path dependency with a directory name different than crate name. Looks like it is only broken if names differ.

Also, these steps do not create [workspace] section in Cargo.toml, so this is an implicit workspace or something. If [workspace] is present, then it looks like cargo fmt works correctly.

cargo fmt --all

$ cargo fmt --all -v
[bin (2018)] "/home/kuviman/Temp/cargo-fmt-test/src/main.rs"
rustfmt --edition 2018 /home/kuviman/Temp/cargo-fmt-test/src/main.rs

^This should format the dependency as well, but it does not

cargo fmt --package dependency-crate-name

$ cargo fmt --package dependency-crate-name
package `dependency-dir-name` is not a member of the workspace
usage: cargo fmt [options]
<...>

^ So, cargo-fmt does not see the dependency as part of the workspace.
Also there is usage output for some reason

Default cargo subcommands do work (like cargo test --package dependency-crate-name).

[topecongiro]

I think that we just need to dig a litter deeper into the data returned from cargo_metadata and figure out the correct name of the package if it differs from the directory name.

[calebcartwright]

I took a look at this one, and detailed my findings below. I personally feel like there's two items here, and what is described above is the expected behavior when using cargo fmt --package .. in this context, but that there might be a bug/issue with cargo fmt --all here.

Following the example outlined above:

If you run cargo metadata --no-deps --format-version 1 in the root cargo-fmt-test directory, the resulting metadata shows only a single package (cargo-fmt-test) which makes sense considering that's the only package defined. (dependency-crate-name is just a dependency of the cargo-fmt-test package that happens to be path-based)

Accordingly, when cargo fmt --package dependency-crate-name is run from the root directory, the specified package (dependency-crate-name) is not in the list of packages returned from cargo_metadata used here.

It doesn't matter that there's a difference in the package name and directory name for depedency-crate-name. Even if they're named the same, it's still just a dependency, so the behavior is the same. The problem is that dependency-crate-name isn't defined as a package/workspace member in the root cargo-fmt-test directory.

As noted in the OP, if you declare a [workspace] in the root level cargo-fmt-test directory to include dependency-crate-name explicitly as a workspace member (and not just a dependency) then cargo fmt --package dependency-crate-name will work just fine, as will cargo fmt --all.

I think the problem with cargo fmt --all in the original example in the OP is due to the difference in the names between the dependency and the directory, but still looking into it.

[calebcartwright]

Believe I have a fix for cargo fmt --all when the dependency name and directory path differ. Will open a PR shortly

[topecongiro]

Closed via #3664.