tests regarding cargo fetching destination are broken on i686

[jcgruenhage]

Describe the bug
There's two test cases that currently fail on i686 machines:

advisories::helpers::test::converts_url_to_path
index::bare::test::matches_cargo

To Reproduce
Steps to reproduce the behavior:

1. Get a 32 bit x86 machine
2. Try to run the tests.

Expected behavior
Tests are working.

Screenshots
https://github.com/void-linux/void-packages/runs/4137744216?check_suite_focus=true#step:7:352, and in case that log disappears:

[Jake-Shadle]

cargo calculates a hash based off various bits of info that is used as part of the root directory for all crate downloads, indexes, and sources, so I guess this is hashing differently on a 32-bit machine vs 64-bit. The code in question is located here https://github.com/EmbarkStudios/cargo-deny/blob/main/src/index.rs#L236 if you want to compare how cargo is doing this compared to this function, which is mostly just a slimmed down version of what cargo does with only the pieces that we care about.

If you can't/don't have time to do this yourself I will try and look at it eventually, but to be honest x86 support is really low on priority.

[jcgruenhage]

I'll see whether I have time to work on this myself, but I currently don't think so, for the same reason, 32 bit x86 support is really low on my priority list as well. I just reported it because it popped up in the CI over at void-linux/void-packages#33951.

If those tests are failing, is it safe to assume that cargo-deny will not work because it won't find the files it's looking for?

[Jake-Shadle]

Yes, but only advisories, all the other checks should work I believe, thanks for linking the issue with the CI failure, I didn't know this existed.

[jcgruenhage]

I'd still go ahead and mark the package as broken on i686 then in Void

[ericonr]

This probably happens on all 32-bit platforms, not only i686.

[ericonr]

At a guess, 2usize.hash(&mut hasher); is the issue. usize is platform dependent; if anyone could try patching that to be 2u64, it might be enough?

[Jake-Shadle]

@ericonr good call, this was indeed the issue!