Low hanging fruite lint do-over.

[Ben-PH]

Apologies if this comes across as low-effort. On potentially new projects, I like to turn on pedantic lints, and go through what comes out and see what little chores I can help with. It gives me a chance to familiarise my self with the projects contribution work flow, as well as get a start at looking at the code base.

The bulk of the lints are merging of the match statements.

There is also (according to the lint) a minor performance gain when using an &&str type: (*the_str).to_string() is better than the_str.to_string().

There are some other lints that promise to be minor micro-optimisations, but they change the interface (mostly about arguments being references vs owned).

If you want, I can also make changes to the private functions where clippy suggests these api changes.

[sharkdp]

Thank you. It's not that it comes off as low-effort, but to be honest, it's also not a huge gain in most cases. And it introduces merge conflicts for a lot of open PRs.

I'm happy to accept PRs like this, but it would be great if you could maybe start with the things you think are most beneficial. And do maybe one lint per PR?

[Ben-PH]

Sure thing. I won't take offense if you say that it's more effort than it's worth on your part, either. I'll break it down into bite-sized PRs. I'll add to lib.rs (commented out) #!(warn(clippy::...)] to indicate the lints (which can be taken out of the PR if you prefer).