| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix missing remaining compiler specific cfg information
Follow-up of #89596. We forgot a few of them:
r? `@notriddle`
|
|
|
|
r=joshtriplett
Fix uppercase/lowercase error
Fix https://github.com/rust-lang/rust/pull/89694#discussion_r726829890
r? ````@joshtriplett````
|
|
The unifying theme for this commit is weak, admittedly. I put together a
list of "expensive" functions when I originally proposed this whole
effort, but nobody's cared about that criterion. Still, it's a decent
way to bite off a not-too-big chunk of work.
Given the grab bag nature of this commit, the messages I used vary quite
a bit.
|
|
|
|
|
|
|
|
r=joshtriplett
Add #[must_use] to non-mutating verb methods
These are methods that could be misconstrued to mutate their input, similar to #89694. I gave each one a different custom message.
I wrote that `upgrade` and `downgrade` don't modify the input pointers. Logically they don't, but technically they do...
Parent issue: #89692
r? ```@joshtriplett```
|
|
Add #[must_use] to as_type conversions
Clippy missed these:
```rust
alloc::string::String fn as_mut_str(&mut self) -> &mut str;
core::mem::NonNull<T> unsafe fn as_uninit_mut<'a>(&mut self) -> &'a MaybeUninit<T>;
str unsafe fn as_bytes_mut(&mut self) -> &mut [u8];
str fn as_mut_ptr(&mut self) -> *mut u8;
```
Parent issue: #89692
r? ````@joshtriplett````
|
|
|
|
|
|
|
|
r=joshtriplett
Add #[must_use] to from_value conversions
I added two methods to the list myself. Clippy did not flag them because they take `mut` args, but neither modifies their argument.
```rust
core::str const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str;
std::ffi::CString unsafe fn from_raw(ptr: *mut c_char) -> CString;
```
I put a custom note on `from_raw`:
```rust
#[must_use = "call `drop(from_raw(ptr))` if you intend to drop the `CString`"]
pub unsafe fn from_raw(ptr: *mut c_char) -> CString {
```
Parent issue: #89692
r? ``@joshtriplett``
|
|
Add #[must_use] to alloc constructors
Added `#[must_use]`. to the various forms of `new`, `pin`, and `with_capacity` in the `alloc` crate. No extra explanations given as I couldn't think of anything useful to add.
I figure this deserves extra scrutiny compared to the other PRs I've done so far. In particular:
* The 4 `pin`/`pin_in` methods I touched. Are there legitimate use cases for pinning and not using the result? Pinning's a difficult concept I'm not very comfortable with.
* `Box`'s constructors. Do people ever create boxes just for the side effects... allocating or zeroing out memory?
Parent issue: #89692
r? ``@joshtriplett``
|
|
r=joshtriplett
Add #[must_use] to conversions that move self
Everything here got the same message. Is the wording okay?
```rust
#[must_use = "`self` will be dropped if the result is not used"]
```
I want to draw attention to these methods in particular:
```rust
alloc::sync::Arc<MaybeUninit<T>> unsafe fn assume_init(self) -> Arc<T>;
alloc::sync::Arc<[MaybeUninit<T>]> unsafe fn assume_init(self) -> Arc<[T]>;
core::pin::Pin<&'a mut T> const fn into_ref(self) -> Pin<&'a T>;
core::pin::Pin<&'a mut T> const fn get_mut(self) -> &'a mut T;
core::pin::Pin<&'a mut T> const unsafe fn get_unchecked_mut(self) -> &'a mut T;
core::pin::Pin<&'a mut T> unsafe fn map_unchecked_mut(self, func: F) -> Pin<&'a mut U>;
core::pin::Pin<&'a mut Pin<P>> fn as_deref_mut(self) -> Pin<&'a mut P::Target>;
```
Parent issue: #89692
r? `@joshtriplett`
|
|
|
|
|
|
While it's an internal function, it is easy to create invalid Arc/Rcs to
a dangling pointer with it.
Fixes https://github.com/rust-lang/rust/issues/89740
|
|
Add #[must_use] to is_condition tests
There's nothing insightful to say about these so I didn't write any extra explanations.
Parent issue: #89692
|
|
Cfg hide no_global_oom_handling and no_fp_fmt_parse
These are unstable sysroot customisation cfg options that only projects building their own sysroot will use (e.g. Rust-for-linux). Most users shouldn't care. `no_global_oom_handling` can be especially annoying since it's applied on many commonly used alloc crate methods (e.g. `Box::new`, `Vec::push`).
r? ```@GuillaumeGomez```
|
|
|
|
There's nothing insightful to say about these so I didn't write any
extra explanations.
|
|
|
|
Add documentation to boxed conversions
Among other changes, documents whether allocations are necessary
to complete the type conversion.
Part of #51430, supersedes #89199
|
|
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
|
|
These methods could be misconstrued as modifying their arguments instead
of returning new values.
Where possible I made the note recommend a method that does mutate in
place.
|
|
|
|
Among other changes, documents whether allocations are necessary
to complete the type conversion.
Part of #51430
Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
Co-authored-by: Joshua Nelson <github@jyn.dev>
|
|
Make cfg imply doc(cfg)
This is a reopening of #79341, rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well):
* `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand, so we need this information in later parts of rustdoc.
* I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation.
* I updated the version for the feature.
There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624)
> I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different.
How/why should they differ?
EDIT: this part has been solved, the current code was fine, just needed a little simplification.
cc `@Nemo157`
r? `@jyn514`
Original PR description:
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via `#[doc(cfg(...))]`, so e.g. to hide a `#[cfg]` you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.
|
|
`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.
|
|
r=joshtriplett
refactor: make VecDeque's IterMut fields module-private, not just crate-private
Made the fields of VecDeque's IterMut private by creating a IterMut::new(...) function to create a new instance of IterMut and migrating usage to use IterMut::new(...).
|
|
* Remove "bool_to_options" feature
* Update version for compiler feature
* rustfmt
|
|
Made the fields of VecDeque's IterMut private by creating a IterMut::new(...) function to create a new instance of IterMut and migrating usage to use IterMut::new(...).
|
|
|
|
|
|
r=joshtriplett
refactor: VecDeques PairSlices fields to private
Reducing VecDeque's PairSlices fields to private, a `from(...)` method is already used to create PairSlices.
|
|
Correctly handle supertraits for min_specialization
Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.
r? ````@nikomatsakis````
|
|
Stabilize try_reserve
Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).
|
|
Include the length in BTree hashes
This change makes it consistent with `Hash` for all other collections.
|
|
VecDeque: improve performance for From<[T; N]>
Create `VecDeque` directly from the array instead of inserting items one-by-one.
Benchmark
```
./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000
```
* Before
```
test vec_deque::bench_from_array_1000 ... bench: 3,991 ns/iter (+/- 717)
```
* After
```
test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37)
```
|
|
implement advance_(back_)_by on more iterators
Add more efficient, non-default implementations for `feature(iter_advance_by)` (#77404) on more iterators and adapters.
This PR only contains implementations where skipping over items doesn't elide any observable side-effects such as user-provided closures or `clone()` functions. I'll put those in a separate PR.
|
|
|
|
Add truncate note to Vec::resize
A very minor addition to the `Vec::resize` documentation to point out the `truncate` method.
When I was searching for something matching `truncate` I managed to miss it, along with some colleagues. We later found it by chance. We did find `resize` however, so I was hoping to point it out in the documentation.
|
|
Add missing `# Panics` section to `Vec` method
namely `Vec::extend_from_within`
|
|
BTree: refine some comments
|
|
|
|
BTree: toughen panicky test of clone()
Test did not cover the second half of `clone_subtree` and why this clones key & value first.
|
|
Optimize unnecessary check in Vec::retain
The function `vec::Vec::retain` only have two stages:
1. Nothing was deleted.
2. Some elements were deleted.
Here is an unnecessary check `if g.deleted_cnt > 0` in the loop, and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics.
I write a special but common bench case for this optimization. I call retain on vec but keep all elements.
Before and after this optimization:
```
test vec::bench_retain_whole_100000 ... bench: 84,803 ns/iter (+/- 17,314)
```
```
test vec::bench_retain_whole_100000 ... bench: 42,638 ns/iter (+/- 16,910)
```
The result is expected, there are two `if`s before the optimization and one `if` after.
|
|
|
