update docs
This commit is contained in:
parent
04b0857691
commit
fbb3f759e2
@ -3292,10 +3292,15 @@
|
|||||||
/// Checks for usage of `Iterator::fold` with a type that implements `Try`.
|
/// Checks for usage of `Iterator::fold` with a type that implements `Try`.
|
||||||
///
|
///
|
||||||
/// ### Why is this bad?
|
/// ### Why is this bad?
|
||||||
/// This is better represented with `try_fold`, but this has one major difference: It will
|
/// This should use `try_fold` instead, which short-circuits on failure, thus opening the door
|
||||||
/// short-circuit on failure. *This is almost always what you want*. This can also open the door
|
/// for additional optimizations not possible with `fold` as rustc can guarantee the function is
|
||||||
/// for additional optimizations as well, as rustc can guarantee the function is never
|
/// never called on `None`, `Err`, etc., alleviating otherwise necessary checks. It's also
|
||||||
/// called on `None`, `Err`, etc., alleviating otherwise necessary checks.
|
/// 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
|
/// ### Example
|
||||||
/// ```rust
|
/// ```rust
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
//@aux-build:proc_macros.rs
|
//@aux-build:proc_macros.rs:proc-macro
|
||||||
#![allow(clippy::unnecessary_fold, unused)]
|
#![allow(clippy::unnecessary_fold, unused)]
|
||||||
#![warn(clippy::manual_try_fold)]
|
#![warn(clippy::manual_try_fold)]
|
||||||
#![feature(try_trait_v2)]
|
#![feature(try_trait_v2)]
|
||||||
|
Loading…
Reference in New Issue
Block a user