Re: [PATCH v5 21/38] rust: ptr: add const_align_up() and enable inline_const feature

From: Danilo Krummrich

Date: Mon Feb 23 2026 - 09:23:27 EST


On Mon Feb 23, 2026 at 3:16 PM CET, Gary Guo wrote:
> On 2026-02-23 11:07, Danilo Krummrich wrote:
>> On Sun Feb 22, 2026 at 8:04 PM CET, John Hubbard wrote:
>>> On 2/21/26 11:46 PM, Gary Guo wrote:
>>>> On 2026-02-21 02:09, John Hubbard wrote:
>>>>> Add const_align_up<ALIGN>() to kernel::ptr as the const-compatible
>>>>> equivalent of Alignable::align_up(). This uses inline_const to validate
>>>>> the alignment at compile time with a clear error message.
>>>>>
>>> ...
>>>
>>>>> +#[inline(always)]
>>>>> +pub const fn const_align_up<const ALIGN: usize>(value: usize) -> usize {
>>>>> + const { assert!(ALIGN.is_power_of_two(), "ALIGN must be a power of two") };
>>>>> + match value.checked_add(ALIGN - 1) {
>>>>> + Some(v) => v & !(ALIGN - 1),
>>>>> + None => panic!("const_align_up: overflow"),
>>>>
>>>> This is wrong. Either this function is always used in const context, in which case
>>>> you take `ALIGN` as normal function parameter and use `build_assert` and `build_error`,
>>>> or this function can be called from runtime and you shouldn't have a panic call here.
>>
>> I think the most common case is that ALIGN is const, but value is not.
>>
>> What about keeping the function as is (with the panic() replaced with a Result)
>> and also add
>>
>> #[inline(always)]
>> pub const fn const_expect<T: Copy>(opt: Result<T>, &'static str) -> T {
>> match opt {
>> Ok(v) => v,
>> Err(_) => panic!(""),
>> }
>> }
>>
>
> We already have `Alignable::align_up` for non-const cases, so this would only be used
> in const context and I don't see the need of having explicit const_expect?

Fair enough -- unfortunate we can't call this from const context.