mirror of
https://github.com/rust-lang/rust-clippy
synced 2024-11-23 21:23:56 +00:00
update docs
This commit is contained in:
parent
04b0857691
commit
fbb3f759e2
2 changed files with 10 additions and 5 deletions
|
@ -3292,10 +3292,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
|
||||
|
|
|
@ -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)]
|
||||
|
|
Loading…
Reference in a new issue