| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix uses of "adaptor"
These docs are in en_US, so "adapter" is the correct spelling (and indeed used in the next line.)
A second commit comes along for the ride to fix other instances in non-rustdoc comments.
|
|
|
|
|
|
|
|
|
|
AudaciousAxiom:docs/missing-closing-code-block-fences, r=tgross35
docs(std): add missing closing code block fences in doc comments
This PR adds a few closing code block fences which I believe are missing in some doc comments. It seems that rustdoc just autocloses code blocks at the end of doc comments and thus these were easily overlooked: I do not think these code blocks are special in any way.
I found these when working on a Clippy lint that checks the last sentence of doc comments for terminal punctuation, and these were failing cases when testing against the std. Therefore I am not entirely sure these are all such cases, but still have high hopes that they are (or at least a well-defined subset of them).
|
|
core: add Peekable::next_if_map
Implementation for rust-lang/rust#143702
|
|
|
|
|
|
r=jhpratt
Stabilize `core::iter::chain`
Closes rust-lang/rust#125964
|
|
|
|
This patch fixes the Markdown formatting in
`std::core::iter::Iterator::by_ref`. Code is used inside a link without
the backticks around the code.
|
|
|
|
Improve formatting of doc code blocks
We don't currently apply automatic formatting to doc comment code blocks. As a
result, it has built up various idiosyncracies, which make such automatic
formatting difficult. Some of those idiosyncracies also make things harder for
human readers or other tools.
This PR makes a few improvements to doc code formatting, in the hopes of making
future automatic formatting easier, as well as in many cases providing net
readability improvements.
I would suggest reading each commit separately, as each commit contains one
class of changes.
|
|
This makes it easier for humans to parse, and improves the result of
potential future automatic formatting.
|
|
Because doc code does not get automatically formatted, some doc code has
creative placements of comments that automatic formatting can't handle.
Reformat those comments to make the resulting code support standard Rust
formatting without breaking; this is generally an improvement to
readability as well.
Some comments are not indented to the prevailing indent, and are instead
aligned under some bit of code. Indent them to the prevailing indent,
and put spaces *inside* the comments to align them with code.
Some comments span several lines of code (which aren't the line the
comment is about) and expect alignment. Reformat them into one comment
not broken up by unrelated intervening code.
Some comments are placed on the same line as an opening brace, placing
them effectively inside the subsequent block, such that formatting would
typically format them like a line of that block. Move those comments to
attach them to what they apply to.
Some comments are placed on the same line as a one-line braced block,
effectively attaching them to the closing brace, even though they're
about the code inside the block. Reformat to make sure the comment will
stay on the same line as the code it's commenting.
|
|
|
|
address clippy formatting nits
- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
|
|
fix Zip unsoundness (again)
Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. #82292 tried to fix unsoundness (#82291) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (#86443), but the fix #86452 didn't fix it for nested Zip iterators (#137255).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in #83791 but we haven't made use of that so far.
fixes #137255
|
|
|
|
|
|
|
|
|
|
Full list of `impl const Default` types:
- ()
- bool
- char
- Cell
- std::ascii::Char
- usize
- u8
- u16
- u32
- u64
- u128
- i8
- i16
- i32
- i64
- i128
- f16
- f32
- f64
- f128
- std::marker::PhantomData<T>
- Option<T>
- std::iter::Empty<T>
- std::ptr::Alignment
- &[T]
- &mut [T]
- &str
- &mut str
- String
- Vec<T>
|
|
Tracking issue number for `iter_macro`
Tracking issue: rust-lang/rust#142269
|
|
small iter.intersperse.fold() optimization
No need to call into fold when the first item is already None, this avoids some redundant work for empty iterators.
"But it uses Fuse" one might want to protest, but Fuse is specialized and may call into the inner iterator anyway.
|
|
|
|
Change `core::iter::Fuse`'s `Default` impl to do what its docs say it does
The [docs on `impl<I: Default> Default for core::iter::Fuse<I>`](https://doc.rust-lang.org/nightly/std/iter/struct.Fuse.html#impl-Default-for-Fuse%3CI%3E) say (as the `I: Default` bound implies) that `Fuse::<I>::default` "Creates a `Fuse` iterator from the default value of `I`". However, the implementation creates a `Fuse` with `Fuse { iter: Default::default() }`, and since the `iter` field is an `Option<I>`, this is actually `Fuse { iter: None }`, not `Fuse { iter: Some(I::default()) }`, so `Fuse::<I>::default()` always returns an empty iterator, even if `I::default()` would not be empty.
This PR changes `Fuse`'s `Default` implementation to match the documentation. This will be a behavior change for anyone currently using `Fuse::<I>::default()` where `I::default()` is not an empty iterator[^1], as `Fuse::<I>::default()` will now also not be an empty iterator.
(Alternately, the docs could be updated to reflect what the current implementation actually does, i.e. returns an always-exhausted iterator that never yields any items (even if `I::default()` would have yielded items). With this option, the `I: Default` bound could also be removed to reflect that no `I` is ever created.)
[Current behavior example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a1e0adc4badca3dc11bfb70a99213249) (maybe an example like this should be added to the docs either way?)
This PR changes publicly observable behavior, so I think requires at least a T-libs-api FCP?
r? libs-api
cc https://github.com/rust-lang/rust/issues/140961
`impl<I: Default> Default for Fuse<I>` was added in 1.70.0 (https://github.com/rust-lang/rust/pull/99929), and it's docs and behavior do not appear to have changed since (`Fuse`'s `iter` field has been an `Option` since before the impl was added).
[^1]: IIUC it is a "de facto" guideline for the stdlib that an iterator type's `default()` should be empty (and for iterators where that would not make sense, they should not implement `Default`): cc https://github.com/rust-lang/libs-team/issues/77#issuecomment-1194681709 , so for stdlib iterators, I don't think this would change anything. However, if a user has a custom `Iterator` type `I`, *and* they are using `Fuse<I>`, *and* they call `Fuse::<I>::default()`, this may change the behavior of their code.
|
|
|
|
Add a doctest with a non-empty-by-default iterator.
|
|
No need to call into fold when the first item is already None,
this avoids some redundant work for empty iterators.
"But it uses Fuse" one might want to protest, but Fuse is specialized
and may call into the inner iterator anyway.
|
|
|
|
|
|
Some history: The Zip TrustedRandomAccess specialization has tried
to emulate the side-effects of the naive implementation for a long time,
including backwards iteration. 82292¹ tried to fix unsoundness (82291¹) in that
side-effect-preservation code, but this introduced some panic-safety
unsoundness (86443¹), but the fix 86452¹ didn't fix it for nested Zip
iterators (137255¹).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces
the number of cases in which side-effects will be preserved; the necessary
API guarantee change was approved in 83791¹ but we haven't made use of that
so far.
¹ see merge commit for linkfied issues.
|
|
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
|
|
Implement `advance_by` via `try_fold` for `Sized` iterators
When `try_fold` is overriden, it is usually easier for compilers to optimize.
Example difference: https://iter.godbolt.org/z/z8cEfnKro
|
|
|
|
When `try_fold` is overriden, it is usually easier for compilers to
optimize.
|
|
Update iterator.rs to use arrays by value
Update examples to no longer avoid iterating arrays for #84513
|
|
Update examples to no longer avoid iterating arrays for #84513
|
|
Steer docs to `utf8_chunks` and `Iterator::take`
- Adds `limit` as an alias of `take` (as this is [what Java calls this operation](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#limit-long-));
- Says that [`Utf8Chunks`](https://doc.rust-lang.org/std/str/struct.Utf8Chunks.html) comes from [`[u8]::utf8_chunks`](https://doc.rust-lang.org/std/primitive.slice.html#method.utf8_chunks).
``@rustbot`` label +A-docs
|
|
This reverts commit ed5f31ab01d41a01b7206eafdf97b458dc41141a.
|
|
`Utf8Chunks`
|
|
r=workingjubilee
docs: Add example to `Iterator::take` with `by_ref`
If you want to logically split an iterator after `n` items, you might first discover `take`. Before this change, you'd find that `take` consumes the iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's hard to discover, especially since `by_ref` is a bit abstract and `Iterator` has many methods.
After this change, you'd see the example showing `take` along with `by_ref`, which allows you to continue using the rest of the iterator. `by_ref` had a good example involving `take` already, so this change just duplicates that existing example under `take`.
|
|
fix docs for `Peekable::next_if{_eq}`
These seem like copy-paste errors
(except `saves the value of` 👉 `retains` which just sounds better to me)
|
|
|
|
|
|
If you want to logically split an iterator after `n` items, you might first
discover `take`. Before this change, you'd find that `take` consumes the
iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's
hard to discover, especially since `by_ref` is a bit abstract and `Iterator`
has many methods.
After this change, you'd see the example showing `take` along with `by_ref`,
which allows you to continue using the rest of the iterator. `by_ref` had a
good example involving `take` already, so this change just duplicates that
existing example under `take`.
|
|
Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are
only needed by reference or not at all. There is already some precedent
for this, given that `__iterator_get_unchecked` is implemented, which
can skip elements. The reduced clones are technically observable by a
user impl of `Clone`.
|
