diff options
author | Kim Altintop <kim@eagain.io> | 2023-08-08 09:37:18 +0200 |
---|---|---|
committer | Kim Altintop <kim@eagain.io> | 2023-08-08 09:37:18 +0200 |
commit | 475a6cc46568911a7618f95999de06525a2c8ca3 (patch) | |
tree | 5cd06f067bd21c43b39b12b4d686faa87c5211c7 | |
parent | b4b096bed736a06a74f8ae73d7214ece9fd82770 (diff) |
Fix (ignore) doctests
-rw-r--r-- | src/iter.rs | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/iter.rs b/src/iter.rs index 1289c52..724c44b 100644 --- a/src/iter.rs +++ b/src/iter.rs @@ -8,8 +8,8 @@ use std::ops::ControlFlow; /// It is a common pattern that instantiating an effectful iterator is fallible, /// while traversing it is fallible, too. This yields unwieldy signatures like: /// -/// ```no_run -/// fn my_iterator() -> Result<impl Iterator<Item = Result<T, F>>, E> +/// ```ignore +/// fn my_iterator<T, E, F>() -> Result<impl Iterator<Item = Result<T, F>>, E> /// ``` /// /// Often, however, we can unify the error types (`E` and `F` above), which @@ -17,8 +17,8 @@ use std::ops::ControlFlow; /// infallible, but an initialiser error is returned upon the first call to /// `next()`. Ie.: /// -/// ```no_run -/// fn my_iterator() -> impl Iterator<Item = Result<T, E>> +/// ```ignore +/// fn my_iterator<T, E>() -> impl Iterator<Item = Result<T, E>> /// ``` #[must_use = "iterators are lazy and do nothing unless consumed"] pub struct Iter<E, F, I, G> { |