Skip to content

Autoharness: support pattern types (RigidTy::Pat) - #4780

Open
Tianshu-Huang wants to merge 6 commits into
model-checking:mainfrom
Tianshu-Huang:autoharness-pattern-type
Open

Tianshu-Huang wants to merge 6 commits into
model-checking:mainfrom
Tianshu-Huang:autoharness-pattern-type

Conversation

@Tianshu-Huang

@Tianshu-Huang Tianshu-Huang commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

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. Raw-pointer bases (NonNull's field) are not supported: the pointee storage would be a local of the synthesized any() and dangle on return. NonNull is a follow-up PR.

call_kani_any_for_ty (automatic.rs) — generate a value of the base type, constrain it via assume_scalar_niche, then transmute — assuming first keeps it valid under -Z valid-value-checks.

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: an integer pattern type as a struct field and as a top-level argument, run with -Z valid-value-checks.

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.

Teach autoharness to recognize and generate values for pattern types,
since nightly-2026-04-01. Without this, any function taking a NonNull
argument (or a struct containing one) is skipped with 'Missing Arbitrary'.

Resolves model-checking#4758
@Tianshu-Huang
Tianshu-Huang requested review from a team as code owners September 3, 2026 23:51
@Tianshu-Huang

Copy link
Copy Markdown
Contributor Author

@Tianshu-Huang
Tianshu-Huang marked this pull request as draft September 3, 2026 23:54
@github-actions github-actions Bot added Z-EndToEndBenchCI Tag a PR to run benchmark CI Z-CompilerBenchCI Tag a PR to run benchmark CI labels Sep 4, 2026
@CYJ904

CYJ904 commented Sep 8, 2026

Copy link
Copy Markdown

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

Copy link
Copy Markdown

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

Copy link
Copy Markdown
Contributor Author

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!

@Tianshu-Huang
Tianshu-Huang marked this pull request as ready for review September 9, 2026 17:12
@feliperodri
feliperodri requested a balanced review from Copilot September 16, 2026 04:09
@feliperodri feliperodri added the Z-Autoharness Issue related to autoharness subcommand label Sep 16, 2026
@feliperodri feliperodri added this to the Autoharness milestone Sep 16, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Pattern-kind inspection can panic, validity is assumed too late, and pointer backing storage may expire prematurely.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds autoharness generation for Rust pattern types, restoring support for ranged scalar fields and NonNull<T>.

Changes:

  • Recognizes derivable pattern-type bases.
  • Generates constrained pattern-type values.
  • Adds and updates autoharness regression tests.
File summaries
File Description
kani-compiler/src/kani_middle/mod.rs Adds pattern derivability and pointer niches.
kani-compiler/src/kani_middle/transform/automatic.rs Generates pattern-type values.
tests/script-based-pre/autoharness_niche/niche_probe.rs Updates pattern-type documentation.
tests/script-based-pre/autoharness_niche/expected Expects restored niche verification.
tests/script-based-pre/autoharness_pattern_type/config.yml Configures the new test.
tests/script-based-pre/autoharness_pattern_type/run.sh Runs the pattern-type test.
tests/script-based-pre/autoharness_pattern_type/pattern_type_probe.rs Exercises NonNull arguments and fields.
tests/script-based-pre/autoharness_pattern_type/expected Defines expected verification results.
Review details

Suppressed comments (2)

kani-compiler/src/kani_middle/mod.rs:1128

  • NonNull's NotNull pattern cannot be inspected through stable Ty::kind(): check_values.rs:919-924 explicitly documents that this conversion panics and uses rustc_internal::internal instead. In this loop, the first ty.kind() at line 1108 will therefore panic before this new arm can recognize the field, so the new NonNull tests cannot be processed reliably. Detect/extract pattern types through the internal rustc type (which will require threading TyCtxt into this eligibility logic).
                } else if let TyKind::RigidTy(RigidTy::Pat(base_ty, _)) = ty.kind() {
                    fields_impl_arbitrary &=
                        pat_base_is_derivable(base_ty, kani_any_def, ty_arbitrary_cache);

kani-compiler/src/kani_middle/transform/automatic.rs:1384

  • The transmute constructs a pattern-typed value before its validity constraint is assumed. With -Z valid-value-checks, ValidValuePass instruments exactly such transmutes (check_values.rs:632-646), so invalid base values fail before the later assumption; this also violates the immediate validity requirement demonstrated by tests/expected/valid-value-checks/custom_niche.rs:57-67. Constrain the base bits using the pattern layout before constructing the pattern value.
        // A pattern type (e.g. `pattern_type!(*const T is !null)`) is layout-compatible with its
        // base type. Generate an arbitrary value of the base type, transmute it to the pattern
        // type, then constrain it to the pattern's validity range via `assume_scalar_niche`.
  • Files reviewed: 8/8 changed files
  • Comments generated: 3
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread kani-compiler/src/kani_middle/mod.rs Outdated
Comment on lines +1088 to +1090
let ty_to_check = match base_ty.kind() {
TyKind::RigidTy(RigidTy::RawPtr(pointee_ty, _)) => pointee_ty,
_ => base_ty,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed: raw-pointer pattern bases are no longer derivable (same rule as reference fields), so NonNull is reported unsupported instead of dangling. I will address inline generation for NonNull in a follow-up PR to keep this PR's review scope small.

} else {
ptr_lcl
}
} else if let TyKind::RigidTy(RigidTy::Pat(base_ty, _)) = ty.kind() {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is stale on the current toolchain. rustc_public converts PatternKind::NotNull since nightly-2026-08-21, and the tests go through this path without panicking.

let bits = int.size().bits();
let bits = match value {
Primitive::Int(int, _) => int.size().bits(),
Primitive::Pointer(_) => tcx.data_layout.pointer_size().bits(),

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@feliperodri

Copy link
Copy Markdown
Member

@Tianshu-Huang could you address all copilot comments?

@Tianshu-Huang

Copy link
Copy Markdown
Contributor Author

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.

Thank you for raising this up! Confirmed with -Z valid-value-checks, it did fail. Fixed by assuming the niche on the base value before the transmute; the test now runs with that flag.

@Tianshu-Huang

Copy link
Copy Markdown
Contributor Author

@Tianshu-Huang could you address all copilot comments?

@feliperodri Thanks for the nudge. All three Copilot comments are now addressed. To keep this PR scoped to #4758 & keep the review simple, I'll split NonNull support into a follow-up PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Z-Autoharness Issue related to autoharness subcommand Z-CompilerBenchCI Tag a PR to run benchmark CI Z-EndToEndBenchCI Tag a PR to run benchmark CI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Autoharness: generate values for pattern-type fields, restoring layout-niche coverage for user-defined ranged types

5 participants