Re: [PATCH v2 2/4] rust: add `Alignment` type

["Alexandre Courbot" <acourbot@nvidia.com>]

On Mon Aug 4, 2025 at 11:17 PM JST, Miguel Ojeda wrote:
> On Mon, Aug 4, 2025 at 1:45 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> +/// align down/up operations. The alignment operations are done using the [`align_up!`] and
>> +/// [`align_down!`] macros.
>
> These intra-doc links don't work (they are not macros in this version at least).

Oops, these are remnants of some previous attempt at making this work,
which I could swear I removed. That and the sentence's grammar as a
whole is incorrect. Let me rework this.

>
>> +    /// Returns the alignment of `T`.
>> +    #[inline(always)]
>> +    pub const fn of<T>() -> Self {
>> +        // INVARIANT: `align_of` always returns a power of 2.
>> +        Self(unsafe { NonZero::new_unchecked(align_of::<T>()) })
>
> Missing safety comment (`CLIPPY=1` spots it).
>
> Also, cannot we use `new()` here? i.e. the value will be known at compile-time.

We can indeed! Brilliant.

>
>> +        if !self.0.is_power_of_two() {
>> +            // SAFETY: per the invariants, `self.0` is always a power of two so this block will
>> +            // never be reached.
>> +            unsafe { core::hint::unreachable_unchecked() }
>> +        }
>
> I guess this one is here to help optimize users after they inline the
> cal? Is there a particular case you noticed? i.e. it may be worth
> mentioning it.

This was a suggestion from Benno [1], to give more hints to the
compiler. Let me add a comment to justify its presence.

[1] https://lore.kernel.org/rust-for-linux/DBL1ZGZCSJF3.29HNS9BSN89C6@kernel.org/

>
>> +    pub const fn mask(self) -> usize {
>> +        // INVARIANT: `self.as_usize()` is guaranteed to be a power of two (i.e. non-zero), thus
>> +        // `1` can safely be substracted from it.
>> +        self.as_usize() - 1
>> +    }
>
> I am not sure why there is `// INVARIANT` here, since we are not
> creating a new `Self`.

>
> I guess by "safely" you are trying to say there is no overflow risk --
> I would be explicit and avoid "safe", since it is safe to overflow.

I just wanted to justify that we cannot substract from 0. Maybe an
`unchecked_sub` would be better here? The `unsafe` block would also
justify the safety comment.

... mmm actually that would be `checked_sub().unwrap_unchecked()`, since
`unchecked_sub` appeared in Rust 1.79.