Generate Clippy clean code

[notpeter]

This came up in the discussion of #1357 so I wanted to break it out into it's own issue.

Quick thoughts:

It'd be nice if progenitor generated code didn't generate Clippy warnings. This makes it possible to enforce Clippy passing on your entire project (ci enforced; rust-analyzer warnings). In particular Clippy is useful in improving the human readability of Rust code. The potential for catching

As a quick win, I've reduced by Clippy warnings to zero by creating a pipeline that generates code -> runs clippy --fix -> runs rust fmt (via rustfmt-wrapper). Ideally this is something that progenitor would support natively without requiring a wrapper.

Duplicating @ahl's comment:

Initial thoughts: progenitor has not had as a goal generation of clippy-clean code. There's a good reason for that! Clippy is intended for code written by humans. Or written by LLMs and read by humans? For example, we would prefer a human (or LLM) write if foo_list.is_empty() ... rather than if foo_list.len() == 0, but they have the same meaning, and produce the same eventual binary (I trust). Modifying code generation to handle that case is--I think--the wrong trade-off: it adds complexity to the code we maintain while adding cleanliness to the code we don't.

My thought in this case is--I think?--the same as the strawman above. Also, this is--I assume--an example of clippy uncleanliness that you encountered, but there are others that you didn't. If the goal is to make generated code clippy-clean, how thorough would we want to be? How would we want to build out the testing framework to ensure clippy-cleanliness? More specifically, I worry about future changes (e.g. by me!) forgetting to add to this "is it Copy" list that we've hard-coded.

So those are my thoughts. I hope that can be the start of a discussion; they're not intended as an edict--just the basis on why we are where we are.

---

I don't have a sense of all the possible inputs which may result in progenitor generating code with clippy warnings, not the types of the warnings. But perhaps this is a place for such a discussion -- especially if they are trivial enough that clippy --fix can automagically take care of them without additional complexity to code generation machinery. More complexity situations / fixes would have to be taken on a case-by-case basis.

[ahl]

As noted above and in #1357: clippy cleanliness is a non-goal. In particular, I think it's the wrong trade-off to have added complexity in the generatING code in order to have greater simplicity or cleanliness in the generatED code.