Differing structs with duplicate "signatures" are combined into only one struct in output

[gnidan]

abi-to-sol will only ever produce exactly one struct definition for any number of tuple types that contain the same number of components with the same types of those components.

This is problematic, e.g. for @uniswap/v3-periphery's ISwapRouter, since ExactInputSingleParams and ExactOutputSingleParams both have the same "signature" [address,address,uint24,address,uint256,uint256,uint256,uint160], even though these are very different structs (the fields for "amount in" and "amount out" have their order reversed!) The resulting usage ends up looking something like this:

router.exactInputSingle(ISwapRouter.ExactOutputSingleParams({
  tokenIn: // ...,
  tokenOut: // ...,
  fee: // ...,
  recipient: // ...,
  deadline: // ...,
  amountOut: 1000,
  amountInMaximum: 10,
  sqrtPriceLimitX96: // ...
}));

Note that amountOut actually refers to amountIn, and amountInMaximum actually refers to amountOutMinimum!

This behavior is due to the way that abi-to-sol performs its initial first pass traversing the input ABI JSON in order to collect all tuple parameters to turn into struct definitions: it visits the ABI entries for all parameters, organizing tuple parameters by their signature. This results in the "undefined behavior" (so to speak) of later-appearing internalTypes overwriting earlier ones.

Proper behavior would be to keep track of these tuple parameters by their actual internalType information and keep things separate.

[gnidan]

The situation here has improved dramatically with abi-to-sol v0.8.0 (see release notes).

This tool should now respect existing internalType names for existing structs, and if two structs with different names have the same "type signature", abi-to-sol will no longer lose track of them.

This has not been completely solved yet, by this release, however, since the fix doesn't apply without internalTypes.

Future work to finally be able to close this will require the declaration search system to consider struct member names when determining which declaration to reference.