-
Notifications
You must be signed in to change notification settings - Fork 295
Add AcknowledgeCheckFailedReason
#2862
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
Merged
jessebraham
merged 6 commits into
esp-rs:main
from
bjoernQ:prepare-i2c-ackcheckfailedreason
Jan 10, 2025
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
d8c9a3b
Add `AcknowledgeCheckFailedReason`
bjoernQ 8ebb1f9
Fix
bjoernQ 28e162f
Remove unused AcknowledgeCheckFailedReason variants
bjoernQ e7278ac
Re-introduce Data and Address, again
bjoernQ f9816b4
Clippy + Tests
bjoernQ 46e6942
Merge branch 'main' into prepare-i2c-ackcheckfailedreason
jessebraham File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why is this
non_exhaustive
, isn't this enum complete? What else is there for the device to not acknowledge?(Using both
Unknown
andnon_exhaustive
seems wrong to me at a glance)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.
In future we might want to provide more information with the error (e.g. at which byte count the nack was detected) - adding such a variant would be a breaking change then. I imagine user-code will do the same when matching
Unknown
or_
so I don't think it's a big dealI agree for now we wouldn't even need
Address
andData
for now, thenThere 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.
Wouldn't such a change be breaking (as we'd add the info to
Data
)? Or how do you imagine such change to manifest?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.
if we change the variant that would be breaking - but we could add another variant - but I agree we should just remove the currently unused variants for now
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.
Adding a variant can still be a breaking change, not at compile time but at runtime. Errors are tricky.
If you add a new variant that is a subset of an existing variant, this is a breaking change.
Imagine a user doing something like this. (Based on the documentation this is acceptable to do)
If you split
Unknown
intoUnknown
andAddress
, once the user pulls in the new version of esp-hal, this if statement no longer executes where they expected it to.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.
yes but that is true for pretty much every error-enum we have
checking an error like that is also bad for exhaustive enums
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.
My code example isn't fantastic but it's easy for code to semantically look like that.
Perhaps I'm being paranoid, I can't think of a nice solution besides completing the enum.
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.
There is precedent in rust std to introduce such breaking changes. We can't prevent users from explicitly matching against
Unknown
but we can document that we don't guarantee that we don't split error variants out of it, and it should be handled as the "nothing else applies" case.That being said, we should be extra careful with these cases. We should probably add and handle Address and Data right now, and accept that they won't carry additional data, or include an empty
struct
in them if we know we might have something useful in them later.