| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 14 pull requests
Successful merges:
- #58730 (Have all methods of Filter and FilterMap use internal iteration)
- #58780 (ManuallyDrop != MaybeUninit)
- #58782 (Replace `s` with `self` in docs for str methods taking self.)
- #58785 (allow specifying attributes for tool lints)
- #58802 (Ensure `record_layout_for_printing()` is inlined.)
- #58821 (Fixed a syntax error in the pin docs)
- #58830 (tidy: deny(rust_2018_idioms))
- #58832 (Revert switching to GCP on AppVeyor)
- #58833 (tools/rustbook: deny(rust_2018_idioms))
- #58835 (tools/remote-test-{client,server}: deny(rust_2018_idioms))
- #58838 (Fix typo in Vec#resize_with documentation)
- #58842 (Forbid duplicating Cargo as a dependency)
- #58852 (Update toolchain to build NetBSD release)
- #58865 (Fix C-variadic function printing)
|
|
|
|
|
|
Stabilize TryFrom and TryInto with a convert::Infallible empty enum
This is the plan proposed in https://github.com/rust-lang/rust/issues/33417#issuecomment-423073898
|
|
Remove some unnecessary 'extern crate'
cc #58099
r? @Centril
|
|
replace deprecated rustfmt_skip with rustfmt::skip
|
|
Relax some Ord bounds on BinaryHeap<T>
Notably, iterators don't require any trait bounds to be iterated.
|
|
|
|
Clarify guarantees for `Box` allocation
This basically says `Box` does the obvious things for its allocations.
See also: https://users.rust-lang.org/t/alloc-crate-guarantees/24981
This may require a T-libs FCP? Not sure.
r? @sfackler
|
|
|
|
Optimise vec![false; N] to zero-alloc
Nowadays booleans have a well-defined representation, so there is no reason not to optimise their allocation.
|
|
introduce benchmarks of BTreeSet.intersection
16 tests combining 4 kinds of contents with different sizes exposing edge cases.
The ones with asymmetric sizes are addressed by https://github.com/rust-lang/rust/pull/58577.
The pos_vs_neg cases seems (are were meant to be) the same as the neg_vs_pos case (same thing, reverse order) but reality shows a surprsing 25% difference.
|
|
fix overlapping references in BTree
This fixes two kinds of overlapping references in BTree (both found by running the BTree test suite in Miri).
In `into_slices_mut`, we did `k.into_key_slice_mut()` followed by `self.into_val_slice_mut()` (where `k` is a copy of `self`). Calling `into_val_slice_mut` calls `self.len()`, which creates a shared reference to `NodeHeader`, which unfortunately (due to padding) overlaps with the mutable reference returned by `into_key_slice_mut`. Hence the key slice got (partially) invalidated. The fix is to avoid creating an `&NodeHeader` after the first slice got created.
In the iterators, we used to first create the references that will be returned, and then perform the walk on the tree. Walking the tree creates references (such as `&mut InternalNode`) that overlap with all of the keys and values stored in a pointer; in particular, they overlap with the references the iterator will later return. This is fixed by reordering the operations of walking the tree and obtaining the inner references.
The test suite still passes (and it passes in Miri now!), but there is a lot of code here that I do not understand...
|
|
override `VecDeque::try_rfold`, also update iterator
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. Cc @RalfJung
|
|
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
|
|
|
