EOSIO.CDT (Contract Development Toolkit) is a suite of tools used to build EOSIO contracts
This release contains a new feature and miscellaneous updates.
eosio:read_only
to enforce read-only nature of an action (#1068). If an action has this attribute but calls specific write host functions, by default the contract compilation will stop and output error messages. If the compiler option --warn-action-read-only
is used, the compilation will continue but output warning messages. Currently, CDT only checks direct calls and limited ways of indirect calls of write host functions.This CDT feature provides warnings
to developers when using the contract-supported method of read-only queries from external clients via a new HTTP-RPC API endpoint in v2.2.0-rc1
nodeos called push_ro_transaction
. Prior to this release, access was limited to data stored in a single table in DB or KV tables via the get_tables
API, a mechanism which is exacting and inefficient. Read-only queries enable developers to perform more complex, cross-table queries natively via contract code with the assurance that table data is from the same block height. It can also be used to understand the consequences of a transaction before it is sent. For details please see Read-only Queries Documentation and the associated unit tests and (#10189).
Sample usage:
[[eosio::action, eosio::read_only]]
void hello(name user) {
int64_t ram, net, cpu;
get_resource_limits( user, ram, net, cpu );
}
The following code will cause compilation error, unless --warn-action-read-only
option is used:
[[eosio::action, eosio::read_only]]
void hello(name user) {
set_resource_limits( user, 0, 0, 0 );
}
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
This is the stable EOSIO.CDT v1.8.0 release with new features, stability changes, and miscellaneous updates.
cleos
to print these values for the end user and eosjs
and similar frameworks to be able to use the values for general computation. To utilize this new feature specify a type for the action return and then return the value as with a normal function call. An example application that is leveraging action results is available here.Sample usage:
[[eosio::action]]
std::string hello() {
return "hello, EOSIO!";
}
eosio::kv::map
. The protocol feature must be enabled before a contract may make use of the new type. It works like a traditional dictionary, with an interface very similar to std::map
. For more in-depth usage and documentation please either look in the docs
directory in this repository or preferably the developer portal. An example usage is available here.Very basic usage:
// the first parameter is the eosio name of the "table" so that it can be referenced via external tooling,
// the next parameter is the key type (can be any type) and then the value type (can be any type).
using cats = eosio::kv::map<"catmap"_n, std::string, cat_data_type>;
void update_cat(std::string name, int number_of_spots) {
cats cats_map;
auto cat_value = cats_map[name];
cat_value = cat{ cat_value.color, cat_value.tail_bobbed, number_of_spots };
}
In addition to this interface, there is another type called eosio::kv::table
that is currently in a developer preview state. This is to show what can be done with the system and allow for feedback as to what persistent storage APIs are the most effective and useful.
Update the underlying technology to leverage LLVM 9
(#896). This has enabled a few things for CDT. It means better support for the C++2a feature set, smarter base optimizer for the rest of the toolchain, and new features/bug fixes for linkage/compilation caused by LLVM 7.
As part of the package release the following set of tools are installed (#810):
When using eosio-cpp
to generate the WASM and ABI, if the contract is empty, or if the specified contract name doesn't match the real contract name, the ABI will silently not be generated. This fix adds warning output under those circumstances, or throws an exception with an error message.
-v
option of eosio-cpp and eosio-cc to use clang-9Special thanks to the community contributors that submitted patches for this release:
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
This release contains miscellaneous fixes.
When using eosio-cpp
to generate the WASM and ABI, if the contract is empty, or if the specified contract name doesn't match the real contract name, the ABI will not be generated silently. This fix adds warning output to that specific situation, or throws an exception with an error message.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
This release contains a number of new features and bug fixes.
cleos
to print these values for the end user and eosjs
like frameworks to be able to use those values for general computation. To utilize this new feature all the engineer has to do is specify a type for the action return and then return the value as you would with a normal function call. For an example application that is leveraging action results you can look here.[[eosio::action]]
std::string hello() {
return "hello, EOSIO!";
}
eosio::kv::map
. It works a lot like a traditional std::map
or dictionary would. And by default is very close interface to std::map
. For more in-depth usage and documentation please either look in the docs
directory in this report or more preferably the developer portal. You can also refer to an example implementation.
Very basic usage:
// the first parameter is the eosio name of the "table" so that it can be referenced via external tooling,
// the next parameter is the key type (can be any type) and then the value type (can be any type).
using cats = eosio::kv::map<"catmap"_n, std::string, cat_data_type>;
void update_cat(std::string name, int number_of_spots) {
cats cats_map;
auto cat_value = cats_map[name];
cat_value = cat{ cat_value.color, cat_value.tail_bobbed, number_of_spots };
}
In addition to this we also have another type called eosio::kv::table
that is currently in a developer preview alpha
state. This is to show what can be done with the system and allow for feedback as to what persistent storage APIs are the most effective and useful.
Updating the underlying technology to leverage LLVM 9
(#896). This has enabled a few things for CDT. It means better support for C++2a feature set, smarter base optimizer for the rest of our toolchain and any new features/bug fixes for linkage/compilation caused by LLVM 7.
As part of the package release we now install the set of tools (#810):
Documentation Thanks!
Special thanks to the community contributors that submitted patches for this release:
@justefg
@conr2d
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
This release contains a number of new features and bug fixes.
eosio::public_key
type and eosio::signature
have become more complex than a buffer of bytes. This will require some degree of refactoring of smart contracts that use these types. The new type eosio::ecc_public_key
are aliases to an std::array<char, 33>
(equivalent to the old capi_public_key
type), these are used to represent the original K1 and R1 keys. A new type eosio::webauthn_public_key
is provided to represent a WebAuthN public key. eosio::public_key
has changed to being an alias to std::variant<ecc_public_key, ecc_public_key, webauthn_public_key>
, this represents either a K1, R1 or a WebAuthN key. Much like the public key, eosio::ecc_signature
was added and this is an alias to std::array<char, 65>
(equivalent to capi_signature
type). In addition the eosio::webauthn_signature
type has been added to represent a WebAuthN signature. Again like the public key case, eosio::signature
has changed to be an alias to std::variant<ecc_signature, ecc_signature, webauthn_signature>
(these represent K1, R1 or a WebAuthN signature).C
smart contracts to access the set_proposed_producers_ex
intrinsic, C++
smart contracts now have a new data structure eosio::producer_authority
to represent a WTMSig block signing authority and a new method overload eosio::set_proposed_producers
which takes a vector of the aforementioned eosio::producer_authority
.eosio::block_signing_authority
was added (#688).preactivate_feature
, is_feature_activated
, and get_sender
. These also have new C++ methods eosio::preactivate_feature
, eosio::is_feature_activated
and eosio::get_sender
defined.std::string
has been added (#459). eosio::string
should be more efficient in memory usage and help to reduce the bloat to smart contract WASMs that std::string
imposes.__eosio_cdt__
, __eosio_cdt_native__
, __eosio_cdt_major__
, __eosio_cdt_minor__
, and __eosio_cdt_patchlevel__
to allow developers to know when compiling source with EOSIO.CDT and what particular version it is being compiled against (#781).capi_public_key
and capi_signature
types have been deprecated (#659) as of v1.7.0 and will be removed in the next release of EOSIO.CDT.eosiolib
prefix will now fail to compile.eosio::asset::to_string()
and related functions (#661).native tester
macros (#642, #660).<
for eosio::permission_level
(#656).-x
compile option (#682).std
types (#682).eosio::get_active_producers
(#682).eosio::extended_symbol
(#767).eosio::binary_extension
and explicit constructible types (#778).Special thanks to the community contributors that submitted patches for this release:
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
This is a RELEASE CANDIDATE for version 1.7.0. The latest STABLE release is v1.6.3.
This release contains a number of new features and bug fixes.
eosio::public_key
type and eosio::signature
have become more complex than a buffer of bytes. This will require some degree of refactoring of smart contracts that use these types. The new type eosio::ecc_public_key
are aliases to an std::array<char, 33>
(equivalent to the old capi_public_key
type), these are used to represent the original K1 and R1 keys. A new type eosio::webauthn_public_key
is provided to represent a WebAuthN public key. eosio::public_key
has changed to being an alias to std::variant<ecc_public_key, ecc_public_key, webauthn_public_key>
, this represents either a K1, R1 or a WebAuthN key. Much like the public key, eosio::ecc_signature
was added and this is an alias to std::array<char, 65>
(equivalent to capi_signature
type). In addition the eosio::webauthn_signature
type has been added to represent a WebAuthN signature. Again like the public key case, eosio::signature
has changed to be an alias to std::variant<ecc_signature, ecc_signature, webauthn_signature>
(these represent K1, R1 or a WebAuthN signature).C
smart contracts to access the set_proposed_producers_ex
intrinsic, C++
smart contracts now have a new data structure eosio::producer_authority
to represent a WTMSig block signing authority and a new method overload eosio::set_proposed_producers
which takes a vector of the aforementioned eosio::producer_authority
.eosio::block_signing_authority
was added (#688).preactivate_feature
, is_feature_activated
, and get_sender
. These also have new C++ methods eosio::preactivate_feature
, eosio::is_feature_activated
and eosio::get_sender
defined.std::string
has been added (#459). eosio::string
should be more efficient in memory usage and help to reduce the bloat to smart contract WASMs that std::string
imposes.capi_public_key
and capi_signature
types have been deprecated (#659) as of v1.7.0 and will be removed in the next release of EOSIO.CDT.eosiolib
header files from the old "eosiolib" prefix will now fail to compile.eosio::asset::to_string()
and related functions (#661).native tester
macros (#642, #660).<
for eosio::permission_level
(#656).-x
compile option (#682).std
types (#682).eosio::get_active_producers
(#682).Special thanks to the community contributors that submitted patches for this release:
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
This release contains a number of bug fixes.
eosio::asset::to_string()
and related functions (#661).native tester
macros (#660).<
for eosio::permission_level
(#656).-x
compile option (#682).std
types (#682).eosio::get_active_producers
(#682).Special thanks to the community contributors that submitted patches for this release:
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
inline
specifier for send_deferred
, this resolves duplicate symbol issues (#479).variants
of complex types (#520).Special thanks to the community contributors that submitted patches for this release:
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
This release provides a bug fix for malformed smart contracts generated by earlier versions of EOSIO.CDT that cause setcode to fail. #464 provides a bug fix for this issue. Please see v1.6.0 Release Notes for details of other changes
Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.
With release v1.6.0 the smart-contract writer no longer needs to manually add a dispatcher or use the EOSIO_DISPATCH
macro. The dispatcher will be created for the contract based on actions
, notify handlers
, pre_dispatch
hook and post_dispatch
hook (#395). This new feature allows for naming the C++ methods that constitute EOSIO actions any valid C++ name as long as you explicitly specify the valid EOSIO action in the corresponding attribute. The auto-generated dispatcher also enables the smart-contract developer to split up the logic of their contracts into sub-contracts and use an aggregate pattern to "link" these actions together in the dispatcher and have greater control in developing easier to maintain code. As part of this new auto-generated dispatcher, all smart-contracts built with this functionality will by default assert if an action is run against it that it has no entry for. The new dispatcher will also assert if the smart-contract receives an onerror
notification and the user would have to opt out of this by supplying an explicit notification handler for onerror
(#418). If the smart-contract writer still wishes to hand write their own dispatcher, they still have the option to do so and this will stop the generation of a dispatcher for the contract. Two new functions are defined for EOSIO smart contract development: pre_dispatch
and post_dispatch
. These are hooks that the contract writer can define in their smart contract to apply custom validation/logic before any dispatching is done and after any dispatching occurs.
As mentioned above, notification handling for smart-contracts is now enabled by a new attribute [[eosio::on_notify(<code account>::<action name>]]
which marks a method as a notification handler, much like how the [[eosio::action]]
attribute is used to mark an action. This new functionality allows the contract developer to specify what types of notifications a handler handles by giving the code account and name of the action. In addition to this the code account can be a wild-card (*
), which would allow the handler to accept notifications of a particular action from any code accounts. The addition of first class support for notification handling, should eliminate the need for contract writers to use custom macros or hand write their own dispatchers.
Support for source-level debugging for the "native" builds for smart-contracts has been added for both Linux and macOS, for more information about the native smart-contract API and set of tools please see native-tester.
With this release the C API is no longer available to smart-contract developers developing with C++, if developers still need these then they will have to build their smart contract with C and use the C compiler (and lose access to auto-generated dispatchers and most of eosiolib). To ease the transition for smart-contract developers, effort has been made to maintain lexical interfaces with the C intrinsics for their C++ type-safe counterparts. This means that most of the C API intrinsics now have proper C++ type-safe alternatives with no naming changes and take the same number of arguments and use types that lexically "match". However, some of the intrinsics could not be created this way and may cause breakage of builds. These new partitioned libraries are an opt-in for this release with deprecation warnings for the old includes, so developers have time to update their contracts if they so choose.
CAPI
will only be available to contract writers using eosio-cc
and purely for C
smart contracts.Contracts
will be available to eosio-cpp
for smart contract writing.Core
will be available to eosio-cpp
for any of the modes (present and future).eosio-cpp
in fnative
mode will have access to all of these groups.use-freeing-malloc
to the compiler you can opt in to using the old implementation. (#356)eosio::rope
is introduced in this release. This is a thin data structure for fast string concatenations, this will be more useful for wasm-ql
when it arrives. (#356)datastream
object. (#416)use-rt
to produce a binary that doesn't import the compiler-rt intrinsics. This is useful for generating WebAssembly that is more self-contained. This will be more useful when wasm-ql
arrives and future WASM modes are added. (#325)pre_dispatch
and post_dispatch
have been added for flexibility in control over smart contract dispatching. (#395)[[eosio::on_notify]]
to facilitate notification handling. (#395)native
, eosio smart contract
, wasm-ql
, and more flavors in the future. (#356)[[eosio::wasm_entry]]
is introduced to allow for a naming agnostic way of having an arbitrary WebAssembly entry function wrapped with global constructor and destructor calls. (#358)[[eosio::wasm_import]]
is introduced to allow for a more dynamic way of specifying WASM imports then a standalone file. This also allows for different libraries to easily expose their own import API. (#358)eosio-abigen | eosio-cpp
for issues with std::variant
types, and nested std::variant
(#399)eosio::onerror
asserting and contracts with no actions defined. (#418)wasm-ql
. (#426)wasm-ql
. (#439)eosio-ld
and eosio-cpp
. In the future use eosio-cpp
with the --abigen
flag, the ABI shouldn't change unless you change your code, so these two should be linked anyway. (#377)Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein, the related GitHub release, the EOSIO software or any documentation related to any of the foregoing, whether expressed or implied, and disclaim all liability that may arise from any use of the software or documentation for any purpose. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one.