| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make Layout's align a NonZeroUsize
This PR makes the `Layout`'s align field a `NonZeroUsize` since it cannot ever be zero, not even while building a `Layout`. It also contains some drive-by minor cleanups over the docs and the code, like updating the documented error types, or using the `size()` and `align()` methods instead of accessing the fields directly (the latter was required for the `NonZeroUsize` change anyways).
r? @SimonSapin
cc @Amanieu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/48458
|
|
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.
|
|
`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.
|
|
This shows up in allocations of vectors and such, so no need for it to not be
inlined!
|
|
|
|
|
|
One was now unused, and `NonNull::new(…).ok_or(AllocErr)` feels short enough
for the few cases that need the other conversion.
|
|
Fixes #49608
|
|
… now that #[global_allocator] does not define a symbol for it
|
|
|
|
Changing the alignment with realloc is not supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
