-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential backwards incompatibility in ABI generated for sequence of pairs #34
Comments
I am not able to reproduce the problem for system contract either. But I could reproduce the problem @arhag observed using a simplified table:
If I removed |
Post Following is a comparison between CDT
In Since
Option 1 is preferred, as the change is straightforward. |
I prefer option 1 as well. So to clarify, with option 1, we basically go back to rc1 behavior except that It is unfortunate that it is a backwards incompatible change, but technically 3.0.0 introduced a backwards incompatible change to the ABI of But please wait to get feedback from @larryk85 before working on any changes. |
Please use option 1. |
Consider the ABIs generated by the following two fields in the core contract of EOS system contracts:
https://github.com/eosnetworkfoundation/eos-system-contracts/blob/a408ba6610f22ee6df312eb5e7a9897ee1522776/contracts/eosio.system/include/eosio.system/eosio.system.hpp#L443
https://github.com/eosnetworkfoundation/eos-system-contracts/blob/a408ba6610f22ee6df312eb5e7a9897ee1522776/contracts/eosio.system/include/eosio.system/eosio.system.hpp#L476
The first field (
return_buckets
) has typestd::map<time_point_sec, int64_t>
and the second (rex_maturities
) has typestd::deque<std::pair<time_point_sec, int64_t>>
. While it would be preferable to just usestd::vector
in both cases, usage of these types in a table is acceptable and from the ABIs perspective they should both map to the same ABI types.When compiling with CDT v3.0.0-rc3, the ABI generated for
return_buckets
is a list of a custom struct (pair_time_point_sec_int64[]
) where the ABI for structpair_time_point_sec_int64
is given by:When compiling with CDT v3.0.0-rc3, the ABI generated for
rex_maturities
has typeB_pair_time_point_sec_int64_E[]
) in whichB_pair_time_point_sec_int64_E
is a type alias that points to the same custom structpair_time_point_sec_int64
defined above.Some have reported that when compiling with the latest CDT 3.0.0, the ABI generated for
rex_maturities
now becomespair_time_point_sec_int64[]
directly (without the type alias intermediary) andreturn_buckets
is still a list of the custom struct (pair_time_point_sec_int64[]
), however, now the ABI definition ofpair_time_point_sec_int64
has changed to:I was not personally able to replicate the above behavior exactly. When I compile EOS system contract with CDT 3.0.0, I still get the first version of the ABI.
However, I was able to get something close to the above difference by intentionally not including the
rex_return_buckets
(which holds thereturn_buckets
field) in the ABI (by removing the[[eosio::table,eosio::contract("eosio.system")]]
attribute from the struct). In this case, there is no ABI generated for thereturn_buckets
field and the ABI generated for therex_maturities
field is stillB_pair_time_point_sec_int64_E[]
. But now the ABI for the custom structpair_time_point_sec_int64
usesfirst
andsecond
as opposed tokey
andvalue
.The fact that CDT may generate an ABI for a sequence of pairs in different ways as described above can be considered a problem since the change of
key
tofirst
andvalue
tosecond
(or vice versa) would be considered a breaking change to the interface of a smart contract.This may be related to the changes of #23.
The text was updated successfully, but these errors were encountered: