Fix rand_os warning in tests#144
Conversation
There was a problem hiding this comment.
I am confused:
- Before merging this PR, it appears that
masterbuilds/tests successfully. - Before merging this PR, it appears that
zcash:masterin https://github.com/zcash/librustzcash/blob/master/librustzcash/Cargo.toml#L31-L32 does not specify arand_osdependency. - This PR removes https://github.com/zcash/librustzcash/pull/144/files#diff-856d0c87bdf2a3f58e126d860ca3fd75L190 which is a
use rand_osline.
How can all three of these be true? Shouldn't that use rand_os line cause building tests to fail, since it's not a declared dependency?
|
Hm, if the tests aren't build/executed for the code being patched, I would change my review to "Request Changes" to request they get added into the CI pipeline in this PR. If instead that code is tested but there's something I'm missing / confused about with dependencies or rust, then I would probably approve this comment and learn something new. |
The tests all pass on this branch. The one failing step is Travis CI, which is trying to also run code coverage and as a result often runs over the 50-minute maximum execution time. Re-running the build is usually sufficient to have it succeed because then the build step is cached.
This PR is changing the |
nathan-at-least
left a comment
There was a problem hiding this comment.
I believe this resolves my previous confusion, and my new belief is that this dependency was declared, but no longer use'd anywhere. Is that true?
(Seems like an opportunity for a linter / unused-code style warning.)
Correct. It was declared as a dev-dependency though, so zero effect on the main code. The tests wouldn't catch unused dev-dependencies, because they can be used for tests, doc-tests, examples, and benchmarks. There might be a clippy lint for it, but we're a while away from being able to add those to CI. |
…-risk fix: prevent mock verifiers from silently bypassing crypto in production
Warnings were originally fixed in #134. This warning was introduced in #114, but it wasn't spotted because there was no merge conflict.