-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement new lint iter_over_hash_type
#11791
Conversation
r? @Jarcho (rustbot has picked a reviewer for you, use r? to override) |
084792b
to
7bc39f3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall fine other than some small changes. It would be nice if this could handle adapters being used (e.g. map
), but that can be done as a future extension.
@rustbot author
&& (match_def_path(cx, did, &HASHMAP_KEYS) | ||
|| match_def_path(cx, did, &HASHMAP_VALUES) | ||
|| match_def_path(cx, did, &HASHSET_ITER_TY) | ||
|| is_type_diagnostic_item(cx, ty, sym::HashMap) | ||
|| is_type_diagnostic_item(cx, ty, sym::HashSet)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is missing HashSet::IterMut
, HashMap::Iter
, HashMap::IterMut
and HashMap::ValuesMut
. Drain
for both collections should probably also be caught.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HashSet::IterMut
doesn't appear to exist, but I'll add the rest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it does not.
/// | ||
/// ### Why is this bad? | ||
/// Because hash types are unordered, when iterated through such as in a for loop, the values are returned in | ||
/// a pseudo-random order. As a result, on redundant systems this may cause inconsistencies and anomalies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: an undefined order
'pseudo-random' is not technically wrong, but very misleading.
cx, | ||
ITER_OVER_HASH_TYPE, | ||
expr.span, | ||
"iterating over unordered hash-based type", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: iteration over
@rustbot ready |
tests/ui/iter_over_hash_type.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like tests with type aliases as well, like FxHashMap
. This should work since you use the typeck table but it should be linted
0d686fa
to
f8ea496
Compare
Thank you. @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Implements and fixes #11788
This PR adds a new restriction lint
iter_over_hash_type
which preventsHash
-types (that is,HashSet
andHashMap
) from being used as the iterator infor
loops.The justification for this is because in
Hash
-based types, the ordering of items is not guaranteed and may vary between executions of the same program on the same hardware. In addition, it reduces readability due to the unclear iteration order.The implementation of this lint also ensures the following:
HashMap::keys
,HashMap::values
, andHashSet::iter
are also denied when used infor
loops,changelog: add new
iter_over_hash_type
lint to prevent unordered iterations through hashed data structures