Eliminate source of caller_location warnings in kani library #2032
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 of changes:
Currently, running Kani on any program involving
kani::any()
results in acaller_location
warning (see #2010). Turns out this intrinsic is brought in by the Kani library itself, more specifically due to the body of thekani::any_raw_inner
function:This macro ends up calling
panic!
, which callspanic_fmt
, which callsstd::panic::Location::caller
which in turn callsstd::intrinsics::caller_location
. Thus, this PR replaces this call by another construct (empty loop) that does not result in the same call stack.As a side effect, Kani compilation is sped up a bit. Even on this tiny program:
I was noticing a slight pause when running Kani, which this PR eliminates. More specifically, before this change:
and after this change:
Another nice side effect is that the generated MIR is significantly smaller. Before this change:
$ RUSTFLAGS="--emit mir" kani test.rs $ wc test.kani.mir 7010 49876 865082 test.kani.mir
and after this change:
$ RUSTFLAGS="--emit mir" kani test.rs $ wc test.kani.mir 163 1019 10329 test.kani.mir
Resolved issues:
Resolves #2010
Related RFC:
Optional #ISSUE-NUMBER.
Call-outs:
I could not find a way to test this. I tried creating a test with
#![deny(warnings)]
, but even without the change, it doesn't fail, apparently because it's a Kani warning and not a compiler warning.Testing:
How is this change tested? See callout
Is this a refactor change? No
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.