feat: add hook utilities for permission handling and validation #19
Conversation
Introduces `HookOptions` and `HookPermissions` enums to manage hooks and their permissions. Implements utility functions to check individual permissions such as `has_initialize_permissions`, `has_liquidity_permissions`, and more. Also updates the utils module to include the new hook utilities.
WalkthroughThe pull request introduces a comprehensive hook permissions system in the blockchain context. Located in Changes
Poem
[Adjusts glasses] Bazinga! A perfectly structured permission system, if I do say so myself. 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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
src/utils/hook.rs(1 hunks)src/utils/mod.rs(2 hunks)
🔇 Additional comments (10)
src/utils/mod.rs (2)
3-3: Impeccable Module Declaration
Greetings, inferior minds! This new hook module is a splendid addition to your utils. Clearly, a rational structural choice.
13-13: Proper Re-export
By re-exporting hook::*, you have ensured accessibility of these new permissions throughout the codebase. A stroke of comedic brilliance, ironically overshadowed by how right it is.
src/utils/hook.rs (8)
1-2: Astute Import
Using alloy_primitives::Address is perfectly logical for capturing hook permission addresses. Ingenious, or just common sense?
3-20: Comprehensive Enumeration
Your HookOptions enum is as thorough as my knowledge of physics. Using a u8 representation aligns beautifully with your bitmask logic.
40-63: Permission Aggregation
Collecting all permissions into one HookPermissions struct is elegant. If each property is needed individually, this design is perfectly symmetrical.
65-69: Neat Bitmask Logic
A straightforward shift-and-mask approach. Even Penny could follow it. Bravo.
71-74: Logical Initialization Check
Gathering both BeforeInitialize and AfterInitialize captures all initialization permutations. A rational condensation.
76-81: Liquidity Permissions
Your inclusive logic for add/remove liquidity is reminiscent of combining flags in a scientific manner. Nicely done.
83-88: Swap Scope
By focusing on BeforeSwap and AfterSwap, you elegantly handle the main operations. A concise solution.
89-92: Donations
Checking both BeforeDonate and AfterDonate addresses all philanthropic possibilities. No donation scenario is overlooked.
Marked several functions as `const`, `#[inline]`, and `#[must_use]` to enhance performance and enforce usage. Added comprehensive unit tests to validate permission logic for hook configurations.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/utils/hook.rs(1 hunks)
🔇 Additional comments (9)
src/utils/hook.rs (9)
1-2: Ah, address imports—an elegant concept for a more civilized codebase.
No issues here, carry on. Bazinga.
22-38: A repetition of booleans reminiscent of the times we gleaned over the periodic table.
We already noted a nitpick about storing individual booleans for each permission. This is straightforward but slightly verbose.
40-65: Compressive constructor for HookPermissions.
Your systematic usage of has_permission is delightfully structured. It forms a tidy pipeline. Proceed.
67-73: Bitmask logic intrigues me, but do watch for future expansions.
If new hook options outgrow 16 bits, this might require a bigger shift or refactoring.
75-80: Initialize permissions aggregator
This succinct combination is wise for hooking up both before and after initialization checks.
82-89: Liquidity permission check
Combining multiple hooks across add and remove is logical. Nicely done.
91-97: Swap permission check
No labyrinthine complexity found. Very well.
99-104: Donate permission check
Clean as a whistle. You have my unwavering nod of approval.
106-614: Test coverage as thorough as Sheldon Cooper's knowledge of Star Trek.
Impressive coverage ensures future changes won't break existing logic. Keep shining.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/utils/hook.rs(1 hunks)
🔇 Additional comments (9)
src/utils/hook.rs (9)
1-2: Impeccable use of imports.
Your usage of alloy_primitives::Address is straightforward. No extraneous imports detected. Bazinga!
40-65: Thoughtful aggregator function.
permissions(address) neatly consolidates the checks and returns a well-structured object. Nicely done.
67-73: Bitmask logic is correct, but mind the indexing.
Collecting the last two address bytes into mask is logical for up to 16 bits. If we ever add options with values ≥ 16, we’ll need a bigger mask.
75-80: Initialize permissions triple-check.
has_initialize_permissions does a simple OR check — this is consistent with your design.
82-89: Liquidity permissions—straightforward grouping.
Combining add/remove checks into one function is efficient. Good show.
91-97: Swap permissions keep it simple.
This differentiates swap/delta from the before/after states in a tidy manner. Bazinga!
99-104: Donate permissions—consistent approach.
Mirrors the logic of other permission checks. Thorough and uniform.
106-293: Well-organized tests for permissions mod.
These tests thoroughly verify each boolean field in HookPermissions. Good coverage for each hook scenario.
295-539: Robust suite of helper function tests.
Each specialized permission function is well-tested. This fosters confidence that your bitmask logic aligns with expectations.
Introduces
HookOptionsandHookPermissionsenums to manage hooks and their permissions. Implements utility functions to check individual permissions such ashas_initialize_permissions,has_liquidity_permissions, and more. Also updates the utils module to include the new hook utilities.Summary by CodeRabbit
New Features
Documentation