mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

DIrect invocations of AllocRef::alloc cannot get optimized away

Browse Source
This commit is contained in:
oli 2020-12-26 17:16:50 +00:00
parent fba17e3f8d
commit efcd8a96c4
1 changed files with 0 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
library/core/src/alloc/mod.rs
View File

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