| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Split non-CAS atomic support off into target_has_atomic_load_store
This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s:
* `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations).
* ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS).
cc #32976
r? @alexcrichton
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/61129
|
|
|
|
|
|
|
|
|
|
… and add a separately-unstable field to force non-exhaustive matching
(`#[non_exhaustive]` is no implemented yet on enum variants)
so that we have the option to later expose the allocator’s error value.
CC https://github.com/rust-lang/wg-allocators/issues/23
|
|
|
|
|
|
This mirrors the implementations of reference slices into arrays.
|
|
Turn `INCOMPLETE_FEATURES` into lint
We do this because it is annoying to see the warning when building rustc and because this is better from a "separation of concerns" POV.
The drawback to this change is that this will respect `--cap-lints`.
Also note that this is not a buffered lint so if there are fatal parser errors then the lint will not trigger.
r? @varkor
|
|
Add doc links to liballoc crate page
|
|
|
|
rustbuild
Remove some random unnecessary lint `allow`s
|
|
|
|
|
|
|
|
Add `impl<T> FromIterator<T> for Arc/Rc<[T]>`
Add implementations of `FromIterator<T> for Arc/Rc<[T]>` with symmetrical logic.
This also takes advantage of specialization in the case of iterators with known length (`TrustedLen`) to elide the final allocation/copying from a `Vec<T>` into `Rc<[T]>` because we can allocate the space for the `Rc<[T]>` directly when the size is known. This is the primary motivation and why this is to be preferred over `iter.collect::<Vec<_>>().into(): Rc<[T]>`.
Moreover, this PR does some refactoring in some places.
r? @RalfJung for the code
cc @alexcrichton from T-libs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`#[rustc_allocator]`
|
|
|
|
future
Also expand the documentation a bit
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize the `alloc` crate.
This implements RFC 2480:
* https://github.com/rust-lang/rfcs/pull/2480
* https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md
Closes https://github.com/rust-lang/rust/issues/27783
|
|
This implements RFC 2480:
* https://github.com/rust-lang/rfcs/pull/2480
* https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md
Closes https://github.com/rust-lang/rust/issues/27783
|
|
|
|
Implement specialized nth_back() for Box and Windows.
Hi there, this is my first pull request to rust :-)
I started implementing some specializations for DoubleEndedIterator::nth_back() and these are the first two. The problem has been discussed in #54054 and nth_back() is tracked in #56995.
I'm stuck with the next implementation so I though I do a PR for the ones I'm confident with to get some feedback.
|
|
|
|
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.
|
|
|
|
|
|
|
|
As FCP’ed in the tracking issue: https://github.com/rust-lang/rust/issues/27791#issuecomment-376864727
|
|
|
|
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.
|
|
|
|
|
|
|
|
Tracking issue FCP to merge: https://github.com/rust-lang/rust/issues/48656#issuecomment-442372750
|