DIrect invocations of `AllocRef::alloc` cannot get optimized away

1 files changed, 0 insertions, 21 deletions

diff --git a/library/core/src/alloc/mod.rs b/library/core/src/alloc/mod.rs
index 9c6e5738183..c61c19cc7d1 100644
--- a/library/core/src/alloc/mod.rs
+++ b/library/core/src/alloc/mod.rs
@@ -94,27 +94,6 @@ pub unsafe trait AllocRef {
     /// The returned block may have a larger size than specified by `layout.size()`, and may or may
     /// not have its contents initialized.
     ///
-    /// Note that you may not rely on this method actually getting called, even if there are calls
-    /// to it in the source. The optimizer may detect unused allocations that it can either
-    /// eliminate entirely or move to the stack and thus never invoke the allocator. The
-    /// optimizer may further assume that allocation is infallible, so code that used to fail due
-    /// to allocator failures may now suddenly work because the optimizer worked around the
-    /// need for an allocation. More concretely, the following code example is unsound, irrespective
-    /// of whether your custom allocator allows counting how many allocations have happened.
-    ///
-    /// ```rust,ignore (unsound and has placeholders)
-    /// Global::dealloc(Global::alloc(some_layout));
-    /// let number_of_heap_allocs = /* call private allocator API */;
-    /// unsafe { std::intrinsics::assume(number_of_heap_allocs > 0); }
-    /// ```
-    ///
-    /// Note that the optimizations mentioned above are not the only
-    /// optimization that can be applied. You may generally not rely on heap allocations
-    /// happening if they can be removed without changing program behavior.
-    /// Whether allocations happen or not is not part of the program behavior, even if it
-    /// could be detected via an allocator that tracks allocations by printing or otherwise
-    /// having side effects.
-    ///
     /// # Errors
     ///
     /// Returning `Err` indicates that either memory is exhausted or `layout` does not meet