fix clippy lints and other minor improvements #688
Conversation
A test tries to compare equality of `Vec`s, approximately `x.sort() == y.sort()`, but `sort()` uses in-place mutation, and returns `unit`, not the input `slice`, so the lists are never actually compared.
It's possible for a call to `File::open()` to succeed even if reading from that `File` isn't actually possible due to the `File` being a directory. In such cases, `Lines` can return `Err` infinitely, causing `filter_map()` to diverge while searching for a nonexistant `Ok`. This is a semantic change. `filter_map()` can filter multiple errors before returning lines again, while `map_while()` will stop iterating entirely at the first `Err`. However, errors are unlikely at all since the `file` argument is currently always a preallocated temporary file for collecting `Command` output. This merely mitigates the worst case if `lines_from_file()` is ever used in a way where this error could occur.
replace `Vec<String>` with `Vec<&str>` to reduce allocation
all ranges are already iterators
`append(true)` implies `write(true)`
|
@cole-h It appears from merged pull requests that you have been the primary ofborg maintainer for some time. Is that still the case? |
There was a problem hiding this comment.
The project appears rather outdated and unidiomatic in general
I'd agree with that 😆
Would there be any problems with replacing hubcaps with octocrab?
In principle, no, but when I played with that in the past (which was a while ago to be fair), I think it was missing something that would severely handicap ofborg's functionality (not that I can remember what that was now, though... maybe checkruns are unsupported?).
Why was this used in the first place? Does anyone depend on this particular format?
allocation should be avoided when possible since it's relatively slow
abysssol
force-pushed
the
fix-clippy-lints
branch
from
c71505c to
0cde2ec
Compare
|
By the way, now that you're done with review, would you like me to squash some of the commits to reduce the quantity of minor commits? I could squash some of the minor clippy fixes, and maybe a couple others. I don't know if it matters, though. Are there any guidelines on commit quantity and size? Any personal preferences? Do you have any general feedback on how I structured the commits? Anything I could improve? Thank you for all your help. |
No need to squash, I'll just rebase-merge as-is.
The commits were good, no specific guidance there. Been deployed for ~1.5h now and seems to be working fine, so I'm gonna merge it now. Thanks again for your effort! |
I was planning on creating a pull request to improve ofborg's behavior when requesting reviews, but noticed that clippy was emitting a lot of warnings and an error. So, I decided to start by fixing them, and along the way ended up adding other assorted improvements as well.
The project appears rather outdated and unidiomatic in general. It seems a partial rewrite may be in order. Most of the dependencies should probably be updated or replaced (
traitobjectisn't sound since it assumes the layout of fat pointers, but won't be fixed since it's unmaintained). Would there be any problems with replacinghubcapswithoctocrab?Notable commits:
07c2ccf
9925e49
5299de3