-
Notifications
You must be signed in to change notification settings - Fork 88
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
error-stack
: move fmt::HookContext
into hook::HookContext
#1693
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1693 +/- ##
==========================================
+ Coverage 55.95% 57.26% +1.30%
==========================================
Files 223 223
Lines 14935 15253 +318
Branches 380 380
==========================================
+ Hits 8357 8734 +377
+ Misses 6573 6514 -59
Partials 5 5
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
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.
✅ Looks good, happy to approve when CI is green 🎉
pub fn cast<U>(&mut self) -> &mut HookContext<Extra, U> { | ||
// SAFETY: `HookContext` is marked as repr(transparent) and the changed generic is only used | ||
// inside of the `PhantomData` | ||
unsafe { &mut *(self as *mut Self).cast::<HookContext<Extra, U>>() } | ||
} |
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 take the opportunity to ask this question as we touched this code: Do you see a way to remove the unsafe
here? I know, why we have, I'm just wondering if there is a way to avoid it (this question is unrelated to this PR).
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 don't think so, if we would instead transmute mut self
instead we could use RFC 2528 may be of help.
## 🌟 What is the purpose of this PR? #1693 separated `fmt::HookContext` into `hook::HookContext` and `fmt::HookContext`, so that it can be used in #1558. While working, the problem is that documentation doesn't render correctly because `hook::HookContext` is private in public. Therefore unreachable rustdoc is unable to navigate to the type, and the documentation is incomplete. This PR moves to a macro-based approach to enable better documentation. Instead of using an unreachable public type, we have a macro that implements the necessary common functions. This is by far not ideal, but I found this to be the best way without compromising #1558 or future hooks.
🌟 What is the purpose of this PR?
This is in preparation for #1558 and generalizes the
HookContext
(notably storage) into its own (isolated) typeHookContext<T, U>
, which is generic over two parameters:T
, which are the extra values that might be needed ndU
, the current type accessed and used for storage partitioning.Why is this needed?
serde
hooks will also need a way to use and store context-sensitive information. I found a lot of code duplication when trying to mirror the storage API, so I chose the consolidation into a single struct. This is purely an internal change and does not change anything for library consumers.👂 Open Questions
Because cargo-doc considershook::context::HookContext
to be private, we currently do not generate any docs for the new inner type. We would need a way to expose those.Using
cfg(doc)
we now expose the struct, which is a bit hacky but enables documentation of all functions.🔗 Related links
📜 Does this require a change to the docs?
No, purely internal change.
🛡 What tests cover this?
Existing tests.