hedge for future changes

Co-authored-by: lcnr <[email protected]>

Author: RalfJung

library/core/src/marker.rs

@@ -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
 ///

library/core/src/ops/drop.rs

@@ -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.