Force-load the kani crate so no_std crates work out of the box - #4682
Open
tautschnig wants to merge 1 commit into
Open
Force-load the kani crate so no_std crates work out of the box#4682tautschnig wants to merge 1 commit into
tautschnig wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the Kani driver to force-load the kani crate via --extern force:kani, ensuring #[no_std] crates don’t fail verification due to missing Kani functions when the user code never explicitly references/imports kani.
Changes:
- Pass
--extern force:kaniwhen compiling single files so thekanicrate is loaded even if unused by the target crate. - Update the
cargo-uino-std-no-kanitest to verify a#[no_std]harness can callkani::any()withoutextern crate kani. - Adjust the expected output for that test from an error to successful verification.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/cargo-ui/no-std-no-kani/src/lib.rs | Updates the test crate to include a #[cfg(kani)] proof harness using kani::any() without importing kani. |
| tests/cargo-ui/no-std-no-kani/expected | Changes the UI expectation from the “Failed to detect Kani functions” error to a successful verification result. |
| kani-driver/src/call_single_file.rs | Switches the injected --extern kani to --extern force:kani so kani is loaded even when unused, fixing no_std out-of-the-box verification. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+26
to
+30
| // Use the `force` modifier so that the `kani` crate is resolved even if the code | ||
| // under verification never references it. `#[no_std]` crates do not link Kani's | ||
| // `std` (which would otherwise pull in `kani`), so without `force` the Kani | ||
| // library and its functions would be missing entirely, c.f. | ||
| // https://github.com/model-checking/kani/issues/3906. |
Kani passed '--extern kani', which makes the kani crate resolvable but does not load it unless the code under verification references it. Crates using #[no_std] never link Kani's std (which is what otherwise pulls in kani), so verifying them failed with 'Failed to detect Kani functions' unless the user manually added 'extern crate kani' to their crate root. Use the (unstable) 'force' extern modifier -- alongside the already-used 'noprelude' modifier -- so the kani crate is always loaded. A no_std crate with proof harnesses and no kani import now verifies out of the box, and 'kani autoharness' works on unmodified no_std crates (about a third of the top-100 crates.io crates). The no-std-no-kani test now expects success rather than the old error message. Note that a pre-existing interaction remains for crates that deny(unused_crate_dependencies): Kani's injected 'noprelude:std' extern trips that lint with or without this change. This addresses the root cause behind the confusing error message reported in model-checking#3906. Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
tautschnig
force-pushed
the
fix-nostd-extern-kani
branch
from
July 29, 2026 00:42
0a6387f to
17ec0fc
Compare
feliperodri
approved these changes
Jul 29, 2026
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.
Description
Kani passes
--extern kani, which makes thekanicrate resolvable but does not load it unless the code under verification references it.#[no_std]crates never link Kani'sstd(which is what otherwise pullskaniin transitively), so verifying them fails with "Failed to detect Kani functions" unless the user manually addsextern crate kanito their crate root — the workaround suggested by the error message introduced for #3906.This PR uses the
forceextern modifier (unstable, like thenopreludemodifier Kani already relies on) so thekanicrate is always loaded. With this:no_stdcrate with#[cfg(kani)] #[kani::proof]harnesses and no kani import verifies out of the box (kani::paths resolve via the forced extern), andkani autoharnessworks on unmodifiedno_stdcrates.Context: while evaluating autoharness on the top-100 crates.io crates, roughly a third of the corpus is
no_stdand hit this error; each needed a source modification to proceed.One pre-existing interaction is unchanged: crates that
deny(unused_crate_dependencies)already fail on Kani's injectednoprelude:stdextern, with or without this change (verified against main). Fixing that lint interaction is a separate work item.Testing
Updated
tests/cargo-ui/no-std-no-kanifrom expecting the error message to expecting successful verification of ano_stdharness that useskani::any()without anyextern crate kani. Fullcargo-uisuite passes (29 tests).Manually verified:
cargo kani autoharnesson the unmodifiedcfg-ifcrate (previously failed) now runs;deny(unused_crate_dependencies)behavior is unchanged vs. main.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.