Enable build cache in cargo kani#2232
Conversation
Note: Need to fix model-checking#1478 before pushing this
Conflicts: kani-driver/src/call_cargo.rs Required adjustments: tests/script-based-pre/check_rebuild/rebuild.expected
91cc8ad to
5577474
Compare
5577474 to
d78e27d
Compare
adpaco-aws
left a comment
There was a problem hiding this comment.
Thanks, @celinval !
The tests in this PR are looking great but I don't know where the first line comes from in, for example, this test:
target/same.log:0
target/same.log: All fresh
target/same.log: No harness
target/same.log: ok
Other than that, only minor comments.
There was a problem hiding this comment.
Are you expecting more work around this particular case?
There was a problem hiding this comment.
No... this warning actually explicitly states that Cargo might turn the warning into error in the near future. So I highly doubt they will invest time to fix this issue.
zhassan-aws
left a comment
There was a problem hiding this comment.
Very cleverly crafted tests! A couple of comments.
| target/initial.log:Checking harness check_u8_u32... | ||
| target/initial.log:Complete - 2 successfully verified harnesses, 0 failures, 2 total. | ||
| Run with a new argument that affects compilation | ||
| target/enable_checks.log:4 |
There was a problem hiding this comment.
Why did the number go down by 1 from initial.log?
There was a problem hiding this comment.
Sorry, I updated the test to use a crate with less dependencies. But that was a great question, so I reverted the test locally to double check. The reason is that one of the crates (autocfg) is a build-dependency. Here is the result of cargo tree for the original test:
└── num-bigint v0.4.3
├── num-integer v0.1.45
│ └── num-traits v0.2.15
│ [build-dependencies]
│ └── autocfg v1.1.0
│ [build-dependencies]
│ └── autocfg v1.1.0
└── num-traits v0.2.15 (*)
[build-dependencies]
└── autocfg v1.1.0
The cache for build dependencies doesn't get affected by the argument change, since the build dependency configuration uses host configuration.
There was a problem hiding this comment.
And here is the full compilation log:
Run with a new argument that affects compilation
Compiling num-traits v0.2.15
Compiling num-integer v0.1.45
Compiling num-bigint v0.4.3
Compiling target_lib v0.1.0 (/kani/tests/script-based-pre/build-cache-dirty/target/target_lib)
There was a problem hiding this comment.
Got it, thanks for clarifying.
| OUT_DIR=target | ||
|
|
||
| # Expects two arguments: "kani arguments" "output_file" | ||
| function check_kani { |
There was a problem hiding this comment.
It might be better to put this function in a different file and source it in each of the scripts to avoid repetition.
There was a problem hiding this comment.
I totally agree, but this compiletest mode fails if it finds any subdirectory that is not a test. So to reuse this file, I would have to define the function inside one test folder and make all the other tests point to that folder.
So I decided to keep it simple and just use redundancy for now.
1- Improve test results readability. 2- Fix / improve comments.
| provide::provide_extern(providers); | ||
| } | ||
|
|
||
| fn print_version(&self) { |
There was a problem hiding this comment.
This doesn't seem to be used anywhere.
There was a problem hiding this comment.
In theory this is a function that the compiler uses to print the codegen version. Note that it is part of the implementation of the CodegenBackend trait.
There is a limitation in the compiler today where this doesn't get invoked for codegen backend that was configured via the driver, but I figured we might as well implement it and once this issue gets fixed, we get our version printed correctly.
| .action(ArgAction::SetTrue), | ||
| ) | ||
| .arg( | ||
| Arg::new("check-version") |
There was a problem hiding this comment.
Nit: should this be called kani-version?
There was a problem hiding this comment.
This is just a dummy argument, so I don't think it matters. I figured that we could eventually ensure that the kani-compiler matches the driver version, but I didn't bother here.
Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
zhassan-aws
left a comment
There was a problem hiding this comment.
Thanks for all the hard work and numerous PRs to allow re-enabling the cache @celinval!
|
Oh, one more thing: please make sure to add this to the |
Description of changes:
This change re-enable the build cache in Kani. For that, we also added a new dummy option that includes Kani's version, which will ensure that the cache gets refreshed when the user upgrades Kani.
Resolved issues:
Resolves #1736
Resolves #2140
Resolves #2036
Related RFC:
Call-outs:
cargo-ui/supported-lib-types/lib-rlib, we declare redundant types which generate a conflict name warning:while subsequent runs print the same warning and crash:
The same behavior can be reproduced using
cargo build.Testing:
How is this change tested? New tests
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.
edit: No longer delete the problematic test.