Autoharness: support pattern types (RigidTy::Pat)

[Tianshu-Huang]

Problem

Since nightly-2026-04-01, NonNull<T> wraps a pattern_type!(*const T is !null) instead of a bare *const T. Since nightly-2026-06-01 (#4760), rustc_layout_scalar_valid_range_start/end attributes were replaced by pattern types more broadly. Autoharness does not recognize RigidTy::Pat — any function whose signature involves a pattern type (directly or through a struct field) is skipped with "Missing Arbitrary implementation".

Solution

can_derive_arbitrary (mod.rs) — recognize RigidTy::Pat in both the struct-field iteration loop and the top-level type match, delegating to a new helper pat_base_is_derivable. For raw-pointer bases (*const T), the pointee T must be derivable (because the raw-pointer codegen allocates storage for it); for any other base (integers, etc.) the base itself must be derivable.

call_kani_any_for_ty (automatic.rs) — generate a nondeterministic value of the base type, transmute it to the pattern type, then constrain it to the pattern's validity range via the existing assume_scalar_niche.

Tests

Updated autoharness_niche: Month, Schedule, PosI8, and check_monthly::<Month> move from skipped to verified (10/10 functions pass), satisfying the acceptance criteria in #4758.

New autoharness_pattern_type: covers NonNull<u8> as a direct argument, NonNull<u32> inside a struct field, and a cover check verifying the generated value is non-null.

Resolves #4758

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[Tianshu-Huang]

@CYJ904 @wodex1nhaoIeng @srivatsansamraj @acearyanarun

[CYJ904]

Verified locally — after rebuilding kani-compiler on this branch, both test cases reproduce the PR description:

autoharness_niche: 10/10 functions verified (up from 2/10 pre-change)
autoharness_pattern_type: 3/3 verified, including the non-null cover check

One question on call_kani_any_for_ty: the base value is generated and transmuted into the pattern type before assume_scalar_niche runs, so there's a brief window where the local holds an out-of-niche value (e.g. a null pointer typed as non-null). Does Kani's codegen insert any validity check on the Transmute cast itself that could fire before the assume takes effect? Tests pass here, so this is likely fine by design, just want to confirm it's intentional rather than incidental to these specific base types.

[acearyanarun]

I noticed a related pointer case: does assume_scalar_niche actually enforce the non-null constraint for NonNull pointer patterns? The current cover shows that a non-null value is reachable, but it doesn’t prove that null values can never be generated. Could we add an assertion that the generated pointer is always non-null?

[Tianshu-Huang]

I noticed a related pointer case: does assume_scalar_niche actually enforce the non-null constraint for NonNull pointer patterns? The current cover shows that a non-null value is reachable, but it doesn’t prove that null values can never be generated. Could we add an assertion that the generated pointer is always non-null?

Nice catch! I looked into scalar_niche, and turns out it does not match pointers, so it returned None for pointer-based pattern types, and assume_scalar_niche never constrained the generated value. I'll make the change to scalar_niche to also handle Primitive::Pointer, and added a kani::assert alongside the existing kani::cover!