@@ -3657,24 +3657,22 @@ declare_clippy_lint! {
36573657}
36583658
36593659declare_clippy_lint ! {
3660- /// Looks for one of two kinds of expressions:
3661- /// - Calling `<T as TryInto<U>> ::try_into` where `T` also implements `Into<U>`
3662- /// - Calling `<T as TryFrom<U>>::try_from` where `T` also implements `From<U>`
3660+ /// ### What it does
3661+ /// Checks for calls to ` TryInto::try_into` and `TryFrom::try_from` when their infallible counterparts
3662+ /// could be used.
36633663 ///
36643664 /// ### Why is this bad?
3665- /// In those cases, the `TryInto` and `TryFrom` trait implementation is a blanket impl which forwards
3665+ /// In those cases, the `TryInto` and `TryFrom` trait implementation is a blanket impl that forwards
36663666 /// to `Into` or `From`, which always succeeds.
3667- /// Indeed, its associated `Error` type is the empty enum `Infallible`,
3668- /// which is impossible to construct by nature, so the error handling that is then imposed by
3669- /// the `Result<_, Infallible>` is unnecessary and can be avoided simply by calling `.into()` or `::from`
3670- /// directly in the first place.
3667+ /// The returned `Result<_, Infallible>` requires error handling to get the contained value
3668+ /// even though the conversion can never fail.
36713669 ///
36723670 /// ### Example
36733671 /// ```rust
36743672 /// let _: Result<i64, _> = 1i32.try_into();
36753673 /// let _: Result<i64, _> = <_>::try_from(1i32);
36763674 /// ```
3677- /// Use instead:
3675+ /// Use `from`/`into` instead:
36783676 /// ```rust
36793677 /// let _: i64 = 1i32.into();
36803678 /// let _: i64 = <_>::from(1i32);
0 commit comments