Replace toml_map_to_field and toml_remap with traits to map between InputValues and TomlTypes

[TomAFrench]

Related issue(s)

Description

Summary of changes

I've replaced the functions toml_map_to_field and toml_remap with implementations of TomlTypes::from<InputValue>() and InputValue::try_from<TomlTypes>(), i.e. rather than mapping the entire set of arguments at once we specify how to map a single input from one type to another.

We can then just iterate over each argument and map them individually.

Dependency additions / changes

N/A

Test additions / changes

N/A

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Additional context

[jfecher]

Looks great, just one style comment that you can choose to ignore if you wish. Seems like we need to re-run the CI as well.

[TomAFrench]

Looks like this will end up incompatible with #622 due to it requiring context about whether a particular value is a field or a string which we can't pass to try_from. We could create some ad-hoc conversion method however where we can pass in the desired AbiType.

[vezenovm]

Looks like this will end up incompatible with #622 due to it requiring context about whether a particular value is a field or a string which we can't pass to try_from. We could create some ad-hoc conversion method however where we can pass in the desired AbiType.

I like the move away from toml_map_to_field, however, as you mention this change will be incompatible with #622. I think we will have to add an ad-hoc method that accepts an AbiType in order for this to work with the changes for string inputs. That PR has some last changes that are being pushed through and should be closed soon

[jfecher]

I believe the reason PR #622 adds the type-aware conversions is to keep allowing "0xabcd" in the toml to decode to an integer or field. Does toml not allow unquoted hexadecimal literals like 0xabcd or is there some maximum bits limitation in toml I'm not aware of? If toml allows the unquoted hex literals my vote would be to remove support for the quoted ones.

[vezenovm]

I believe the reason PR #622 adds the type-aware conversions is to keep allowing "0xabcd" in the toml to decode to an integer or field. Does toml not allow unquoted hexadecimal literals like 0xabcd or is there some maximum bits limitation in toml I'm not aware of? If toml allows the unquoted hex literals my vote would be to remove support for the quoted ones.

To my knowledge toml does not allow unquoted hexadecimal literals and that is why we use strings for hexadecimal inputs. If toml does allow unquoted hex literals I agree we should just remove support for the quoted ones to avoid confusion.

[TomAFrench]

Does toml not allow unquoted hexadecimal literals like 0xabcd or is there some maximum bits limitation in toml I'm not aware of? If toml allows the unquoted hex literals my vote would be to remove support for the quoted ones.

It does support hex representations of integers however integers are limited to values which fit in an i64 so without accepting string representations we wouldn't be able to specify a large range of fields.

[TomAFrench]

I've rebased this back on top of master to support string types.

[jfecher]

👍