Use deterministic randomness in arbitrary tests #1120
Merged
Conversation
This file contains 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
|
The CI failure is strange. It looks like a change in rust nightly linting behavior, and can be reproduced with Possibly rust-lang/rust#117120 and rust-lang/rust#116033. |
|
Thanks for sharing the command to minimally reproduce it. That helped. I've opened this to fix the lint warnings in nightly: |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 24, 2023
### What Fix nightly lints on unused internal exports ### Why #1120 (comment)
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.
What
Use a seeded StdRng instead of thread_rng in arbitrary tests.
Why
Per stellar/rs-soroban-env#810 randomized test cases should be deterministic.
Known limitations
This is different from the approach in soroban-env-host from stellar/rs-soroban-env#1124, where a test prng is attached to the env / host.
There are two more uses of thread_rng in this crate, but I don't know enough about that code to know how they should be removed, i.e. if they should follow a pattern similar to soroban-env-host. I am willing to replace all uses of thread_rng if given guidance about the preferred way to do it.
The implementation of StdRng is allowed to change in the future, so it's possible the exact numbers generated could change. I could import rand_chacha instead if desired.