From 80447ad68de719f8f8f5c9825dcc0b82531e272d Mon Sep 17 00:00:00 2001 From: Catherine <114838443+Centri3@users.noreply.github.com> Date: Mon, 26 Jun 2023 14:32:01 -0500 Subject: [PATCH] update docs --- clippy_lints/src/methods/mod.rs | 13 +++++++++---- tests/ui/manual_try_fold.rs | 2 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/clippy_lints/src/methods/mod.rs b/clippy_lints/src/methods/mod.rs index a177be050083..57516096a00e 100644 --- a/clippy_lints/src/methods/mod.rs +++ b/clippy_lints/src/methods/mod.rs @@ -3290,10 +3290,15 @@ declare_clippy_lint! { /// Checks for usage of `Iterator::fold` with a type that implements `Try`. /// /// ### Why is this bad? - /// This is better represented with `try_fold`, but this has one major difference: It will - /// short-circuit on failure. *This is almost always what you want*. This can also open the door - /// for additional optimizations as well, as rustc can guarantee the function is never - /// called on `None`, `Err`, etc., alleviating otherwise necessary checks. + /// This should use `try_fold` instead, which short-circuits on failure, thus opening the door + /// for additional optimizations not possible with `fold` as rustc can guarantee the function is + /// never called on `None`, `Err`, etc., alleviating otherwise necessary checks. It's also + /// slightly more idiomatic. + /// + /// ### Known issues + /// This lint doesn't take into account whether a function does something on the failure case, + /// i.e., whether short-circuiting will affect behavior. Refactoring to `try_fold` is not + /// desirable in those cases. /// /// ### Example /// ```rust diff --git a/tests/ui/manual_try_fold.rs b/tests/ui/manual_try_fold.rs index e00371eb2288..4521e9fa1a50 100644 --- a/tests/ui/manual_try_fold.rs +++ b/tests/ui/manual_try_fold.rs @@ -1,4 +1,4 @@ -//@aux-build:proc_macros.rs +//@aux-build:proc_macros.rs:proc-macro #![allow(clippy::unnecessary_fold, unused)] #![warn(clippy::manual_try_fold)] #![feature(try_trait_v2)]