Clippy: -D question_mark #3645
Clippy: -D question_mark #3645
Conversation
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.
| if ret.is_err() { | ||
| return ret; | ||
| } | ||
| .unwrap_or(Err(ErrorCode::RESERVE))?; |
There was a problem hiding this comment.
Two better options
| .unwrap_or(Err(ErrorCode::RESERVE))?; | |
| .or(Err(ErrorCode::RESERVE))?; |
| .unwrap_or(Err(ErrorCode::RESERVE))?; | |
| .map_err(|e| ErrorCode::RESERVE)?; |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
You're right, the first one should not have an enclosing Err
| Some(ShaOperation::Sha256) => self.sha.set_mode_sha256()?, | ||
| Some(ShaOperation::Sha384) => self.sha.set_mode_sha384()?, | ||
| Some(ShaOperation::Sha512) => self.sha.set_mode_sha512()?, | ||
| _ => return Err(ErrorCode::INVAL), | ||
| } |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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)?; |
There was a problem hiding this comment.
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.
|
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. |
c032a17
|
The dismissed reviews are from doing a trivial merge with |
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
/docs, or no updates are required.Formatting
make prepush.