fix!(rust): panic when using FastPFOR::new

[CommanderStorm]

Both page_size and block_size don't make sense to have as zero

[Copilot]

Pull request overview

This PR aims to prevent panics caused by constructing FastPFOR with a page_size or block_size of zero by making these values non-zero at the type level.

Changes:

• Introduces NonZeroU32 for FastPFOR::new parameters.
• Updates public constants (BLOCK_SIZE_128, BLOCK_SIZE_256, DEFAULT_PAGE_SIZE) to NonZeroU32.
• Adjusts one internal comparison to account for NonZeroU32 (.get()).

Comments suppressed due to low confidence (1)

src/rust/integer_compression/fastpfor.rs:152

• Changing FastPFOR::new to require NonZeroU32 is also a breaking API change for callers that currently pass u32 values/variables (including internal benches/tests). If the goal is to avoid division-by-zero panics, consider keeping the u32 signature and validating page_size/block_size inside the constructor (e.g., return a FastPForResult via a new try_new, or at least fail fast with a clear error/panic message). Also note that page_size/block_size fields are still pub u32, so invariants can still be violated after construction.

    pub fn new(page_size: NonZeroU32, block_size: NonZeroU32) -> FastPFOR {
        let page_size = page_size.get();
        let block_size = block_size.get();
        FastPFOR {
            page_size,
            block_size,
            bytes_container: bytebuffer::ByteBuffer::new(3 * page_size / block_size + page_size),

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!