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 at 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.
On Tue Aug 5, 2025 at 3:13 PM CEST, Alexandre Courbot wrote:> 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: >>> + 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.No need to do that, the compiler already knows that there won't be underflow and optimizes it accordingly (since self.as_usize() converts a `NonZero<usize>`). [1] (it also works when removing the `is_power_of_two` check, but if we only stored a `usize`, I bet the compiler would also optimize this given that check) I'd just add a normal comment that mentions no underflow can occur. This shouldn't need unsafe. [1]: https://godbolt.org/z/M5x1W49nn --- Cheers, Benno