Skip to content

dependencies warning control, overriding path heuristic #8546

@ijackson

Description

@ijackson

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Error and warning messages generated by Cargo itself.C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions