emilk opened a new pull request, #10759:
URL: https://github.com/apache/arrow-rs/pull/10759

   # Which issue does this PR close?
   
   - Part of https://github.com/apache/arrow-rs/issues/10553
   
   # Rationale for this change
   
   Part 2 of 4, splitting out the `clippy::missing_panics_doc` work.
   **Stacked on https://github.com/apache/arrow-rs/pull/10755** - the diff shown
   here includes that PR, so review only the commits after
   `fix: return errors instead of panicking in fallible functions`. The diff
   shrinks to this PR's own contents once #10755 merges.
   
   1. #10755 - return errors from fallible functions
   2. **this PR** - remove unreachable panics
   3. document the panics that genuinely remain
   4. `#[expect]` the unreachable ones, so the lint can be turned on
   
   Where a panic cannot happen, the cleanest fix is not to document it or 
suppress
   the lint, but to write the code so the panic is not there. That is what this 
PR
   does. No behavior changes.
   
   # What changes are included in this PR?
   
   * replace `unwrap`/`expect` calls that cannot fail with non-panicking
     equivalents, e.g. `NaiveDate::default()` for the Unix epoch, 
`NaiveTime::MIN`,
     `as_chunks::<4>()` and `split_first_chunk::<4>()` for fixed-width reads
   * `IpcWriteOptions::try_new` validates the alignment in one `match` instead 
of
     checking and then unwrapping the conversion
   * `MutableBuffer` and `Bytes` recover from a poisoned memory reservation lock
     rather than panicking. The lock guards a size counter, so there is no 
broken
     invariant to protect. Adds `pool::lock_reservation` so the recovery is 
written
     once instead of at each of the ten lock sites
   * drop branches that could never run: the `last()` fallbacks in
     `BooleanBufferBuilder::truncate`/`append_n` and in
     `RunEndBuffer::get_physical_indices`. Index the element directly and record
     why it is in range
   * `SqlInfoDataBuilder::build` iterates its `BTreeMap` directly, which is 
already
     in key order, instead of copying the entries into a `Vec` and sorting them
   
   # Are these changes tested?
   
   Covered by the existing tests. Every change here is a rewrite of code whose
   panic was unreachable, so there is no new behavior to test.
   
   # Are there any user-facing changes?
   
   No.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to