-
Notifications
You must be signed in to change notification settings - Fork 6
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
Big Trait Changes #206
Big Trait Changes #206
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #206 +/- ##
==========================================
- Coverage 87.23% 83.87% -3.36%
==========================================
Files 42 43 +1
Lines 3595 3231 -364
==========================================
- Hits 3136 2710 -426
- Misses 459 521 +62 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
Shout out to our extensive tests that caught a ton of the mistakes I was making along the way! I would have forgot to add the signature check if we didn't have a test specifically that matched the interface+member but gave a blank body. |
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 to know whether the 'unchecked' should be marked unsafe
as well and whether we should call it unverified, unmatched because the Result
seems to suggest things are checked - which they are but not all - which may be clear to us now, but future me may not have a recollection of this.
c8414f0
to
1443168
Compare
Rebased on main. |
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 a nice improvement over what we have.
I would like to slap a comment or warning on the unchecked
and propose to rename it to something descriptive from_identified_message
and add its checking sibling to the trait [try_]from_message
which will do the tests. See the code review for more thoughts. I am curious to know if you think that makes sense!
Change trait bounds for auto-impl of MessageConversion
…-app/atspi into checked-and-unchecked-tryfrom-msg
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 in general.
Do we know if there are tangible performance fruits attributable from this PR?
Not sure if the path from Message to Event had become any cheaper but it also should not not be more expensive.
The thing I feel most uncomfortable with is the try_from_validated_message
which I think would improve if we renamed it to try_from_message_unchecked
. Please see comment in the relevant place.
I'd lile to hear your thoughts.
~50% performance increase! Branch(I ran this once before capturing the output, so branch is baseline)
Main
|
Excuse the issues with |
But your local git branch is tracking a remote branch isn't it? |
Couple untested areas I want to hit before merge. ETA one hour. |
Eh, this PR is too big already, let's just call it here. Plus it undermines the zbus 5.x PR since signatures are completely different. |
Summary
Split
BusProperties
into theconst &'static str
s (still calledBusProperties
), and message conversion:MessageConversion
(TODO: name).All trivial events (where they contain only the field
item
) now implementFrom<ObjectRef>
.All events that implement
From<ObjectRef>
get theirMessageConversion
implementation for free (blanket impl).Rename:
from_message_parts(ObjectRef, Self::Body)
, totry_from_message_unchecked(&zbus::Message)
An additional check was added to all implementations of
From<&zbus::Message>
(the macro) requireing that the body signature match the event's body signature—this supplements the xisitng checks on the interface and member.Commits
TODO
Event
and interface-grouped enums use_unchecked
instead ofTryFrom<&Message>
_unchecked
variant deserialization for interface-grouped enums, which will not check the validity of the interface before continuing,