Updates following hashbrown's inclusion in std #127
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
Hashbrown has a different ordering from HashMap, even with deterministic fnv hashing, so the tests were failing on beta. This changes nameattr to use an indexmap instead, which has a reliable ordering at all times (insertion order). This is probably a better behavior anyway, because it means that attributes will be added in the order they appear in the nameattr file.
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.
hashbrownno longer needs to be included as a dependency. It also has a different ordering than the oldHashMap, which caused our nameattr tests to start failing. Instead of relying on the new order (which would make tests fail on stable), I changed the implementation to use anIndexMap(which preserves insertion order) so that we aren't dependent on the map order any more. This is probably also more reasonable, since it means that the attribute order from the nameattr file will be preserved.This PR also switches most maps to use FNV hashing, since we don't really need the adverserial robustness that randomized hashing gives us in this context.