-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
improve the proptest of the resolver. #6120
Comments
proptest basic validation This adds a function for testing that the output of the resolver is basically reasonable. This function has the same signature as the function for running the resolver in a test. So it is easy to switch back and forth, depending on the thoroughness vs speed tradeoff. This also adds a proptest/fuzz that runs this validation against arbitrary registry. cc #6120 Sorry about the cargo fmt.
Cc, @necaris |
Another property, that I think will shrink well, that will take some design work, is order randomization. |
Resolver cleanups and a new fuzz test This is the commits from my on going work on pub/priv deps that did not relate to that functionality. Then it also adds a fuzz test that minimal-versions does not change whether resolution is possible. cc #6120
Just came across this excellent summary of how to make properties. |
varisat is on crates.io, and may work. At the moment @jix recommendations for |
Test the Resolver against the varisat Library Resolution can be reduced to the SAT problem. So this is an alternative implementation of the resolver that uses a SAT library for the hard work. This is intended to be easy to read, as compared to the real resolver, and run as part of the test sweet to make sure the real resolver works as expected. Part of #6120. Some notes on performance: The initial version did not support public & private deps: ~64 loc, `O(nln(n))` vars, `O(nln(n) + n*d)` clauses, 0.5x slower on `prop_passes_validation` The final version: ~163 loc, `O(dn^2`) vars, `O(dn^3)` clauses, 1.5x slower on `prop_passes_validation` That comparison makes me feel better about spending months trying to get public & private deps to be fast enough for stabilization.
We have some proptests that are used to fuzz the resolver. They were introduced in #5921. However, not all the good ideas from that discussion got implemented in the initial push. This is a list of good ideas related to using proptests on the resolver to act as a hub.
The current strategy does not:
[patch]
sources #7118The current properties do not test:
The text was updated successfully, but these errors were encountered: