-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
"cargo install" should be robust against deny(warnings) #17339
Copy link
Copy link
Open
Labels
A-gitArea: anything dealing with gitArea: anything dealing with gitC-bugCategory: bugCategory: bugCommand-installS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Description
Activity
Metadata
Metadata
Assignees
Labels
A-gitArea: anything dealing with gitArea: anything dealing with gitC-bugCategory: bugCategory: bugCommand-installS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
More than once have I encountered issues where I wanted to
cargo installa crate that unfortunately had#![deny(warnings)]among its attributes. This is generally considered a bad thing for crates to do, but sadly that does not stop people from doing it. Now I have to wait until upstream fixes their code or fiddle withRUSTFLAGS=-Asomethingwhich will also rebuild all dependencies, it's all not very nice.As of right now, one example of a command that fails due to this issue is
When building dependencies, cargo uses
--cap-lintsto make this a non-issue. However, when installing a crate from crates.io or from a git repo, then as far as I am concerned even the binary crate I am installing is a "dependency" -- it is not code I wrote or can do much about. It would be nice if cargo could treat it as such and apply--cap-lints. (I don't care whether it caps the lints to "allow" or "warn" as long as installation isn't blocked by a misplaced#![deny(warnings)].)Related issues:
#![deny(warnings)]today so either that did not work or it did get reverted.