| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Deprecate the unstable Vec::resize_default
As a way to either get additional feedback to stabilize or help move nightly users off it.
Tracking issue: https://github.com/rust-lang/rust/issues/41758#issuecomment-449719961
r? @SimonSapin
|
|
Nowadays booleans have a well-defined representation, so there is no reason not to optimise their allocation.
|
|
|
|
Use more impl header lifetime elision
Inspired by seeing explicit lifetimes on these two:
- https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html#impl-FusedIterator
- https://doc.rust-lang.org/nightly/std/primitive.u32.html#impl-Not
And a follow-up to https://github.com/rust-lang/rust/pull/54687, that started using IHLE in libcore.
Most of the changes in here fall into two big categories:
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop`, `Debug`, and `Clone`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations [where the flipped one cannot elide the lifetime](https://internals.rust-lang.org/t/impl-type-parameter-aliases/9403/2?u=scottmcm).
I also removed two lifetimes that turned out to be completely unused; see https://github.com/rust-lang/rust/issues/41960#issuecomment-464557423
|
|
This keeps the slice based iteration and updates the iterator
state after each slice. It also uses a loop to reduce the amount
of code.
This uses unsafe code, so some thorough review would be
appreciated.
|
|
There are two big categories of changes in here
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
|
|
|
|
split MaybeUninit into several features, expand docs a bit
This splits the `maybe_uninit` feature gate into several:
* `maybe_uninit` for what we will hopefully stabilize soon-ish.
* `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear.
* `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work.
* `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have https://github.com/rust-lang/rust/issues/49147 yet).
Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`.
I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
|
|
Update which libcore/liballoc tests Miri ignores, and document why
|
|
fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
|
|
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key
```rust
impl [T] {
pub fn sort_by_cached_key<K, F>(&mut self, f: F)
where F: FnMut(&T) -> K, K: Ord;
}
```
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
Closes #34447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notably, iterators don't require any trait bounds to be iterated.
|
|
|
|
|
|
documentation"
This reverts commit 9c7b69e17909ceb090a1c4b8882a4e0924a2a755.
|
|
|
|
Stabilize str::escape_* methods with new return types…
… that implement `Display` and `Iterator<Item=char>`, as proposed in FCP: https://github.com/rust-lang/rust/issues/27791#issuecomment-376864727
|
|
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
|
|
|
|
FCP: https://github.com/rust-lang/rust/issues/27791#issuecomment-376864727
|
|
As FCP’ed in the tracking issue: https://github.com/rust-lang/rust/issues/27791#issuecomment-376864727
|
|
|
|
|
|
|
|
libcore, liballoc: disable tests in Miri
I am going to run the libcore and liballoc unit test suites in Miri. Not all tests pass. This PR disables a whole bunch of tests when running in Miri, to get us to a baseline from which I can investigate failures.
Cc @SimonSapin @alexcrichton
|
|
|
|
|
|
Avoid some bounds checks in binary_heap::{PeekMut,Hole}
Fixes #58121.
|
|
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
|
|
Transition liballoc to Rust 2018
This transitions liballoc to Rust 2018 edition and applies relevant idiom lints.
I also did a small bit of drive-by cleanup along the way.
r? @oli-obk
I started with liballoc since it seemed easiest. In particular, adding `edition = "2018"` to libcore gave me way too many errors due to stdsimd. Ideally we should be able to continue this crate-by-crate until all crates use 2018.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
