| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use an unbounded lifetime in `String::leak`.
Using `'a` instead of `'static` is predicted to make the process of making `String` generic over an allocator easier/less of a breaking change.
See:
- https://github.com/rust-lang/rust/pull/109814#issuecomment-1550164195
- https://github.com/rust-lang/rust/pull/109814#issuecomment-1550250163
ACP: https://github.com/rust-lang/libs-team/issues/109
|
|
Stabilize `BuildHasher::hash_one`
FCP completed in https://github.com/rust-lang/rust/issues/86161#issuecomment-1561125732
|
|
Support #[global_allocator] without the allocator shim
This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim.
Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist.
To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors.
(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
|
|
|
|
Mark internal functions and traits unsafe to reflect preconditions
No semantics are changed in this PR; I only mark some functions and and a trait `unsafe` which already had implicit preconditions. Although it seems somewhat redundant for `numfmt::Part::Copy` to contain a `&[u8]` instead of a `&str`, given that all of its current consumers ultimately expect valid UTF-8. Is the type also intended to work for byte-slice formatting in the future?
|
|
Fix duplicate `arcinner_layout_for_value_layout` calls when using the uninit `Arc` constructors
What this fixes is the duplicate calls to `arcinner_layout_for_value_layout` seen here: https://godbolt.org/z/jr5Gxozhj
The issue was discovered alongside #111603 but is otherwise unrelated to the duplicate `alloca`s, which remain unsolved. Everything I tried to solve said main issue has failed.
As for the duplicate layout calculations, I also tried slapping `#[inline]` and `#[inline(always)]` on everything in sight but the only thing that worked in the end is to dedup the calls by hand.
|
|
Specialize ToString implementation for fmt::Arguments
Generates far fewer instructions by formatting into a String with `fmt::format` directly instead of going through the `fmt::Display` impl. This change is insta-stable.
|
|
|
|
Change Vec examples to not assert exact capacity except where it is guaranteed
It was [brought up on discord](https://discord.com/channels/273534239310479360/818964227783262209/1107633959329878077) that the `Vec::into_boxed_slice` example contradicted the `Vec::with_capacity` docs in that the returned `Vec` might have _more_ capacity than requested.
So, to reduce confusion change all the `assert_eq!(vec.capacity(), _)` to `assert!(vec.capacity() >= _)`, except in 4 examples that have guaranteed capacities: `Vec::from_raw_parts`, `Vec::from_raw_parts_in`, `Vec::<()>::with_capacity`,`Vec::<(), _>::with_capacity_in`.
|
|
|
|
|
|
|
|
|
|
You will need to add the following as replacement for the old __rust_*
definitions when not using the alloc shim.
#[no_mangle]
static __rust_no_alloc_shim_is_unstable: u8 = 0;
|
|
Stabilize const_ptr_read
Stabilizes const_ptr_read, with tracking issue #80377
|
|
r=Mark-Simulacrum
enable `rust_2018_idioms` lint group for doctests
With this change, `rust_2018_idioms` lint group will be enabled for compiler/libstd doctests.
Resolves #106086
Resolves #99144
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
|
|
Our `Cursor::peek_prev` and `CursorMut::peek_prev` must agree
on how to behave when they are called on the "null element".
|
|
|
|
|
|
Loosen `From<&[T]> for Box<[T]>` bound to `T: Clone`
Also loosens `From<Cow<'_, [T]>> for Box<[T]>`'s bound.
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/From.3C.26.5BT.5D.3E.20impls.20consistency)
|
|
Co-authored-by: David Tolnay <dtolnay@gmail.com>
|
|
Make sure that some stdlib method signatures aren't accidental refinements
In the process of implementing https://rust-lang.github.io/rfcs/3245-refined-impls.html, I found a bunch of stdlib implementations that accidentally "refined" their method signatures by dropping (unnecessary) bounds.
This isn't currently a problem, but may become one if/when method signature refining is stabilized in the future. Shouldn't hurt to make these signatures a bit more accurate anyways.
NOTE (just to be clear lol): This does not affect behavior at all, since we don't actually take advantage of refined implementations yet!
|
|
|
|
|
|
|
|
Spelling library
Split per https://github.com/rust-lang/rust/pull/110392
I can squash once people are happy w/ the changes. It's really uncommon for large sets of changes to be perfectly acceptable w/o at least some changes.
I probably won't have time to respond until tomorrow or the next day
|
|
|
|
* advance
* aligned
* borrowed
* calculate
* debugable
* debuggable
* declarations
* desugaring
* documentation
* enclave
* ignorable
* initialized
* iterator
* kaboom
* monomorphization
* nonexistent
* optimizer
* panicking
* process
* reentrant
* rustonomicon
* the
* uninitialized
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
Updating Wake example to use new 'pin!' macro
Closes: https://github.com/rust-lang/rust/issues/109965
I have already had this reviewed and approved here: https://github.com/rust-lang/rust/pull/110026 . But because I had some git issues and chose the "nuke it" option as my solution it didn't get merged. I nuked it too quickly. I am sorry for trouble of reviewing twice.
|
|
|
|
Add support for allocators in `LinkedList`
Allows `LinkedList` to use a custom allocator
|
|
|
|
This reverts commit c9a6e41026d7aa27d897fb83e995447719753076.
|
|
This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
|
