| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Also applies to `Vec::into_raw_parts`.
The expectation is that you can round-trip these methods with
`from_raw`, but this is only true when using the global allocator. With
custom allocators you should instead be using
`into_raw_with_allocator` and `from_raw_in`.
The implementation of `Box::leak` is changed to use
`Box::into_raw_with_allocator` and explicitly leak the allocator (which
was already the existing behavior). This is because, for `leak` to be
safe, the allocator must not free its underlying backing store. The
`Allocator` trait only guarantees that allocated memory remains valid
until the allocator is dropped.
|
|
|
|
|
|
|
|
|
|
|
|
Master bootstrap update
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday
r? `@Mark-Simulacrum`
|
|
Reduce `Box::default` stack copies in debug mode
The `Box::new(T::default())` implementation of `Box::default` only
had two stack copies in debug mode, compared to the current version,
which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing
`T` directly to the `Box` pointer, the stack usage in debug mode remains
the same as the old version.
Another option would be to mark `Box::write` as `#[inline(always)]`,
and change it's implementation to to avoid calling `MaybeUninit::write`
(which creates a `MaybeUninit<T>` on the stack) and to use `ptr::write` instead.
Fixes: #136043
|
|
|
|
|
|
Prepare standard library for Rust 2024 migration
This includes a variety of commits preparing the standard library for migration to Rust 2024.
The actual migration is blocked on a few things, so I wanted to get this out of the way in a relatively digestable PR.
|
|
|
|
A small workaround for https://github.com/rust-lang/rust/issues/136899,
rustdoc's invalid_rust_codeblocks was not handling this well in 2024.
This may be needed when migrating to 2024 when building with stage0.
|
|
In the deferred initialization pattern, the docs were needlessly going
through as_mut_ptr().write() to initialize, which is unnecessary use of
a pointer, needs to be inside an unsafe block, and may weaken alias
analysis.
|
|
The `Box::new(T::default())` implementation of `Box::default` only
had two stack copies in debug mode, compared to the current version,
which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing
`T` directly to the `Box` pointer, the stack usage in debug mode remains
the same as the old version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use attributes for `dangling_pointers_from_temporaries` lint
Checking for dangling pointers by function name isn't ideal, and leaves out certain pointer-returning methods that don't follow the `as_ptr` naming convention. Using an attribute for this lint cleans things up and allows more thorough coverage of other methods, such as `UnsafeCell::get()`.
|
|
|
|
|
|
This commit is a response to feedback on the displayed type
signatures results, by making generics act stricter.
Generics are tightened by making order significant. This means
`Vec<Allocator>` now matches only with a true vector of allocators,
instead of matching the second type param. It also makes unboxing
within generics stricter, so `Result<A, B>` only matches if `B`
is in the error type and `A` is in the success type. The top level
of the function search is unaffected.
Find the discussion on:
* <https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.202024-07-08/near/449965149>
* <https://github.com/rust-lang/rust/pull/124544#issuecomment-2204272265>
* <https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/deciding.20on.20semantics.20of.20generics.20in.20rustdoc.20search/near/476841363>
|
|
+ some minor style changes
|
|
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.
This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver
These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.
Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.
It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874
r? @wesleywiser
|
|
The `Box<T: Default>` impl currently calls `T::default()` before allocating
the `Box`.
Most `Default` impls are trivial, which should in theory allow
LLVM to construct `T: Default` directly in the `Box` allocation when calling
`<Box<T>>::default()`.
However, the allocation may fail, which necessitates calling `T's` destructor if it has one.
If the destructor is non-trivial, then LLVM has a hard time proving that it's
sound to elide, which makes it construct `T` on the stack first, and then copy it into the allocation.
Create an uninit `Box` first, and then write `T::default` into it, so that LLVM now only needs to prove
that the `T::default` can't panic, which should be trivial for most `Default` impls.
|
|
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
|
|
r=MarkSimulacrum,workingjubilee
Add `NonNull` convenience methods to `Box` and `Vec`
Implements the ACP: https://github.com/rust-lang/libs-team/issues/418.
The docs for the added methods are mostly copied from the existing methods that use raw pointers instead of `NonNull`.
I'm new to this "contributing to rustc" thing, so I'm sorry if I did something wrong. In particular, I don't know what the process is for creating a new unstable feature. Please advise me if I should do something. Thank you.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A partial stabilization that only affects:
- AllocType<T>::new_uninit
- AllocType<T>::assume_init
- AllocType<[T]>::new_uninit_slice
- AllocType<[T]>::assume_init
where "AllocType" is Box, Rc, or Arc
|
|
r=dtolnay
library: Move unstable API of new_uninit to new features
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as it was decided to only stabilize `uninit*` and `assume_init`.
|
|
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as
it was decided to only stabilize `uninit*` and `assume_init`.
|
|
|
|
PinCoerceUnsized trait into core
cc ``@Darksonn`` ``@wedsonaf`` ``@ojeda``
This is a PR to introduce a `PinCoerceUnsized` trait in order to make trait impls generated by the proc-macro `#[derive(SmartPointer)]`, proposed by [RFC](https://github.com/rust-lang/rfcs/blob/e17e19ac7ad1c8ccad55d4babfaee1aa107d1da5/text/3621-derive-smart-pointer.md#pincoerceunsized-1), sound. There you may find explanation, justification and discussion about the alternatives.
Note that we do not seek stabilization of this `PinCoerceUnsized` trait in the near future. The stabilisation of this trait does not block the eventual stabilization process of the `#[derive(SmartPointer)]` macro. Ideally, use of `DerefPure` is more preferrable except this will actually constitute a breaking change. `PinCoerceUnsized` emerges as a solution to the said soundness hole while avoiding the breaking change. More details on the `DerefPure` option have been described in this [section](https://github.com/rust-lang/rfcs/blob/e17e19ac7ad1c8ccad55d4babfaee1aa107d1da5/text/3621-derive-smart-pointer.md#derefpure) of the RFC linked above.
Earlier discussion can be found in this [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Pin.20and.20soundness.20of.20unsizing.20coercions) and [rust-for-linux thread](https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/.23.5Bderive.28SmartPointer.29.5D.20and.20pin.20unsoundness.20rfc.233621).
try-job: dist-various-2
|
|
Add `#[must_use]` to some `into_raw*` functions.
cc #121287
r? ``@cuviper``
Adds `#[must_use = "losing the pointer will leak memory"]`[^1] to `Box::into_raw(_with_allocator)`, `Vec::into_raw_parts(_with_alloc)`, `String::into_raw_parts`[^2], and `rc::{Rc, Weak}::into_raw_with_allocator` (Rc's normal `into_raw` and all of `Arc`'s `into_raw*`s are already `must_use`).
Adds `#[must_use = "losing the raw <resource name may leak resources"]` to `IntoRawFd::into_raw_fd`, `IntoRawSocket::into_raw_socket`, and `IntoRawHandle::into_raw_handle`.
[^1]: "*will* leak memory" may be too-strong wording (since `Box`/`Vec`/`String`/`rc::Weak` might not have a backing allocation), but I left it as-is for simplicity and consistency.
[^2]: `String::into_raw_parts`'s `must_use` message is changed from the previous (possibly misleading) "`self` will be dropped if the result is not used".
|
|
|
