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