From 408b8d5f5101f35d92aa332dfae92e0a44ce583d Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 19 Jan 2023 08:35:04 -0800 Subject: [PATCH] Remove lint mitigation suggesting to use a cargo feature. Since it is not possible to have "private" features, it can be an issue if users enable it without understanding what it is for. --- src/doc/src/reference/semver.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/doc/src/reference/semver.md b/src/doc/src/reference/semver.md index 72be6557daa..36482ff6e65 100644 --- a/src/doc/src/reference/semver.md +++ b/src/doc/src/reference/semver.md @@ -1206,12 +1206,8 @@ Additionally, updating `rustc` to a new version may introduce new lints. Transitive dependencies which introduce new lints should not usually cause a failure because Cargo uses [`--cap-lints`](../../rustc/lints/levels.html#capping-lints) to suppress all lints in dependencies. Mitigating strategies: -* Options for dealing with denying warnings: - * Understand you may need to deal with resolving new warnings whenever you update your dependencies. - * Place `deny(warnings)` behind a [feature][Cargo features], for example `#![cfg_attr(feature = "deny-warnings", deny(warnings))]`. - Set up your automated CI to check your crate with the feature enabled, possibly as an allowed failure with a notification. - Beware that features are exposed to users, so you may want to clearly document it as something that is not to be used. - * If using RUSTFLAGS to pass `-Dwarnings`, also add the `-A` flag to allow lints that are likely to cause issues, such as `-Adeprecated`. +* If you build with warnings denied, understand you may need to deal with resolving new warnings whenever you update your dependencies. + If using RUSTFLAGS to pass `-Dwarnings`, also add the `-A` flag to allow lints that are likely to cause issues, such as `-Adeprecated`. * Introduce deprecations behind a [feature][Cargo features]. For example `#[cfg_attr(feature = "deprecated", deprecated="use bar instead")]`. Then, when you plan to remove an item in a future SemVer breaking change, you can communicate with your users that they should enable the `deprecated` feature *before* updating to remove the use of the deprecated items.