Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented Aug 23, 2023

Pull Request Overview

This pull request fixes the question mark clippy lint that says to use ? instead of checking the error and then returning it.

This makes some changes to make the ? use more natural.

Skips the epmp because it is changing anyway.

Testing Strategy

travis

TODO or Help Wanted

n/a

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

bradjc added 2 commits August 23, 2023 14:58
When can use the ? to return early when an error code is detected. The
basic conversion leads to some odd rust code, so this makes things more
rust-y.

Skips the epmp because that is being replaced.
@github-actions github-actions bot added kernel arch/risc-v RISC-V architecture WG-OpenTitan In the purview of the OpenTitan working group. labels Aug 23, 2023
if ret.is_err() {
return ret;
}
.unwrap_or(Err(ErrorCode::RESERVE))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two better options

Suggested change
.unwrap_or(Err(ErrorCode::RESERVE))?;
.or(Err(ErrorCode::RESERVE))?;
Suggested change
.unwrap_or(Err(ErrorCode::RESERVE))?;
.map_err(|e| ErrorCode::RESERVE)?;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alevy The first one changes the semantics (and I'm not sure would pass the type-checker). For a Result<T, E>, unwrap_or() takes a T and returns either the Ok(T) contained in the result, or the default value. or() will return a different Result<T, F> passed in, in case the original result is an Err(_).

Second case is good, but we should rename e or _ to avoid an unused closure argument warning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the first one should not have an enclosing Err

Some(ShaOperation::Sha384) => self.sha.set_mode_sha384()?,
Some(ShaOperation::Sha512) => self.sha.set_mode_sha512()?,
_ => return Err(ErrorCode::INVAL),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think either of these is more clear what's going on:

app.sha_operation.ok_or(ErrorCode::INVAL).map(|op| {
                        ShaOperation::Sha256 => self.sha.set_mode_sha256(),
                        ShaOperation::Sha384 => self.sha.set_mode_sha384(),
                        ShaOperation::Sha512 => self.sha.set_mode_sha512(),
                    })?;
let op = app.sha_operation.ok_or(ErrorCode::INVAL)?;
match op {
    ShaOperation::Sha256 => self.sha.set_mode_sha256()?,
    ShaOperation::Sha384 => self.sha.set_mode_sha384()?,
    ShaOperation::Sha512 => self.sha.set_mode_sha512()?,
}

First, we transform the Option into a Result that basically says: if you passed in None that was invalid. Then, we get to assume it's not erroneous, and we match on the operation, erroring if setting the mode is unsupported (or whatever the error is).

}
AesOperation::AES128CCM(_encrypt) => Ok(()),
AesOperation::AES128GCM(_encrypt) => Ok(()),
match app.aes_operation {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto here to the SHA version. Though, of course, many correct patterns can co-exist. It's just my taste.

if let Err(e) = AES128::set_key(self.aes, buf) {
return Err(e);
}
AES128::set_key(self.aes, buf)?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole block can be simplified dramatically. I can take a pass, or we can avoid additional changes in this PR, and just focus on making clippy happy, cleaning up code style even more separately.

alevy
alevy previously approved these changes Aug 25, 2023
Copy link
Member

@alevy alevy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments, but personally I'm for merging as is rather than blocking the clippy work on style bikeshedding

@bradjc
Copy link
Contributor Author

bradjc commented Aug 25, 2023

I would prefer to keep the clippy PRs just fixes for clippy so we don't have to review these PRs for other changes as well.

ppannuto
ppannuto previously approved these changes Aug 29, 2023
@ppannuto ppannuto added the last-call Final review period for a pull request. label Aug 29, 2023
hudson-ayers
hudson-ayers previously approved these changes Sep 1, 2023
@alevy alevy dismissed stale reviews from hudson-ayers, ppannuto, and themself via c032a17 September 3, 2023 18:58
@alevy
Copy link
Member

alevy commented Sep 3, 2023

The dismissed reviews are from doing a trivial merge with master, thus I'm making an executive decision to merge this as long as I didn't break the build, assuming that @hudson-ayers and @ppannuto would trivially re-appprove.

@alevy alevy added this pull request to the merge queue Sep 3, 2023
Merged via the queue into master with commit b41ecd3 Sep 3, 2023
@alevy alevy deleted the clippy-D-question-mark branch September 3, 2023 22:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch/risc-v RISC-V architecture kernel last-call Final review period for a pull request. WG-OpenTitan In the purview of the OpenTitan working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants