| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Stabilize vec_spare_capacity
Closes #75017
|
|
Closes #75017
|
|
Docs: recommend VecDeque instead of Vec::remove(0)
Suggestion based on a [discussion](https://internals.rust-lang.org/t/should-vec-have-a-try-remove-mut-self-usize-option-t-function/15964/9?u=kornel) where user needlessly struggled with `remove(0)` and accidentally created a quadratic cost.
|
|
|
|
Clarify explicitly that BTree{Map,Set} are ordered.
One of the main reasons one would want to use a BTree{Map,Set} rather than a Hash{Map,Set} is because they maintain their keys in sorted order; but this was never explicitly stated in the top-level docs (it was only indirectly alluded to there, and stated explicitly in the docs for `iter`, `values`, etc.)
This PR states the ordering guarantee more prominently.
|
|
Add diagnostic items for macros
For use in Clippy, it adds diagnostic items to all the stable public macros
Clippy has lints that look for almost all of these (currently by name or path), but there are a few that aren't currently part of any lint, I could remove those if it's preferred to add them as needed rather than ahead of time
|
|
Yield means something else in the context of generators, which are
sufficiently close to iterators that it's better to avoid the
terminology collision here.
|
|
Add Sync bound to allocator parameter in vec::IntoIter
The `A: Sync` bound was forgotten in https://github.com/rust-lang/rust/commit/8725e4c33749b23f260b2fc46e090c3792b6f97e#diff-b78c3ab6d37f4ede32195707528f8a76c49d4557cc9d3a7a09417b5157729b9fR3132
Similar `unsafe impl Sync` in that commit _do_ include the `A: Sync` bound (and around the alloc lib), so I think this was just an honest mistake.
Here's an example of the unsoundness: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=16cbfeff7c934ae72ab632c1476fdd8b
`@steffahn` found this, I'm just putting up the fix cause nobody else did :^)
Fixes #92633
|
|
Partially stabilize `maybe_uninit_extra`
This covers:
```rust
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
```
It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).
FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
|
|
This covers:
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
It does not cover the const-ness of `write` under
`const_maybe_uninit_write` nor the const-ness of
`assume_init_read` (this commit adds
`const_maybe_uninit_assume_init_read` for that).
FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
r=Mark-Simulacrum
Replace usages of vec![].into_iter with [].into_iter
`[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same)
So we should change all the implementation, documentation and tests to use it.
I skipped:
* `src/tools` - Those are copied in from upstream
* `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it.
* any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter<T>`
* any case where it looked like we were intentionally using `vec![].into_iter` to test it.
|
|
|
|
Mak DefId to AccessLevel map in resolve for export
hir_id to accesslevel in resolve and applied in privacy
using local def id
removing tracing probes
making function not recursive and adding comments
Move most of Exported/Public res to rustc_resolve
moving public/export res to resolve
fix missing stability attributes in core, std and alloc
move code to access_levels.rs
return for some kinds instead of going through them
Export correctness, macro changes, comments
add comment for import binding
add comment for import binding
renmae to access level visitor, remove comments, move fn as closure, remove new_key
fmt
fix rebase
fix rebase
fmt
fmt
fix: move macro def to rustc_resolve
fix: reachable AccessLevel for enum variants
fmt
fix: missing stability attributes for other architectures
allow unreachable pub in rustfmt
fix: missing impl access level + renaming export to reexport
Missing impl access level was found thanks to a test in clippy
|
|
|
|
Switch all libraries to the 2021 edition
The fix for https://github.com/rust-lang/rust/issues/88638#issuecomment-996620107 is to simply add const-stability for these functions.
r? `@m-ou-se`
Closes #88638.
|
|
|
|
|
|
Fix a minor mistake in `String::try_reserve_exact` examples
The examples of `String::try_reserve_exact` didn't actually use `try_reserve_exact`, which was probably a minor mistake, and this PR fixed it.
|
|
Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison
I tried to run https://github.com/rust-lang/miri-test-libstd on `alloc` with `-Zmiri-track-raw-pointers`, and got a failure on the test `slice::panic_safe`. The test failure has nothing to do with panic safety, it's from how the test tests for panic safety.
I minimized the test failure into this very silly program:
```rust
use std::cell::Cell;
use std::cmp::Ordering;
#[derive(Clone)]
struct Evil(Cell<usize>);
fn main() {
let mut input = vec![Evil(Cell::new(0)); 3];
// Hits the bug pattern via CopyOnDrop in core
input.sort_unstable_by(|a, _b| {
a.0.set(0);
Ordering::Less
});
// Hits the bug pattern via InsertionHole in alloc
input.sort_by(|_a, b| {
b.0.set(0);
Ordering::Less
});
}
```
To fix this, I'm just removing the mutability/uniqueness where it wasn't required.
|
|
|
|
|
|
Constify `Box<T, A>` methods
Tracking issue: none yet
Most of the methods bounded on `~const`. `intrinsics::const_eval_select` is used for handling an allocation error.
<details><summary>Constified API</summary>
```rust
impl<T, A: Allocator> Box<T, A> {
pub const fn new_in(x: T, alloc: A) -> Self
where
A: ~const Allocator + ~const Drop;
pub const fn try_new_in(x: T, alloc: A) -> Result<Self, AllocError>
where
T: ~const Drop,
A: ~const Allocator + ~const Drop;
pub const fn new_uninit_in(alloc: A) -> Box<mem::MaybeUninit<T>, A>
where
A: ~const Allocator + ~const Drop;
pub const fn try_new_uninit_in(alloc: A) -> Result<Box<mem::MaybeUninit<T>, A>, AllocError>
where
A: ~const Allocator + ~const Drop;
pub const fn new_zeroed_in(alloc: A) -> Box<mem::MaybeUninit<T>, A>
where
A: ~const Allocator + ~const Drop;
pub const fn try_new_zeroed_in(alloc: A) -> Result<Box<mem::MaybeUninit<T>, A>, AllocError>
where
A: ~const Allocator + ~const Drop;
pub const fn pin_in(x: T, alloc: A) -> Pin<Self>
where
A: 'static,
A: 'static + ~const Allocator + ~const Drop,
pub const fn into_boxed_slice(boxed: Self) -> Box<[T], A>;
pub const fn into_inner(boxed: Self) -> T
where
Self: ~const Drop,
}
impl<T, A: Allocator> Box<MaybeUninit<T>, A> {
pub const unsafe fn assume_init(self) -> Box<T, A>;
pub const fn write(mut boxed: Self, value: T) -> Box<T, A>;
pub const unsafe fn from_raw_in(raw: *mut T, alloc: A) -> Self;
pub const fn into_raw_with_allocator(b: Self) -> (*mut T, A);
pub const fn into_unique(b: Self) -> (Unique<T>, A);
pub const fn allocator(b: &Self) -> &A;
pub const fn leak<'a>(b: Self) -> &'a mut T
where
A: 'a;
pub const fn into_pin(boxed: Self) -> Pin<Self>
where
A: 'static;
}
unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> const Drop for Box<T, A>;
impl<T: ?Sized, A: Allocator> const From<Box<T, A>> for Pin<Box<T, A>>
where
A: 'static;
impl<T: ?Sized, A: Allocator> const Deref for Box<T, A>;
impl<T: ?Sized, A: Allocator> const DerefMut for Box<T, A>;
impl<T: ?Sized, A: Allocator> const Unpin for Box<T, A> where A: 'static;
```
</details>
<details><summary>Example</summary>
```rust
pub struct ConstAllocator;
unsafe impl const Allocator for ConstAllocator {
fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
unsafe {
let ptr = core::intrinsics::const_allocate(layout.size(), layout.align());
Ok(NonNull::new_unchecked(ptr as *mut [u8; 0] as *mut [u8]))
}
}
unsafe fn deallocate(&self, _ptr: NonNull<u8>, _layout: Layout) {
/* do nothing */
}
fn allocate_zeroed(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
self.allocate(layout)
}
unsafe fn grow(
&self,
_ptr: NonNull<u8>,
_old_layout: Layout,
_new_layout: Layout,
) -> Result<NonNull<[u8]>, AllocError> {
unimplemented!()
}
unsafe fn grow_zeroed(
&self,
_ptr: NonNull<u8>,
_old_layout: Layout,
_new_layout: Layout,
) -> Result<NonNull<[u8]>, AllocError> {
unimplemented!()
}
unsafe fn shrink(
&self,
_ptr: NonNull<u8>,
_old_layout: Layout,
_new_layout: Layout,
) -> Result<NonNull<[u8]>, AllocError> {
unimplemented!()
}
fn by_ref(&self) -> &Self
where
Self: Sized,
{
self
}
}
#[test]
fn const_box() {
const VALUE: u32 = {
let mut boxed = Box::new_in(1u32, ConstAllocator);
assert!(*boxed == 1);
*boxed = 42;
assert!(*boxed == 42);
*boxed
};
assert!(VALUE == 42);
}
```
</details>
|
|
|
|
|
|
Remove pronunciation guide from Vec<T>
I performed an extremely scientific poll on twitter, and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315
|
|
Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid
~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up)
I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`.
I minimized the test failure into this program:
```rust
#![feature(vec_split_at_spare)]
fn main() {
Vec::<i32>::with_capacity(1).split_at_spare_mut();
}
```
The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
|
|
|
|
|
|
|
|
|
|
|
|
In `Vec`, two doc tests are using `MaybeUninit::write` , stabilized in 1.55. This makes docs' usage of `maybe_uninit_extra` feature unnecessary.
|
|
r=joshtriplett
RawVec: don't recompute capacity after allocating.
Currently it sets the capacity to `ptr.len() / mem::size_of::<T>()`
after any buffer allocation/reallocation. This would be useful if
allocators ever returned a `NonNull<[u8]>` with a size larger than
requested. But this never happens, so it's not useful.
Removing this slightly reduces the size of generated LLVM IR, and
slightly speeds up the hot path of `RawVec` growth.
r? `@ghost`
|
|
|
|
|
|
Currently it sets the capacity to `ptr.len() / mem::size_of::<T>()`
after any buffer allocation/reallocation. This would be useful if
allocators ever returned a `NonNull<[u8]>` with a size larger than
requested. But this never happens, so it's not useful.
Removing this slightly reduces the size of generated LLVM IR, and
slightly speeds up the hot path of `RawVec` growth.
|
|
The previous implementation used slice::as_mut_ptr_range to derive the
pointer for the spare capacity slice. This is invalid, because that
pointer is derived from the initialized region, so it does not have
provenance over the uninitialized region.
|
|
|
|
Update example code for Vec::splice to change the length
The current example for `Vec::splice` illustrates the replacement of a section of length 2 with a new section of length 2. This isn't a particularly interesting case for splice, and makes it look a bit like a shorthand for the kind of manipulations that could be done with a mutable slice.
In order to provide a stronger example, this updates the example to use different lengths for the source and destination regions, and uses a slice from the middle of the vector to illustrate that this does not necessarily have to be at the beginning or the end.
Resolves #92067
|
|
The src pointers in CopyOnDrop and InsertionHole used to be *mut T, and
were derived via automatic conversion from &mut T. According to Stacked
Borrows 2.1, this means that those pointers become invalidated by
interior mutation in the comparison function.
But there's no need for mutability in this code path. Thus, we can
change the drop guards to use *const and derive those from &T.
|
|
|
|
Add missing `'s` to ` Let check it out.`
|
|
Optimize `vec::retain` performance
This simply moves the loops into the inner function which leads to better results.
```
old:
test vec::bench_retain_100000 ... bench: 203,828 ns/iter (+/- 2,101)
test vec::bench_retain_iter_100000 ... bench: 63,324 ns/iter (+/- 12,305)
test vec::bench_retain_whole_100000 ... bench: 42,989 ns/iter (+/- 291)
new:
test vec::bench_retain_100000 ... bench: 42,180 ns/iter (+/- 451)
test vec::bench_retain_iter_100000 ... bench: 65,167 ns/iter (+/- 11,971)
test vec::bench_retain_whole_100000 ... bench: 33,736 ns/iter (+/- 12,404)
```
Measured on x86_64-unknown-linux-gnu, Zen2
Fixes #91497
|
|
r=jackh726,pnkfelix
Stabilize `destructuring_assignment`
Closes #71126
- [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058)
- [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819)
`@rustbot` label +F-destructuring-assignment +T-lang
Also needs +relnotes but I don't have permission to add that tag.
|
|
|
|
|
|
add BinaryHeap::try_reserve and BinaryHeap::try_reserve_exact
`try_reserve` of many collections were stablized in https://github.com/rust-lang/rust/pull/87993 in 1.57.0. Add `try_reserve` for the rest collections such as `BinaryHeap` should be not controversial.
|
