Open dallasjohnson opened 3 years ago
Can you please tell us which version of CDT you are using? eosio-cpp --version
There also exists a workaround for this as outlined in https://github.com/EOSIO/eosio.cdt/issues/658#issuecomment-571916106 - can you please let us know if this workaround is acceptable for your needs currently. We are also tracking the complete compatibility matrix as outlined https://github.com/EOSIO/eosio.cdt/issues/231 .
I tested both develop
and release\1.8.x
branches, and the generated ABI doesn't contain definition for pair_string_pair_string_string
mentioned above (see map_nest.cpp.txt and map_nest.abi.txt).
At the moment, typedef
or using
can be applied as a workaround (see map_nest2.cpp.txt
and map_nest2.abi.txt as an example).
After this PR https://github.com/EOSIO/eosio.cdt/pull/1213, the common used template can be nested use. After this PR, use don't need use typedef for common used template, such as vector, set, deque, map, pair, tuple..., and if you look into https://github.com/EOSIO/eosio.cdt/blob/develop/tests/unit/test_contracts/explicit_nested_tests.cpp, you will see a list of test for these nested types, now these types works well.
std::map types with nested std::map types not working with
abi-gen
I'm having trouble nesting
std::map
s inACTION
signatures and having them convert correctly throughabigen
.A single level of type traversal works for
std::map
to extract primitive types or pre-defined structs but it doesn't seem to work for extracting types recursively when the value type of astd::map
is also astd::map
For example a contract action like this:
the
name
anddetails
parameters are generated in theabi
and behave as expected but thenested_details
parameter does not work.The generated
abi
contains the following:I would have expects another struct to be extracted out as
pair_string_pair_string_string[]
perhaps with a format like this:This would then refer to the same extracted type from the
details
paramater typepair_string_string
with the vector wrapper ([]
) but this doesn't get generated, suggesting the abi type generation for maps is not recursive. When I tried adding it manually I was able install the abi into the blockchain but then I would get runtime errors in the contract related to "uninitialized table element" on this action which I believe is related to this point in the contract code although it's a little hard to be sure with only caveman debugging available. From this error message the only reference I could find to in thecdt
code was here: https://github.com/EOSIO/eosio.cdt/blob/a6b8d3fc289d46f4612588cdd7223a3d549238f6/tools/external/wabt/src/interp.cc#L1555 From there I got a bit lost to able able to pinpoint the cause any further.Other details not directly related to this issue
I have seen comments on Telegram saying that
std::map
s are quite expensive and their use should be minimised but when I consider an alternative structure here could be to provide a parameter of vectors (or possibly nested vectors) of another struct which contains thekey
as a field on that struct but I feel that would severely impact the readability of the ACTION signature since a vector does not implicitly enforce uniqueness across any keys as is implied with astd::map
. Another option could be to have a nested struct which only holds a map to wrap the nested map so the parameter would becomemap<string, nested_map_wrapper> nested_details
where thenested_map_wrapper
would only contain amap<string, string> nested_details
field. but this feels like an unnecessary level when there is not other reason to have it.It's worth noting the nested types are not required to exist in their own multi-index table row since they would never be queried or used without the context of the parent key.