rustfmt: Fix CI by running rustfmt on util/hash_tables.rs
#2919
Conversation
.. to fix the silent rebase conflict.
WalkthroughThe recent modifications focus on enhancing the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- lightning/src/util/hash_tables.rs (7 hunks)
Additional comments: 10
lightning/src/util/hash_tables.rs (10)
- 19-19: The usage of
std::collections::HashMapis correctly preserved under the condition that thehashbrownfeature is not enabled. This ensures backward compatibility and maintains the expected behavior in environments wherestdis available.- 21-21: The re-export of
std::collections::{hash_map, HashSet}under a conditional compilation flag is a good practice for maintaining modularity and ensuring that the correct data structures are used based on the build features.- 29-31: The
new_hash_mapfunction definition is straightforward and correctly utilizes theHashMap::new()method. This is a clean and efficient way to provide a utility function for creating new hash maps.- 36-42: The
hash_map_from_iterfunction is correctly implemented to create aHashMapfrom an iterator. This utility function enhances the code's readability and usability by abstracting the creation process.- 46-48: The
new_hash_setfunction is correctly implemented, providing a simple and effective way to create a newHashSet. This contributes to the consistency and readability of the codebase.- 52-54: The
hash_set_from_iterfunction is correctly implemented, allowing for the creation of aHashSetfrom an iterator. This utility function is a valuable addition for simplifying set creation.- 76-92: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [79-112]
The
RandomStatestruct and its implementation within thehashermodule under thehashbrown_tablesmod show a thoughtful approach to handling hash randomization in a no-std environment. The use ofgetrandomto opportunistically randomize the hash state is a good security practice. However, it's important to ensure that thepossiblyrandomfeature is correctly managed across different build configurations to avoid potential issues.Verification successful
The
possiblyrandomfeature is correctly configured in the Cargo.toml file, and its usage within the codebase is limited to thelightning/src/util/hash_tables.rsfile. This indicates a thoughtful approach to managing the feature across different build configurations, with no evidence of unintended side effects based on the provided context.* 124-124: The re-export of the `hasher` module's contents under the `hashbrown_tables` mod is a clean way to manage the visibility and usage of the `RandomState` struct and related functionality. This helps maintain a clear structure and separation of concerns within the module. * 143-149: The modified `hash_map_from_iter` function within the `hashbrown_tables` mod introduces a more efficient way to create a `HashMap` from an iterator by pre-allocating the minimum required capacity. This optimization can lead to performance improvements, especially for large collections. It's a good practice to consider the iterator's size hint for capacity estimation. * 163-165: The modified `hash_set_from_iter` function, similar to `hash_map_from_iter`, optimizes the creation of a `HashSet` from an iterator by pre-allocating the minimum required capacity. This change is consistent with the approach taken for hash maps and is a good example of applying performance optimizations uniformly across similar functionalities.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the `possiblyrandom` feature is correctly configured in Cargo.toml rg 'possiblyrandom' Cargo.toml # Ensure no unintended side effects in different build configurations rg 'feature = "possiblyrandom"' --files-with-matchesLength of output: 198
Here, we reformat
util/hash_tables.rsto fix the silent rebase conflict (i.e., it was introduced after the base of #2877) and unbreak CI.