You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 29, 2024. It is now read-only.
Running cargo clippy (the linter) on the projects suggests that some key types in hashmaps which implement Ord and Eq have interior mutability (Cell/RefCell) members. This means that it's theoretically possible to mutate the value but not update the hash leading to a logic error. This is worth checking.
The text was updated successfully, but these errors were encountered:
Heh, I didn't know clippy had lints for this, that's great! I haven't run it locally yet, but I suspect this is due to using Signal references as keys. In this case, I actually want reference equality, not value equality; I believe the relevant usage and implementations of Eq etc should match that, and this should then be a non-issue (the actual values shouldn't matter, whether or not they could be changed). It's worth double-checking and possibly annotating the affected type(s) to explicitly allow the current usage in the linter (as well as document intent).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Running cargo clippy (the linter) on the projects suggests that some key types in hashmaps which implement Ord and Eq have interior mutability (Cell/RefCell) members. This means that it's theoretically possible to mutate the value but not update the hash leading to a logic error. This is worth checking.
The text was updated successfully, but these errors were encountered: