dependencies warning control, overriding path heuristic

Maintainers notes

• https://github.com/rust-lang/cargo/issues/8546#issuecomment-902914957 lists proposed solution and general idea on solving it

Describe the problem you are trying to solve

I am working on a project with upstream dependencies, some of which I have had to edit locally. So (pending an upstream release, and sometimes even pending locally committing the upstream code) I have edited my Cargo.toml to have a path dependency on the upstream.

However, the upstream has a number of warnings from rustc.

When I compile the same crate as a non-path dependency, cargo gets the version from crates.io - which has the same warnings - but the warnings are suppressed. Evidently cargo treats the use of a path dependency as an indication that I am a developer of the dependency and therefore want to see the warnings. (I failed to find a discussion of this in the cargo documentation.)

Describe the solution you'd like

This path dependency heuristic is a good rule of thumb. Usually it will be right. But it would be good if there were a way to override it.

I suggest an additional entry in the dependency, alongside the path key. propagate_warnings maybe. The default would be false for non-path dependencies, and true for path dependencies, but it could be overridden by the depending crate.

Warnings would be shown to the user if all of the dependency links from the toplevel to the relevant place had propagate_warnings. (I haven't checked but presumably this is what cargo does already, only just checking for path dependencies.)

In my scenario this would mean that I would see the warnings if I ran cargo build in the directory of my dependency, but not in the directory of my own project. That seems right to me.

Notes

It seems that a git dependency suppresses the warnings. So I could use a git dependency instead, as a workaround. In my situation this is less than ideal, because it means I must always be sure to commit all my edits to the dependency. For another user it might well be useful to enable the warnings.

Another possibility would be some kind of global configuration to specify which crates to print warnings for. That would be independently useful but it would be less helpful in my specific situation.

Start with the proposed solution and general approach in the linked comment, then trace Cargo's existing handling of path and git dependencies for compiler-warning suppression. The issue names no files or tests; done means agreeing on the dependency-level override semantics and covering the described path, non-path, and transitive-warning cases.