| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is my first PR; be gentle!
In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict, since we don't require `T` to have the same size, just `size_of::<T>() * capacity` to be the same, since that is what results in `Layout::size` being the same in `dealloc`, which is really what matters.
Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts`, which I think is useful advise that could also be mentioned in the docs, so I added that too.
Let me know what you think! :)
|
|
|
|
|
|
Made the fields of VecDeque's Iter private by creating a Iter::new(...) function to create a new instance of Iter and migrating usage to use Iter::new(...).
|
|
Use MaybeUninit in VecDeque to remove the undefined behavior of slice
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Ref https://github.com/rust-lang/rust/issues/74189. Adjust the code to follow the [doc.rust-lang.org/reference/behavior-considered-undefined.html](https://doc.rust-lang.org/reference/behavior-considered-undefined.html).
* Change the return type of `buffer_as_slice` from `&[T]` to `&[MaybeUninit<T>]`.
* Add some corresponding safety comments.
Benchmark results:
master 8d6f527530f4ba974d922269267fe89050188789
```rust
test collections::vec_deque::tests::bench_pop_back_100 ... bench: 47 ns/iter (+/- 1)
test collections::vec_deque::tests::bench_pop_front_100 ... bench: 50 ns/iter (+/- 4)
test collections::vec_deque::tests::bench_push_back_100 ... bench: 69 ns/iter (+/- 10)
test collections::vec_deque::tests::bench_push_front_100 ... bench: 72 ns/iter (+/- 6)
test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 145,891 ns/iter (+/- 7,975)
test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 141,647 ns/iter (+/- 3,711)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 120,132 ns/iter (+/- 4,078)
```
This PR
```rust
test collections::vec_deque::tests::bench_pop_back_100 ... bench: 48 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_pop_front_100 ... bench: 51 ns/iter (+/- 3)
test collections::vec_deque::tests::bench_push_back_100 ... bench: 73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_push_front_100 ... bench: 73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 131,796 ns/iter (+/- 5,440)
test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 137,563 ns/iter (+/- 3,349)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 128,815 ns/iter (+/- 3,289)
```
|
|
|
|
Improve doc wording for retain on some collections
I found the documentation wording on the various retain methods on many collections to be unusual.
I tried to invert the relation by switching `such that` with `for which` .
|
|
|
|
r=Mark-Simulacrum
Use modern formatting for format! macros
This updates the standard library's documentation to use the new format_args syntax.
The documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
`eprintln!("{}", e)` becomes `eprintln!("{e}")`, but `eprintln!("{}", e.kind())` remains untouched.
|
|
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
|
|
|
|
Signed-off-by: JmPotato <ghzpotato@gmail.com>
|
|
|
|
BTree: remove dead data needlessly complicating insert
Possibly needless instructions generated
r? rust-lang/libs
r? ``@Amanieu``
cc ``@frank-king``
|
|
|
|
|
|
fix typo in btree/vec doc: Self -> self
this pr fixes #92345
the documentation refers to the object the method is called for, not the type, so it should be using the lower case self.
|
|
|
|
BTree: simplify test code
Mostly, use `from` & `from_iter`.
|
|
Fix a layout possible miscalculation in `alloc::RawVec`
A layout miscalculation could happen in `RawVec` when used with a type whose size isn't a multiple of its alignment. I don't know if such type can exist in Rust, but the Layout API provides ways to manipulate such types. Anyway, it is better to calculate memory size in a consistent way.
|
|
|
|
|
|
Improve the documentation of drain members
hopefully fixes #92765
|
|
|
|
Move `{core,std}::stream::Stream` to `{core,std}::async_iter::AsyncIterator`
Following amendments in https://github.com/rust-lang/rfcs/pull/3208/.
cc #79024
cc ``@yoshuawuyts`` ``@joshtriplett``
|
|
Add documentation to more `From::from` implementations.
For users looking at documentation through IDE popups, this gives them relevant information rather than the generic trait documentation wording “Performs the conversion”. For users reading the documentation for a specific type for any reason, this informs them when the conversion may allocate or copy significant memory versus when it is always a move or cheap copy.
Notes on specific cases:
* The new documentation for `From<T> for T` explains that it is not a conversion at all.
* Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other central blanket implementation of conversion.
* The new documentation for construction of maps and sets from arrays of keys mentions the handling of duplicates. Future work could be to do this for *all* code paths that convert an iterable to a map or set.
* I did not add documentation to conversions of a specific error type to a more general error type.
* I did not add documentation to unstable code.
This change was prepared by searching for the text "From<... for" and so may have missed some cases that for whatever reason did not match. I also looked for `Into` impls but did not find any worth documenting by the above criteria.
|
|
|
|
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
|
|
|
|
|
|
Stabilize cfg_target_has_atomic
`target_has_atomic_equal_alignment` is now tracked separately in #93822.
Closes #32976
|
|
Closes #32976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The function gets the inner value, cloning only if necessary.
|
|
Bootstrap compiler update
r? ``@Mark-Simulacrum``
|
|
|
|
juniorbassani:use-from-array-in-collections-examples, r=yaahc
Replace iterator-based construction of collections by `Into<T>`
Just a few quality of life improvements in the doc examples. I also removed some `Vec`s in favor of arrays.
|
|
Stabilize arc_new_cyclic
This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet.
Closes #75861 .
``@rustbot`` label +T-libs-api
|
|
|
|
Improve `Arc` and `Rc` documentation
This makes two changes (I can split the PR if necessary, but the changes are pretty small):
1. A bunch of trait implementations claimed to be zero cost; however, they use the `Arc<T>: From<Box<T>>` impl which is definitely not free, especially for large dynamically sized `T`.
2. The code in deferred initialization examples unnecessarily used excessive amounts of `unsafe`. This has been reduced.
|
|
|
|
AngelicosPhosphoros:try_smarter_vec_from_iter_48994_2, r=Mark-Simulacrum
Improve capacity estimation in Vec::from_iter
Iterates on the attempt made in #53086.
Closes #48994
|
|
Closes #48994
|
|
doc: guarantee call order for sort_by_cached_key
`slice::sort_by_cached_key` takes a caching function `f: impl FnMut(&T) -> K`, which means that the order that calls to the caching function are made is user-visible. This adds a clause to the documentation to promise the current behavior, which is that `f` is called on all elements of the slice from left to right, unless the slice has len < 2 in which case `f` is not called.
For example, this can be used to ensure that the following code is a correct way to involve the index of the element in the sort key:
```rust
let mut index = 0;
slice.sort_by_cached_key(|x| (my_key(index, x), index += 1).0);
```
|
