[replace] silently ignored if crate is part of a workspace

[lilith]

Using cargo 0.13.0-nightly (b78beb1 2016-09-01)
Also reproduced with cargo 0.13.0-nightly (9399229 2016-09-14)
Repro:

git clone https://github.com/nathanaeljones/cargo_replace_test
cd cargo_replace_test/any_crate
cargo build
(note pkg-config pulled from crates.io)
cd ..
git checkout no_workspace
cargo build
(note pkg-config pulled from replacement location)

[SergioBenitez]

Just ran into the issue (I believe) you're describing. To be clear, Cargo ignores the [replace] section in workspace non-root crates without emitting a warning. However, not emitting a warning will surely lead to confusion (as it did for me). Thus, Cargo should emit a warning when it ignores [replace]or, better yet, fail with an error.

[lilith]

What do you mean by root crate? Are there any circumstances in which Cargo honors [replace] if workspaces are in use?

[SergioBenitez]

Yes. Cargo honors [replace] if the section is placed in the root crate or virtual root crate.

[lilith]

I cannot reproduce success in that scenario.

[SergioBenitez]

I'm on IRC as @sergio. Ping me and let's see if we can find the differences.

[lilith]

So, I can now reproduce that success. I have a failed build against a August nightly of cargo where it fails, and some corner cases where the lockfile cache doesn't get updated, but I think I have a path to success for my actual project as well as the repro above.

Raising an error would be super helpful, though.

[alexcrichton]

@nathanaeljones ah ok, looks like things got sorted out with the right build here? Could you clarify though what error should be raised?

[SergioBenitez]

@alexcrichton No, the issue still exists. See my original comment:

Just ran into the issue (I believe) you're describing. To be clear, Cargo ignores the [replace] section in workspace non-root crates without emitting a warning. However, not emitting a warning will surely lead to confusion (as it did for me). Thus, Cargo should emit a warning when it ignores [replace]or, better yet, fail with an error.

[alexcrichton]

Oh right, indeed! Sounds good to me.

[sanmai-NL]

So this issue can be closed? @alexcrichton

[alexcrichton]

I believe so, yes!