[PATCH v2 2/4] rust: add `Alignment` type
Alexandre Courbot
acourbot at nvidia.com
Tue Aug 5 13:13:27 UTC 2025
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 at 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.
More information about the Nouveau
mailing list