-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Primitive Proptests #1435
Support for Primitive Proptests #1435
Conversation
TOOD: API implementation, BODY1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add some documentation on what you're doing in the proptest override? Maybe a README.md?
We now have a fork of propest. What's the best way to maintain this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should add the proptest code in our repository. We should probably do one of the following:
- Refactor the changes so we can extend proptest instead of forking from it.
- If we do need to fork proptest, we should create a separate repository with the fork. We should then add a submodule here to this fork.
Feel free to ping me offline if you want to discuss this further or if you have any suggestions.
setup_lib(&out_dir, &lib_out, "kani"); | ||
setup_lib(&out_dir, &lib_out, "kani_macros"); | ||
setup_lib(&out_dir, &lib_out, "std"); | ||
println!("cargo:rustc-env=KANI_LIB_PATH={}", lib_out); | ||
println!("cargo:rustc-env=TARGET={}", target); | ||
println!( | ||
"cargo:rustc-env=KANI_EXTERN_OUT_DIR={}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why you are not using out_dir?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo kani
compiles to the directory with target/$ARCH/debug/deps
automatically.
I've found the incremental build to be a bit more finichy when using target/debug/deps
perhaps because cargo build --workspace
will also compile to the same directory. I can give it a try if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Yeah, that is a problem that we have with our libraries today. We are compiling them twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that one of the issues addressed in your linker update? If so, I can hold off on this one until that is in, and both std/proptest can take advantage.
@@ -80,10 +82,18 @@ impl KaniSession { | |||
}); | |||
} | |||
|
|||
let mut symtabs = glob(&outdir.join("*.symtab.json"))?; | |||
let mut metadata = glob(&outdir.join("*.kani-metadata.json"))?; | |||
if std::env::var("IS_KANI_PROPTEST").is_ok() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I posted a comment in the issue you created. Can you please check?
@@ -80,10 +82,18 @@ impl KaniSession { | |||
}); | |||
} | |||
|
|||
let mut symtabs = glob(&outdir.join("*.symtab.json"))?; | |||
let mut metadata = glob(&outdir.join("*.kani-metadata.json"))?; | |||
if std::env::var("IS_KANI_PROPTEST").is_ok() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we planning to enable this as a compilation flag or a runtime option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of now, scripts/cargo-kani
detects proptests automatically. I would be OK making it an argument, perhaps via -Z
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's probably better if the user has to opt-in at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments. :)
@@ -19,4 +19,26 @@ then | |||
fi | |||
KANI_PATH=${KANI_CANDIDATES[0]} | |||
|
|||
# if the crate uses proptest, get ready to run that. Make sure local | |||
# proptest import and kani's proptest does not clash. | |||
function has-direct-proptest-import() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't add any logic to these scripts. They are meant to be a proxy that enables development and it will actually not run with our pre-build code.
Is there a reason why this is not inside kani-driver
? We are already invoking cargo metadata
there which already has this information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why this is not inside kani-driver? We are already invoking cargo metadata there which already has this information.
If it already has Cargo.toml
info, I'll move to that
# not support any integers, which crashes this test case. See | ||
# https://github.com/model-checking/kani/issues/1473 for details. | ||
# [dev-dependencies] | ||
# proptest = "1.0.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer if you add a runtime option for users to enable proptest analysis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll resolve this along with the comment with IS_KANI_PROPTEST
Until the ticket for approving the separate repository goes through, code review for proptests will be managed through the features/proptest branch. The proptest fork will be imported through submodules. |
Closing in favor of the following approaches.
proptest = { path = "$PATH_TO/STUBBED/proptest"}
[patch.crates-io]
proptest = { path = "$PATH_TO/STUBBED/proptest"} |
Description of changes:
Adds support for running proptests with primitive inputs using kani.
Resolved issues:
Resolves #1363
Call-outs:
cargo kani
.tests/cargo-kani/rectangle-example
. This means we disable the proptest import in that test case.Testing:
How is this change tested?
tests/cargo-kani/proptest
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.