| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
|
|
|
|
reorder attributes to make miri-test-libstd work again
Fixes fallout from https://github.com/rust-lang/rust/pull/110141
|
|
since DrainFilter no longer continues draining when it's dropped
the panic tracking is no longer needed.
|
|
Don't drain-on-drop in DrainFilter impls of various collections.
This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](https://github.com/rust-lang/rfcs/pull/3288).
closes #101122
[ACP](https://github.com/rust-lang/libs-team/issues/136)
affected tracking issues
* #43244
* #70530
* #59618
Related hashbrown update: https://github.com/rust-lang/hashbrown/pull/374
|
|
Stabilize String::leak
Stabilizes the following API:
```Rust
impl String {
pub fn leak(self) -> &'static mut str;
}
```
closes #102929
blocked by having an FCP for stabilization.
|
|
|
|
|
|
#[must_use]
|
|
|
|
Ignore `core`, `alloc` and `test` tests that require unwinding on `-C panic=abort`
Some of the tests for `core` and `alloc` require unwinding through their use of `catch_unwind`. These tests fail when testing using `-C panic=abort` (in my case through a target without unwinding support, and `-Z panic-abort-tests`), while they should be ignored as they don't indicate a failure.
This PR marks all of these tests with this attribute:
```rust
#[cfg_attr(not(panic = "unwind"), ignore = "test requires unwinding support")]
```
I'm not aware of a way to test this on rust-lang/rust's CI, as we don't test any target with `-C panic=abort`, but I tested this locally on a Ferrocene target and it does indeed make the test suite pass.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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!
|
