feat(`forge bind`): dedupe generated alloy type bindings by sharing types

[alxiong]

Component

Forge

Describe the feature you would like

Currently alloy bindings are all separate in their own submodule, if multiple child contracts uses the same library, e.g. contract B and C uses library A, then types in library A will appear in both the bindings of B and C in the current version of forge bind --aloy

a concrete example is:

https://github.com/EspressoSystems/espresso-network/tree/ace0e437e653187a9cd8e50fd71da6403c18f3ef/contracts/rust/adapter/src/bindings
you will find pub mod BN254 { pub struct G1Point } both in lightclient.rs and iplonkverifier.sol and plonkverifier.sol and they are all mutually incompatible types (or different types)

This create pains because any additional methods written for one of the types won't be translated over to another. (e.g. the From<arkworks::G1Point> for G1Point)

This doesn't used to be a problem in ethers-rs's bindings, because the share_types.rs logic, where shared types are extrapolated out into a separate files and all other modules inherits from that.

This issue requests a similar feature in alloy bindings.

Additional context

No response

[alxiong]

A stopgap solution for those who runs into the same headache:
Try to somehow have a function with public visibility in the youngest/child contract (in the inheritance tree) that involves all of the struct/data type so that all of your rust bindings are imported from that.

That should solve lots of type-incompatible problem, even though you still have tons of code duplication in your bindings.

here's a concrete example: EspressoSystems/espresso-network@7751233

previously our LightClient.sol doesn't have any function that involves struct IPlonkVerifier.VerifyingKey. Thus its bindings are created in iplonkverifier.rs instead of lightclient.rs, and then rust compiler will complain about the different BN254 types used.

what I did was to deliberately have a public function that involves the missing type (i.e. function _getVk() public returns (IPlonkVerifier.VerifyingKey), (so that the bindings show up in that rust module). You can even write a dummy function that does nothing. (again, this is a stopgap solution, not an ideal solution)

[mattsse]

I see, thanks for the repro.

I think it should be possible to dedup library types here, looks looks currently those get inlined in contract bindings.

@DaniPopes what would be the best way to do this?