summary refs log tree commit diff
path: root/src/libcore/alloc.rs
AgeCommit message (Collapse)AuthorLines
2018-04-22Remove Alloc::oomSteven Fackler-26/+0
2018-04-22Replace GlobalAlloc::oom with a lang itemSteven Fackler-11/+0
2018-04-20Implement Copy for std::alloc::LayoutSimon Sapin-1/+1
Fixes https://github.com/rust-lang/rust/issues/48458
2018-04-15Auto merge of #49884 - alexcrichton:less-unwrap, r=Mark-Simulacrumbors-8/+14
core: Remove panics from some `Layout` methods `Layout` is often used at the core of allocation APIs and is as a result pretty sensitive to codegen in various circumstances. I was profiling `-C opt-level=z` with a wasm project recently and noticed that the `unwrap()` wasn't removed inside of `Layout`, causing the program to be much larger than it otherwise would be. If inlining were more aggressive LLVM would have figured out that the panic could be eliminated, but in general the methods here can't panic in the first place! As a result this commit makes the following tweaks: * Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and `Layout::for_value`. For posterity though a debug assertion was left behind. * Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment indicating that the function call couldn't panic wasn't quite right in that if `alloc_size` becomes too large and if `align` is high enough it could indeed cause a panic. This'll hopefully mean that panics never get introduced into code in the first place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
2018-04-13core: Remove panics from some `Layout` methodsAlex Crichton-8/+14
`Layout` is often used at the core of allocation APIs and is as a result pretty sensitive to codegen in various circumstances. I was profiling `-C opt-level=z` with a wasm project recently and noticed that the `unwrap()` wasn't removed inside of `Layout`, causing the program to be much larger than it otherwise would be. If inlining were more aggressive LLVM would have figured out that the panic could be eliminated, but in general the methods here can't panic in the first place! As a result this commit makes the following tweaks: * Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and `Layout::for_value`. For posterity though a debug assertion was left behind. * Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment indicating that the function call couldn't panic wasn't quite right in that if `alloc_size` becomes too large and if `align` is high enough it could indeed cause a panic. This'll hopefully mean that panics never get introduced into code in the first place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
2018-04-13core: Inline `From<AllocErr> for CollectionAllocErr`Alex Crichton-0/+1
This shows up in allocations of vectors and such, so no need for it to not be inlined!
2018-04-12Initial docs for the GlobalAlloc traitSimon Sapin-5/+39
2018-04-12Rename alloc::Void to alloc::OpaqueSimon Sapin-19/+19
2018-04-12Remove conversions for allocated pointersSimon Sapin-17/+0
One was now unused, and `NonNull::new(…).ok_or(AllocErr)` feels short enough for the few cases that need the other conversion.
2018-04-12Use NonNull<Void> instead of *mut u8 in the Alloc traitMike Hommey-33/+25
Fixes #49608
2018-04-12Restore Global.oom() functionalitySimon Sapin-0/+4
… now that #[global_allocator] does not define a symbol for it
2018-04-12Conversions between Result<*mut u8, AllocErr>> and *mut VoidSimon Sapin-0/+21
2018-04-12realloc with a new size only, not a full new layout.Simon Sapin-51/+36
Changing the alignment with realloc is not supported.
2018-04-12Return Result instead of Option in alloc::Layout constructorsSimon Sapin-22/+41
2018-04-12Remove the now-unit-struct AllocErr field inside CollectionAllocErrSimon Sapin-3/+3
2018-04-12Remove the now-unit-struct AllocErr parameter of oom()Simon Sapin-1/+1
2018-04-12Implement GlobalAlloc for SystemSimon Sapin-0/+4
2018-04-12Make AllocErr a zero-size unit structSimon Sapin-50/+8
2018-04-12Rename `heap` modules in the core, alloc, and std crates to `alloc`Simon Sapin-0/+1125