chore: abstract away hashbrown

[DaniPopes]

Revm is moving away from hashbrown on std, so we want to stop exporting it ourselves.

[DaniPopes]

@grandizzy any idea why the test_persist_fuzz_failure test would fail with seemingly unrelated changes?

[grandizzy]

@grandizzy any idea why the test_persist_fuzz_failure test would fail with seemingly unrelated changes?

hm, it seems like test was delayed/reexecuted so failure was recorded for a different fuzzed input. Probably should make sure persist failure always deleted when test enters, I can look more into and make test robust

[grandizzy]

@grandizzy any idea why the test_persist_fuzz_failure test would fail with seemingly unrelated changes?

hm, it seems like test was delayed/reexecuted so failure was recorded for a different fuzzed input. Probably should make sure persist failure always deleted when test enters, I can look more into and make test robust

actually I can reproduce it locally with this branch, the failures are not properly reloaded from file hence new failures. I am looking into it, works OK in master

[grandizzy]

@grandizzy any idea why the test_persist_fuzz_failure test would fail with seemingly unrelated changes?

hm, it seems like test was delayed/reexecuted so failure was recorded for a different fuzzed input. Probably should make sure persist failure always deleted when test enters, I can look more into and make test robust

actually I can reproduce it locally with this branch, the failures are not properly reloaded from file hence new failures. I am looking into it, works OK in master

the issue is that with std HashSet the state is not reconstructed similarly / ordered between runs (as hashbrown's HashSet for some reason I'm missing it did...) using BTreeSet for FuzzDictionary fix this issue see #7438 Could introduce a slightly performance penalty @DaniPopes

[DaniPopes]

std hashmap is a wrapper around hashbrown, iteration order is never guaranteed
if order matters use vec or indexmap (crates.io)

[DaniPopes]

I wanted to use indexset anyway for performance when iterating, since we iterate way more than inserting values. Thanks for looking into it