feat(rust): Adds the ability to specify custom derive attributes

[thomastaylor312]

I also did a little bit of cleanup of clippy warnings while I was in these files.

Closes#554

[thomastaylor312]

I am pretty sure the test failure is a flake or not related to my code as I am seeing it in other PRs as well

[alexcrichton]

Thanks for this! No worries on the failed test, that's known to be flaky and should be resolved on main soon through ignoring it.

At a high level one concern I have about this is that it won't work for Resource types. That won't implement Serialize/Deserialize and doesn't currently implement PartialEq/Hash, although it perhaps could. This means that implementing traits uniformly for all types may not be sufficient and eventually this may need a form of "ignore this type" or "only derive for this type". That all being said I think it's fine to deal with those situations as they come up later, for now this is suitable and works well so I'd say we should land it and then iterate on further syntaxes later if necessary.

[alexcrichton]

No worries for this PR, but for future contributions I'd recommend splitting out clippy changes into a separate commit or possibly PR. Makes the "meat" elsewhere a bit easier to review that way.

[alexcrichton]

One important caveat to be aware of about HashSet<T> is that its iteration order is not defined and not deterministic between runs of a process. This means, for example, that different code is generated from the same WIT source as derives might be shuffled around.

Mind using a BTreeSet (or IndexSet) here instead to preserve order?

[thomastaylor312]

Oh right, I should have thought about the ordering issue. I'll switch that around

[thomastaylor312]

This should be all resolved, but leaving the comment unresolved until you have a chance to take a look at it

[thomastaylor312]

@alexcrichton Should be ready to go for a rereview

In regards to this:

At a high level one concern I have about this is that it won't work for Resource types. That won't implement Serialize/Deserialize and doesn't currently implement PartialEq/Hash, although it perhaps could. This means that implementing traits uniformly for all types may not be sufficient and eventually this may need a form of "ignore this type" or "only derive for this type". That all being said I think it's fine to deal with those situations as they come up later, for now this is suitable and works well so I'd say we should land it and then iterate on further syntaxes later if necessary.

I completely agree with the path forward here. I was curious how this would interact with resources, but it definitely seemed easiest to add this to struct/enum types for now and then we can see if there is a way to make it more specific in the future

[alexcrichton]

Looks great to me, thanks!

One option is to use the TypeInfo bits to avoid these extra derives for types-with-resources, but that's still a bit specific and may not work out in all cases. In any case this looks good for now 👍

[sehz]

does this work in cargo component ?

[thomastaylor312]

@sehz I was actually going to go open an issue over there in cargo component