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

["Danilo Krummrich" <dakr@kernel.org>]

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.