-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for const alloc::Layout
#67521
Comments
Tracking issue rust-lang#67521, Layout::new in rust-lang#66254
Shouldn't most methods of This would allow certain usages where a custom derive + const is used to calculate field offsets of So following additional methods should become const too in the future in my opinion:
The problems can be resolved as following
The main hindrance I see is that not using pub fn extend(&self, next: Self) -> Result<(Self, usize), LayoutErr> {
let new_align = max_align(self.align(), next.align());
let pad = self.padding_needed_for(next.align());
let offset = bail_on_overflow!{ self.size().checked_add(pad) };
let new_size = bail_on_overflow!{ offset.checked_add(next.size()) };
match Layout::from_size_align(new_size, new_align) {
Ok(layout) => Ok((layout, offset)),
other => other
}
} ///------------- temporary helpers to be used by `extend` and other `Layout` methods
macro_rules! bail_on_overflow!{
($expr:expr) => ({
match $expr {
None => return Err(LayoutErr { private: () }),
Some(x) => x
}
});
}
const fn max_align(align1: usize, align2: usize) -> usize {
if align1 < align2 { align2 }
else { align1 }
} Not super nice but it would do for now I think. Lastly let's try to reason why
And:
As the original source code already mentions So following should be fine: pub const fn pad_to_align(&self) -> Layout {
let pad = self.padding_needed_for(self.align());
// [...]
let new_size = self.size() + pad;
// Safe: [...]
unsafe { Layout::from_size_align_unchecked(new_size, align) }
} |
Open questions:
|
Stabilize alloc::Layout const functions Stabilizes rust-lang#67521. In particular the following stable methods are stabilized as `const fn`: * `size` * `align` * `from_size_align` Stabilizing `size` and `align` should not be controversial as they are simple (usize and NonZeroUsize) fields and I don't think there's any reason to make them not const compatible in the future. That being true, the other methods are trivially `const`. The only other issue being returning a `Result` from a `const fn` but this has been made more usable by recent stabilizations.
It looks like this only has |
Constify remaining `Layout` methods Makes the methods on `Layout` that aren't yet unstably const, under the same feature and issue, rust-lang#67521. Most of them required no changes, only non-trivial change is probably constifying `ValidAlignment` which may affect rust-lang#102072
Constify remaining `Layout` methods Makes the methods on `Layout` that aren't yet unstably const, under the same feature and issue, rust-lang#67521. Most of them required no changes, only non-trivial change is probably constifying `ValidAlignment` which may affect rust-lang#102072
Constify remaining `Layout` methods Makes the methods on `Layout` that aren't yet unstably const, under the same feature and issue, rust-lang#67521. Most of them required no changes, only non-trivial change is probably constifying `ValidAlignment` which may affect rust-lang#102072
Constify remaining `Layout` methods Makes the methods on `Layout` that aren't yet unstably const, under the same feature and issue, rust-lang#67521. Most of them required no changes, only non-trivial change is probably constifying `ValidAlignment` which may affect rust-lang#102072
The following stable functions are unstably const under this issues: fn for_value<T>(t: &T) -> Layout
fn align_to(&self, align: usize) -> Result<Layout, LayoutError>
fn pad_to_align(&self) -> Layout
fn extend(&self, next: Layout) -> Result<(Layout, usize), LayoutError>
fn array<T>(n: usize) -> Result<Layout, LayoutError> The following are unstable functions that are also unstably const: unsafe fn for_value_raw<T>(t: *const T) -> Layout
fn padding_needed_for(&self, align: usize) -> usize
fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutError>
fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutError>
fn extend_packed(&self, next: Layout) -> Result<Layout, LayoutError> I think the unstable functions should simply be const without a separate const unstable issue? |
Shouldn't Then it would be guaranteed that the |
Feature
const_alloc_layout
makes these methods onLayout
const:padding_needed_for
for_value
for_value_raw
pad_to_align
array
Making more methods of
alloc::Layout
const allows computing alignment/size information for arbitrary (sized) types at compile-time. Whilemem::size_of
andmem::align_of
are already const andLayout
is solely based on those, there is no guarantee that a const derived from these functions will be exactly the same as what is used in a call toalloc::alloc
. ConstifyingLayout
makes this possible.PR #67494, related to #67520
The text was updated successfully, but these errors were encountered: