Renamed dev-dependency on self isn't respected

[Nemo157]

Problem
Adding a renamed dev-dependency with path = "." doesn't result in the correct name being used during compilation. The dependency is added, but it uses the original package name in the --extern.

Steps

> git clone https://gist.github.com/Nemo157/105a7f43e0920d6ab9572e88871c18ee foo && cd foo
> cargo test -vv --lib
.... rustc ... --extern foo=/home/nemo157/.cargo/shared-target/debug/deps/libfoo-c6907ef92fad7161.rlib ...
error[E0433]: failed to resolve: use of undeclared crate or module `bar`
 --> lib.rs:8:13
  |
8 | fn test() { bar::foo() }
  |             ^^^ use of undeclared crate or module `bar`
> cargo test -vv --test test
.... rustc ... --extern foo=/home/nemo157/.cargo/shared-target/debug/deps/libfoo-c6907ef92fad7161.rlib --extern foo=/home/nemo157/.cargo/shared-target/debug/deps/libfoo-c6907ef92fad7161.rlib ...
error[E0433]: failed to resolve: use of undeclared crate or module `bar`
 --> test.rs:2:17
  |
2 | pub fn test() { bar::foo(); }
  |                 ^^^ use of undeclared crate or module `bar`
> cargo test -vv --doc
.... rustdoc ... --extern foo=/home/nemo157/.cargo/shared-target/debug/deps/libfoo-c6907ef92fad7161.rlib --extern foo=/home/nemo157/.cargo/shared-target/debug/deps/libfoo-c6907ef92fad7161.rlib ...
error[E0433]: failed to resolve: use of undeclared crate or module `bar`
 --> lib.rs:2:1
  |
4 | bar::foo();
  | ^^^ use of undeclared crate or module `bar`

Possible Solution(s)
Apply the requested rename of the dependency.

Notes

Output of cargo version: cargo 1.53.0-nightly (0ed318d18 2021-04-23)

[Eh2406]

Can you make a reproducible example?
I am not understanding what path = "." would mean, you want the package to have a dev-dependency on itself but with a different name?

[Nemo157]

Reproducible example is in the steps: https://gist.github.com/Nemo157/105a7f43e0920d6ab9572e88871c18ee

I am not understanding what path = "." would mean, you want the package to have a dev-dependency on itself but with a different name?

Yes, exactly. For the purposes of writing examples in a crate that will be included in a facade I want to write the examples as if they were in the facade, but able to be run independently without actually building the facade crate. So in the crate stylish-core I write an example on stylish_core::Style that uses use stylish::Style;, and then use a dev-dependency stylish = { package = "stylish-core", path = "." }.

I wouldn't be too heartbroken if it's instead decided that this should be an error. Similar to the error for having duplicate dependencies on the same crate, this would result in the non-lib tests having a duplicate dependency on the library crate with different names. But in that case it should be an explicit error in the crate definition, not a compile-time error because the renaming wasn't respected.

[PaulDance]

@Nemo157 Wouldn't it be simpler to just use stylish_core::Style and explain that it should be done with stylish instead or just put the example in stylish directly?

[Nemo157]

These examples will appear in both the stylish_core and stylish docs, since the latter re-exports everything from the former. Because the types are defined as part of stylish_core the docs must also be defined there.

You can see an existing example of this sort of documentation setup in futures, futures::future::join3 is actually futures_util::future::join3; but the documentation always uses futures rooted paths as futures-util is mostly an implementation detail (by the time you have a reason to depend directly on futures-util instead of futures, you likely know enough about the Rust ecosystem to understand this sort of facade setup and see behind the presentation in the documentation).

The way futures does this by simply having futures-util have a dev-dependency on futures. This is likely the route I will go too. It seems unlikely that cargo can support having the duplicated self-dependency given it erroring out on duplicate renamed dependencies, if that restriction is ever relaxed then maybe my original idea on how this might work could be implemented. Until then I think it's probably better to go for the route of adding an explicit error about the duplicated self-dependency.

[Eh2406]

Thanks @Nemo157 for pointing out the duplication.
I am closing in faver of #9518