This PR adds support for user-defined value types by redoing the internals of how abi-to-sol finds all the declared types it needs to emit.
Previously, abi-to-sol was built only to emit structs, and it relied heavily on the ABI schema's idea of a tuple signature (e.g. (uint256,address)) to organize all the known struct declarations. Struct signatures were used both during declaration collection and during code generation. This caused problems in #42 because signatures lose names, and the old format couldn't collect more than one struct for a given signature. This also prevented any kind of UDVT support, because everything was struct-based.
So this PR replaces that with several very-explicit-but-kind-of-messy modules for kinds, identifiers, etc.... and a new explicit bind step, whew! This explicit bind step is helpful and long overdue. In the spirit of structuring these new internals as an IR, things get complicated with ABI JSON parameter's type field, which is standard, and internalType, which is Solidity-specific. This PR includes a bunch of type guards for taking a type and classifying it as elementary/array/tuple/etc., and similarly classifying parameter type references as structs and UDVTs and whatnot.
To decouple code generation from struct signature based lookups, the new declarations collection system also provides corresponding search logic, so that when the code generator must output an ABI parameter, there's a first-class mechanism for finding the right declaration to use.
This PR also includes some unrelated changes:
Add madge
Use newer Solidiy for fast-check tests
Add test for output settings behavior
Upgrade TypeScript to ^4.9.5
Change lib from es2017 to es2019
Pin fast-check to match @truffle/abi-utils' version, since the arbitraries must match
Move the source-map-support stuff to the bin, not the lib itself (since that is wrong)
Notes:
Of course, UDVTs rely on internalType, so if Vyper ever adds those, this feature will likely need revisiting.
The fix for #42 relies on internalType also, so the system still might not be smart enough to pick the right struct if the input ABI doesn't have internalTypes. Fixing this limitation should now be doable thanks to the better organization scheme and search logic, but figured it wasn't urgent enough to include here.
Hopefully this lays the groundwork for #41, since things are more organized for that sort of change.
Addresses #113 and partially addresses #42
This PR adds support for user-defined value types by redoing the internals of how abi-to-sol finds all the declared types it needs to emit.
Previously, abi-to-sol was built only to emit
structs, and it relied heavily on the ABI schema's idea of a tuple signature (e.g.(uint256,address)) to organize all the known struct declarations. Struct signatures were used both during declaration collection and during code generation. This caused problems in #42 because signatures lose names, and the old format couldn't collect more than one struct for a given signature. This also prevented any kind of UDVT support, because everything was struct-based.So this PR replaces that with several very-explicit-but-kind-of-messy modules for kinds, identifiers, etc.... and a new explicit bind step, whew! This explicit bind step is helpful and long overdue. In the spirit of structuring these new internals as an IR, things get complicated with ABI JSON parameter's
typefield, which is standard, andinternalType, which is Solidity-specific. This PR includes a bunch of type guards for taking atypeand classifying it as elementary/array/tuple/etc., and similarly classifying parameter type references as structs and UDVTs and whatnot.To decouple code generation from struct signature based lookups, the new declarations collection system also provides corresponding search logic, so that when the code generator must output an ABI parameter, there's a first-class mechanism for finding the right declaration to use.
This PR also includes some unrelated changes:
Notes:
internalType, so if Vyper ever adds those, this feature will likely need revisiting.internalTypealso, so the system still might not be smart enough to pick the right struct if the input ABI doesn't haveinternalTypes. Fixing this limitation should now be doable thanks to the better organization scheme and search logic, but figured it wasn't urgent enough to include here.