Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

EOSIO.CDT Version 1.6.0 Release Notes
Compare
Choose a tag to compare
@larryk85 larryk85 released this 22 Mar 02:21
· 1497 commits to master since this release
v1.6.0
603b757
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

EOSIO.CDT Version 1.6.0

This release introduced a bug that generates malformed smart contracts that cause setcode to fail. Please use v1.6.1 instead to avoid this issue.

New Features

  • Auto-generation of smart-contract dispatcher.
  • First class support for notification handling.
  • Proper debugability for "native" build smart-contracts.
  • Partitioning of eosiolib to better facilitate good programming practices.

Auto-Generated Dispatcher

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.

First class support for notification handling (#395)

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.

Proper debugging for "native" built smart-contracts (#427)

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.

Partitioning of eosiolib to better facilitate good programming practices (#405)

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.

Summary Of Changes

eosiolib

  • Partitioning of eosiolib into three groups (CAPI, Contracts, and Core), these allow for finer grained allowance for particular modes of compilation. (#405)
    • The CAPI will only be available to contract writers using eosio-cc and purely for C smart contracts.
    • The 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.
  • New simple, small and fast grab-bag malloc is being introduced as the new default malloc. Caveats are that this will not free any memory when calling free (essentially a noop). If your contract needs to free memory because of overrunning malloc'd memory, then by passing the flag use-freeing-malloc to the compiler you can opt in to using the old implementation. (#356)
  • New data structure 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)
  • Fix off by one error in varint.hpp. (#402)
  • Fix contract::get_datastream() accessor to return a reference to its datastream object. (#416)

new libraries

  • Softfloat and compiler-rt are introduced in this release, these can be used with the flag 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)

tools

eosio-cpp

  • Auto generation of dispatcher for smart contracts. (#395)
  • Two new function hooks, pre_dispatch and post_dispatch have been added for flexibility in control over smart contract dispatching. (#395)
  • New attribute [[eosio::on_notify]] to facilitate notification handling. (#395)
  • ABI linking at the link stage of building smart contracts, which now allows for splitting your smart contract into multiple implementation files and still have ABI generation work. (#356)
  • Created system for modal compilation, i.e. native, eosio smart contract, wasm-ql, and more flavors in the future. (#356)
  • New attribute [[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)
  • New attribute [[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)
  • Fixes for eosio-abigen | eosio-cpp for issues with std::variant types, and nested std::variant (#399)
  • Removed timestamp from generated ABI file. (#352)
  • Fix codegen for niladic actions. (#412)
  • A few fixes for eosio::onerror asserting and contracts with no actions defined. (#418)
  • Changes to fix issue with compiling with the wrong LP64 model. (#424)
  • Various small fixes for user experience and more support for wasm-ql. (#426)
  • Fix for mac OS X debug native contract compilation, now supports source level debugging. (#427)
  • Renaming of exported functions for wasm-ql. (#439)

eosio-abigen

  • This tool is now deprecated because of the "ABI" linking capabilities of 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)

eosio-ld

  • Linkage of ABIs (now held in the object files), to produce the generated ABI. (#395)

eosio-init

  • Fix for invalid project names. (#370)

unit tests

  • Addition of eosiolib unit tests. (#424)

Special Thanks

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.

Assets 7
Loading