Additional error data in Result + some API cleanup and clarification #78
Conversation
This file contains 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
- Replace Result<()> with Result - Use new facility for cleanly reporting error data - Fix a few incorrect APIs (bad lifetime, error/warning confusion) - Drop some usage of core::result::Result, qualify the rest better
HadrienG2
commented
Jan 3, 2019
GabrielMajeri
approved these changes
Jan 4, 2019
|
I try to do this kind of API changes now so that we don't have to do them later, as the more UEFI entry points we have the more painful this exercise becomes (not to mention the impact on users, when we have more of them). It is also a good way for me to become more familiar with your work. Next things I'd like to work on:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR fixes #70 by adding support for additional error data to our Result type. As a result, usage of raw
core::result::Resultcan now be restricted to functions which do not call into UEFI.Since most functions do not return additional error data, the associated type parameter is optional with a default of
(). After some thought, I think that the main output should probably get the same treatment, as a large amount of "setter" UEFI functions do not emit anything more than a status code.While I went around the codebase to tweak every API entry point definition accordingly, I noticed a couple of issues here and there. Some entry points were in minor disagreement with the spec's semantics, while others did something wrong and dangerous. I'll clarify those changes as PR comments.
As I noticed some lifetime errors among these, I thought now might be a good time to use clearer lifetime parameter names in order to clarify the semantics of lifetime-based code. Result's generic parameters also got the same treatment.