Open roblabla opened 3 years ago
Wasn't there a problem that it possibly makes your library fail to build on crater?
I feel crater should probably use rustc's cap-lint too if it doesn't already.
Even if the reasoning in the book is wrong, #![deny(warnings)]
is still an anti-pattern that makes contributors lives harder for no reason. It is bad enough and widespread enough that I have had to add --cap-lints warn
to my global RUSTFLAGS
to workaround the issue (which is itself bad because it downgrades all the deny
-by-default warnings to just warn
, but that is a lesser evil).
https://reddit.com/r/rust/comments/f5xpib/psa_denywarnings_is_actively_harmful/ has some discussion, and mentions that crater does use cap-lints
for the beta runs, but this runs into the same issue I mention that it also disables the deny
-by-default lints. Given the forward compat lifecycle found through a deny stage it seems very unfortunate if crater would not pick up forward compat issues.
So from my understanding we could:
Am I right?
The main reason why
deny(warning)
is considered an antipattern, according to the patterns guide, is that a crate author opts out of Rust's stability guarantees, since Rust is allowed to add new warnings to new versions. Thus, new versions of rust may break the crate.However, rust currently caps the the max lint level to "warn" when building dependencies. Thus, even if a crate specifies
#![deny(warning)]
, the warnings will not be upgraded to denies when it is built as a dependency. See this comment:As such,
deny(warning)
is actually an entirely fine pattern for libraries to use. It may be worth amending thedeny(warning)
antipattern crate to explain that it only applies to binary crates.CC https://github.com/rust-unofficial/patterns/issues/46