Challenge 25: Verify Vecdeque safety with Kani#605
Draft
v3risec wants to merge 4 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds Kani-based verification proofs for
VecDequefunctions inlibrary/alloc/src/collections/vec_deque/mod.rsfor Challenge 25: Verify the safety ofVecDequefunctions.The change introduces:
VecDequehelpers#[cfg(kani)]for all Challenge 25 listed entriesVecDequehelpers for initialized, bounded, unbounded, ZST, and reserve-sensitive statesVerification Coverage Report
Coverage: 43 / 43 Challenge 25 entries targeted
Unsafe helper coverage includes:
push_uncheckedbuffer_readbuffer_writebuffer_rangecopycopy_nonoverlappingwrap_copycopy_slicewrite_iterwrite_iter_wrappinghandle_capacity_increasefrom_contiguous_raw_parts_inabort_shrinkSafe abstraction coverage includes:
getget_mutswapreserve_exactreservetry_reserve_exacttry_reserveshrink_totruncateas_slicesas_mut_slicesrangerange_mutdrainpop_frontpop_backpush_frontpush_backinsertremovesplit_offappendretain_mutgrowresize_withmake_contiguousrotate_leftrotate_rightrotate_left_innerrotate_right_innerApproach
The verification strategy combines executable harnesses with targeted contracts, loop annotations, and path-specific symbolic states:
VecDequehelper functions that read, write, copy, or rearrange the ring buffer.#[kani::proof]and#[kani::proof_for_contract]harnesses for each Challenge 25 target, using concrete instantiations across integer types,usize/isize, unit/ZSTs, and arrays.VecDequebuilders where harnesses need to varyheadandlenindependently without pointing logical elements at uninitialized storage.handle_capacity_increaseis covered through its non-wrapped, wrapped-tail, and remaining wrapped cases;abort_shrinkis similarly covered through its different internal paths.Bounded and Unbounded Modeling Notes
The proofs do not rely on loop unwinding for the annotated loops; loop contracts
are used where needed.
The harnesses use both unbounded and bounded symbolic states:
Some harnesses leave logical lengths and capacities without small explicit bounds, so they exercise unbounded-style states subject only to validity, allocation-layout, and contract preconditions. In these cases, capacities can be very large, approaching the Rust allocation limits such as
isize::MAXbytes where the standard library permits it.Some harnesses intentionally bound allocation sizes because Kani/CBMC heap write-set reasoning has practical CAR limitations. In particular, heap write-set objects near the upper allocation range can exceed CBMC's capacity for precise write-set tracking; the practical threshold appears around the
2^51to2^47range depending on the proof shape and element type.A few harnesses use a small bound such as
MAX_VEC_DEQUE_LEN = 4. These are targeted proofs for branch-heavy operations where the goal is to cover ring-buffer layouts, wrapping/non-wrapping states, growth/shrink paths, and ZST behavior without making heap write-set reasoning dominate the proof.These bounds are verification engineering constraints rather than semantic preconditions on
VecDeque; the production implementation remains unchanged, and bounded helpers are kept undercfg(kani).Scope Assumptions
Tis represented through a broad set of concrete instantiations used by the harness macros.VecDeque::<()>::capacity()is logicallyusize::MAXand does not require backing storage.Verification
All added Challenge 25 harnesses pass locally with Kani.
Resolves #286
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.