Clippy lints / Nursery
Clippy lint · Nursery · checked with Clippy 0.1.99
clippy::fallible_impl_from: consider implementing `TryFrom` instead
What it meansChecks for impls of From<..> that contain panic!() or unwrap() It is in the nursery group and off by default.
What you see
warning: consider implementing `TryFrom` instead --> main.rs:5:1 | 5 | / impl From<String> for Foo { 6 | | fn from(s: String) -> Self { 7 | | Foo(s.parse().unwrap()) 8 | | } 9 | | } | |_^ | = help: `From` is intended for infallible conversions only. Use `TryFrom` if there's a possibility for the conversion to fail note: potential failure(s) --> main.rs:7:13 | 7 | Foo(s.parse().unwrap()) | ^^^^^^^^^^^^^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#fallible_impl_from = note: `-W clippy::fallible-impl-from` implied by `-W clippy::nursery`
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?
TryFrom should be used if there’s a possibility of failure.
New lints still being finished. Off by default and may have false positives.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
struct Foo(i32);
impl From<String> for Foo {
fn from(s: String) -> Self {
Foo(s.parse().unwrap())
}
}
Write this instead
struct Foo(i32);
impl TryFrom<String> for Foo {
type Error = ();
fn try_from(s: String) -> Result<Self, Self::Error> {
if let Ok(parsed) = s.parse() {
Ok(Foo(parsed))
} else {
Err(())
}
}
}
Turn it off, or on
It is off by default. To use it, set it to warn or deny:
Whole crate (Cargo.toml)
[lints.clippy]
fallible_impl_from = "warn"In code
#![warn(clippy::fallible_impl_from)]One run
cargo clippy -- -W clippy::fallible-impl-fromThe [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 impls of From<..> that contain panic!() or unwrap()
Why is this bad?
TryFrom should be used if there’s a possibility of failure.
Example
struct Foo(i32);
impl From<String> for Foo {
fn from(s: String) -> Self {
Foo(s.parse().unwrap())
}
}
Use instead:
struct Foo(i32);
impl TryFrom<String> for Foo {
type Error = ();
fn try_from(s: String) -> Result<Self, Self::Error> {
if let Ok(parsed) = s.parse() {
Ok(Foo(parsed))
} else {
Err(())
}
}
}
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- redundant_cloneChecks for a redundant clone() (and its relatives) which clones an owned value that is going to be dropped without further use
- doc_link_codecode link adjacent to code text
- empty_enumsChecks for enums with no variants, which therefore are uninhabited types (cannot be instantiated). As of this writing, the never_type is still a nightly-only experimental API. Therefore, this lint is only triggered if #![feature(never_type)] is enabled
- equatable_if_letChecks for pattern matchings that can be expressed using equality
- future_not_sendfuture cannot be sent between threads safely
- imprecise_flopscube-root of a number can be computed more accurately
- iter_on_empty_collectionsChecks for calls to iter, iter_mut or into_iter on empty collections
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::redundant_cloneChecks for a redundant clone() (and its relatives) which clones an owned value that is going to be dropped without further useRead it next →Did this answer your question?