mathieu/granite-rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

hedge for future changes

Browse source 
Co-authored-by: lcnr <rust@lcnr.de>
This commit is contained in:
Ralf Jung 2023-05-12 15:25:24 +02:00
parent 967ebb9c3d
commit b93fd8355a
2 changed files with 7 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
library/core/src/marker.rs
View file

@ -668,9 +668,11 @@ impl<T: ?Sized> !Sync for *mut T {}
///
/// ## Ownership and the drop check
///
/// Adding a field of type `PhantomData<T>` indicates that your type *owns* data of type `T`. This
/// in turn has effects on the Rust compiler's [drop check] analysis, but that only matters in very
/// specific circumstances. For the exact rules, see the [drop check] documentation.
/// The exact interaction of `PhantomData` with drop check **may change in the future**.
///
/// Currently, adding a field of type `PhantomData<T>` indicates that your type *owns* data of type
/// `T` in very rare circumstances. This in turn has effects on the Rust compiler's [drop check]
/// analysis. For the exact rules, see the [drop check] documentation.
///
/// ## Layout
///

3
library/core/src/ops/drop.rs
View file

@ -168,7 +168,8 @@
/// The Nomicon discusses the need for [drop check in more detail][drop check].
///
/// To reject such code, the "drop check" analysis determines which types and lifetimes need to
/// still be live when `T` gets dropped:
/// still be live when `T` gets dropped. The exact details of this analysis are not yet
/// stably guaranteed and **subject to change**. Currently, the analysis works as follows:
/// - If `T` has no drop glue, then trivially nothing is required to be live. This is the case if
/// neither `T` nor any of its (recursive) fields have a destructor (`impl Drop`). [`PhantomData`]
/// and [`ManuallyDrop`] are considered to never have a destructor, no matter their field type.