Clippy lints / Correctness
Clippy lint · Correctness · checked with Clippy 0.1.99
clippy::deprecated_semver: the since field must contain a semver-compliant version
What it meansChecks for #[deprecated] annotations with a since field that is not a valid semantic version. Also allows “TBD” to signal future deprecation. It is in the correctness group and denied by default (the build fails).
What you see
error: the since field must contain a semver-compliant version --> main.rs:3:14 | 3 | #[deprecated(since = "forever")] | ^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#deprecated_semver = note: `#[deny(clippy::deprecated_semver)]` on by default
Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.
Does it matter?
For checking the version of the deprecation, it must be a valid semver. Failing that, the contained information is useless.
Code that is almost certainly wrong. Denied by default: the build fails until you fix it or allow it.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
#[deprecated(since = "forever")]
fn something_else() { /* ... */ }
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::deprecated_semver)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
deprecated_semver = "allow"One run
cargo clippy -- -A clippy::deprecated-semverThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Clippy's own documentation
What it does
Checks for #[deprecated] annotations with a since
field that is not a valid semantic version. Also allows “TBD” to signal
future deprecation.
Why is this bad?
For checking the version of the deprecation, it must be a valid semver. Failing that, the contained information is useless.
Example
#[deprecated(since = "forever")]
fn something_else() { /* ... */ }
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- bad_bit_maskChecks for incompatible bit masks in comparisons. The formula for detecting if an expression of the type _ <bit_op> m <cmp_op> c (where <bit_op> is one of {&, |} and <cmp_op> is one of {!=, >=, >, !=, >=, >}) can be determined from the following table: ComparisonBit OpExampleis alwaysFormula == or !=&x & 2 == 3falsec & m != c < or >=&x & 2 < 3truem < c > or <=&x & 1 > 1falsem <= c == or !=|x | 1 == 0falsec | m != c < or >=|x | 1 < 1falsem >= c <= or >|x | 1 > 0truem > c
- cast_slice_different_sizescasting between raw pointers to `[i32]` (element size 4) and `[u8]` (element size 1) does not adjust the count
- char_indices_as_byte_indicesChecks for usage of a character position yielded by .chars().enumerate() in a context where a byte index is expected, such as an argument to a specific str method or indexing into a str or String
- derive_ord_xor_partial_ordLints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd implementation
- derived_hash_with_manual_eqLints against manual PartialEq implementations for types with a derived Hash implementation
- eager_transmutethis transmute is always evaluated eagerly, even if the condition is false
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::bad_bit_maskChecks for incompatible bit masks in comparisons. The formula for detecting if an expression of the type _ <bit_op> m <cmp_op> c (where <bit_op> is one of {&, |} and <cmp_op> is one of {!=, >=, >, !=, >=, >}) can be determined from the following table: ComparisonBit OpExampleis alwaysFormula == or !=&x & 2 == 3falsec & m != c < or >=&x & 2 < 3truem < c > or <=&x & 1 > 1falsem <= c == or !=|x | 1 == 0falsec | m != c < or >=|x | 1 < 1falsem >= c <= or >|x | 1 > 0truem > cRead it next →Did this answer your question?