Cleanup old references in docs.
Further rename of EOSIO.CDT to CDT. Further rename of eosio-cpp to cdt-cpp and eosio-cc to cdt-cc. Delete references to removed eosio-abigen tool. Replace references to old eos and eosio.cdt repos with leap and cdt respectively. Have not changed references eosio.contracts repo yet. Have not changed/removed URLs to developers.eos.io website. Other small cleanup and fixes to docs.
This commit is contained in:
Areg Hayrapetian
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "eosio.cdt",
|
||||
"name": "cdt",
|
||||
"generators": [
|
||||
{
|
||||
"name": "collate_markdown",
|
||||
|
||||
@@ -1,62 +1,5 @@
|
||||
---
|
||||
content_title: Binary Releases
|
||||
content_title: Installation
|
||||
---
|
||||
|
||||
CDT currently supports Linux x86_64 Debian packages.
|
||||
|
||||
## Debian Package Install
|
||||
|
||||
```sh
|
||||
wget https://github.com/eoscdt/releases/download/v3.0.0/cdt_3.0.0_amd64.deb
|
||||
sudo apt install ./cdt_3.0.0_amd64.deb
|
||||
```
|
||||
|
||||
## Debian Package Uninstall
|
||||
|
||||
```sh
|
||||
sudo apt remove cdt
|
||||
```
|
||||
|
||||
# Guided Installation or Building from Scratch
|
||||
|
||||
```sh
|
||||
git clone --recursive https://github.com/AntelopeIO/cdt
|
||||
cd eosio.cdt
|
||||
mkdir build
|
||||
cd build
|
||||
cmake ..
|
||||
make -j8
|
||||
```
|
||||
|
||||
From here onward you can build your contracts code by simply exporting the `build` directory to your path, so you don't have to install globally (makes things cleaner).
|
||||
Or you can install globally by running this command
|
||||
|
||||
```sh
|
||||
sudo make install
|
||||
```
|
||||
|
||||
## Uninstall after manual installation
|
||||
|
||||
```sh
|
||||
sudo rm -fr /usr/local/cdt
|
||||
sudo rm -fr /usr/local/lib/cmake/cdt
|
||||
sudo rm /usr/local/bin/eosio-*
|
||||
sudo rm /usr/local/bin/cdt-*
|
||||
```
|
||||
|
||||
# Installed Tools
|
||||
|
||||
* cdt-cpp
|
||||
* cdt-cc
|
||||
* cdt-ld
|
||||
* cdt-init
|
||||
* cdt-abidiff
|
||||
* cdt-wasm2wast
|
||||
* cdt-wast2wasm
|
||||
* cdt-ranlib
|
||||
* cdt-ar
|
||||
* cdt-objdump
|
||||
* cdt-readelf
|
||||
|
||||
License
|
||||
[MIT](../LICENSE)
|
||||
See README of https://github.com/AntelopeIO/cdt for instructions on how to build and install CDT.
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
content_title: cdt-abigen tool
|
||||
---
|
||||
|
||||
## This tool is deprecated, use `cdt-cpp` for generation of your ABIs
|
||||
|
||||
To generate an ABI with ```cdt-abigen```, only requires that you give the main '.cpp' file to compile and the output filename `--output` and generating against the contract name `--contract`.
|
||||
|
||||
Example:
|
||||
```bash
|
||||
$ cdt-abigen hello.cpp --contract=hello --output=hello.abi
|
||||
```
|
||||
|
||||
This will generate one file:
|
||||
* The generated ABI file (hello.abi)
|
||||
```
|
||||
USAGE: cdt-abigen [options] <source0> [... <sourceN>]
|
||||
|
||||
OPTIONS:
|
||||
|
||||
Generic Options:
|
||||
|
||||
-help - Display available options (-help-hidden for more)
|
||||
-help-list - Display list of available options (-help-list-hidden for more)
|
||||
-version - Display the version of this program
|
||||
|
||||
cdt-abigen:
|
||||
generates an ABI from C++ project input
|
||||
|
||||
-extra-arg=<string> - Additional argument to append to the compiler command line
|
||||
-extra-arg-before=<string> - Additional argument to prepend to the compiler command line
|
||||
-output=<string> - Set the output filename and fullpath
|
||||
-p=<string> - Build path
|
||||
```
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
content_title: EOSIO.CDT To CDT
|
||||
---
|
||||
|
||||
For this release all of the naming of namespaces and file paths will remain as `eosio`, so there is no need to migrate away from that with this release.
|
||||
|
||||
But there are a few differences.
|
||||
|
||||
1. The tool names have change prefix. I.e. tools like `eosio-cpp` are now `cdt-cpp`.
|
||||
2. The CMake toolchain file has changed its name from `EosioWasmToolchain.cmake` to `CDTWasmToolchain.cmake`.
|
||||
3. The library path for the CMake package has changed from `/usr/local/lib/cmake/eosio.cdt` to `/usr/local/lib/cmake/cdt` (or alternatively from `/usr/lib/cmake/eosio.cdt` to `/usr/lib/cmake/cdt` if installing from the Debian package). Additionally, the name to use with CMake `find_package` has similarly changed: use `find_package(cdt)` now instead of `find_package(eosio.cdt)`.
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
content_title: EOSIO.CDT To Leap.CDT
|
||||
---
|
||||
|
||||
For this release all of the naming of namespaces and file paths will remain as `eosio`, so no need to migrate away from that with this release.
|
||||
|
||||
But there are a few differences.
|
||||
|
||||
1. The tool names have change prefix. I.e. tools like `eosio-cpp` are now `cdt-cpp`.
|
||||
2. The cmake toolchain file has changed its name from `EosioWasmToolchain.cmake` to `CDTWasmToolchain.cmake`.
|
||||
3. The library path for the cmake package and package name have changed. `/usr/local/lib/cmake/eosio.cdt` to `/usr/local/lib/cmake/cdt` and in cmake `find_package(eosio.cdt)` to `find_package(cdt)`.
|
||||
@@ -4,7 +4,7 @@ content_title: Return Values From Actions
|
||||
|
||||
## Overview
|
||||
|
||||
`Leap` version 3.1 enables you to return any value from any action. This new feature facilitates easier smart contract implementation debugging, and better messaging between a smart contract and its clients. From now on the clients of a smart contract are able to use the value returned by an action, no more string parsing on the client side and no more print statements in the smart contract implementation.
|
||||
An Antelope blockchain with the `ACTION_RETURN_VALUE` protocol feature activated enables you to return any value from any action. This new feature facilitates easier smart contract implementation debugging, and better messaging between a smart contract and its clients. From now on the clients of a smart contract are able to use the value returned by an action, no more string parsing on the client side and no more print statements in the smart contract implementation.
|
||||
|
||||
## Concept
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ content_title: The eosio::binary_extension Type
|
||||
|
||||
Let's fully explain what the `eosio::binary_extension` type is, what it does, and why we need it for contract upgrades in certain situations.
|
||||
|
||||
You can find the implementation of `eosio::binary_extension` in the `eosio.cdt` repository in file: `eosio.cdt/libraries/eosiolib/core/eosio/binary_extension.hpp`.
|
||||
You can find the implementation of `eosio::binary_extension` within the CDT repository in the file: `libraries/eosiolib/core/eosio/binary_extension.hpp`.
|
||||
|
||||
Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in an `eosio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration.
|
||||
|
||||
@@ -366,7 +366,7 @@ Find below their corresponding sections in the `.abi` files:
|
||||
Now, let's start up a blockchain instance, compile this smart contract, and test it out.
|
||||
|
||||
```
|
||||
~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
```
|
||||
|
||||
```
|
||||
@@ -511,7 +511,7 @@ struct [[eosio::table]] structure {
|
||||
Next, let's upgrade the contract and try to read from our table and write to our table the original way:
|
||||
|
||||
```
|
||||
~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
content_title: Native Tester And Compilation
|
||||
---
|
||||
|
||||
As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. [`cdt-cc`](../03_command-reference/cdt-cc.md), [`cdt-cpp`](../03_command-reference/cdt-cpp.md) and [`cdt-ld`](../03_command-reference/cdt-ld.md) now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development \(note the default implementations of a lot of the Leap `intrinsics` are currently asserts that state they are unavailable, these are user definable.\)
|
||||
As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. [`cdt-cc`](../03_command-reference/cdt-cc.md), [`cdt-cpp`](../03_command-reference/cdt-cpp.md) and [`cdt-ld`](../03_command-reference/cdt-ld.md) now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development (note the default implementations of a lot of the Antelope intrinsics (aka host functions) are currently asserts that state they are unavailable, these are user definable.)
|
||||
|
||||
## Getting Started
|
||||
Once you have your smart contract written then a test source file can be written.
|
||||
@@ -91,10 +91,10 @@ int main(int argc, char** argv) {
|
||||
}
|
||||
```
|
||||
|
||||
Every `intrinsic` that is defined for eosio (prints, require_auth, etc.) is re-definable given the `intrinsics::set_intrinsics<intrinsics::the_intrinsic_name>()` functions. These take a lambda whose arguments and return type should match that of the intrinsic you are trying to define. This gives the contract writer the flexibility to modify behavior to suit the unit test being written. A sister function `intrinsics::get_intrinsics<intrinsics::the_intrinsic_name>()` will return the function object that currently defines the behavior for said intrinsic. This pattern can be used to mock functionality and allow for easier testing of smart contracts. For more information see, either the [tests](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/tests/) directory or [hello_test.cpp](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/tests/hello_test.cpp) for working examples.
|
||||
Every `intrinsic` that is defined for eosio (prints, require_auth, etc.) is re-definable given the `intrinsics::set_intrinsics<intrinsics::the_intrinsic_name>()` functions. These take a lambda whose arguments and return type should match that of the intrinsic you are trying to define. This gives the contract writer the flexibility to modify behavior to suit the unit test being written. A sister function `intrinsics::get_intrinsics<intrinsics::the_intrinsic_name>()` will return the function object that currently defines the behavior for said intrinsic. This pattern can be used to mock functionality and allow for easier testing of smart contracts. For more information see, either the [tests](https://github.com/AntelopeIO/cdt/tree/main/examples/hello/tests/) directory or [hello_test.cpp](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/tests/hello_test.cpp) for working examples.
|
||||
|
||||
## Compiling Native Code
|
||||
- Raw `eosio-cpp` to compile the test or program the only addition needed to the command line is to add the flag `-fnative` this will then generate native code instead of `wasm` code.
|
||||
- Raw `cdt-cpp` to compile the test or program the only addition needed to the command line is to add the flag `-fnative` this will then generate native code instead of `wasm` code.
|
||||
- Via CMake
|
||||
- `add_native_library` and `add_native_executable` CMake macros have been added (these are a drop in replacement for add_library and add_executable).
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ The following steps show:
|
||||
|
||||
### Automatic generation of CMake configuration
|
||||
|
||||
To compile a smart contract project with CMake, you'll need a CMake file. To use the new `eosio-init` tool to generate the directory structure stub `.hpp/.cpp` files and the CMake configuration files follow these steps:
|
||||
To compile a smart contract project with CMake, you'll need a CMake file. To use the new `cdt-init` tool to generate the directory structure stub `.hpp/.cpp` files and the CMake configuration files follow these steps:
|
||||
|
||||
```sh
|
||||
cd ~
|
||||
|
||||
@@ -54,7 +54,7 @@ Add the data structure data members. Each data member corresponds to a field of
|
||||
|
||||
### 3. Define The Primary Index
|
||||
|
||||
Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (eosio-cpp) will generate an error saying it can not find the field to use as the primary key:
|
||||
Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key:
|
||||
|
||||
```diff
|
||||
// the data structure which defines each row of the table
|
||||
@@ -116,7 +116,7 @@ Declare the `testtab` multi-index table as a data member of type `test_table_t`.
|
||||
Now you have instantiated a multi-index table, and assigned to `testtab` variable, which has a primary index defined for its `test_primary` data member.
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -116,7 +116,7 @@ __multi_index_example.hpp__
|
||||
Now you have instantiated the `testtab` as a multi-index table which has a primary index defined for its `test_primary` data member and a secondary index for its `secondary` data member.
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
[[warning | Do not add a secondary index to an existing table]]
|
||||
| Adding a secondary index to an existing multi-index table it will have unpredictable outcome. Consult the [Data design and migration](../best-practices/data-design-and-migration) documentation for more details.
|
||||
|
||||
@@ -146,7 +146,7 @@ __singleton_example.cpp__
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of singleton can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/singleton_example).
|
||||
| A full example project demonstrating the instantiation and usage of singleton can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ Check to see if the user exists and use [`erase`(...)](../../group__multiindex/#
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ Use the [`emplace`](../../group__multiindex/#function-emplace) method to make th
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ Add the data structure data members. Each data member corresponds to a field of
|
||||
|
||||
### 3. Define The Primary Index
|
||||
|
||||
Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (eosio-cpp) will generate an error saying it can not find the field to use as the primary key:
|
||||
Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key:
|
||||
|
||||
```diff
|
||||
// the data structure which defines each row of the table
|
||||
@@ -173,7 +173,7 @@ class [[eosio::contract]] multi_index_example : public contract {
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
+1
-1
@@ -155,7 +155,7 @@ __multi_index_example.cpp__
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
+1
-1
@@ -139,7 +139,7 @@ __multi_index_example.cpp__
|
||||
```
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ If the `user` object you want to update is found, the [`eosio::check`](../../nam
|
||||
Now you have implemented a new action `mod`. Call `mod` to update the `datum` data member for the user object identified by the `user` name parameter.
|
||||
|
||||
[[info | Full example location]]
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ multi_index_example::mod_action modaction("multiindexex"_n, {get_self(), 1});
|
||||
+modaction.send("eostutorial"_n, 1);
|
||||
```
|
||||
|
||||
For a full example see the [`multi_index` contract implementation](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example).
|
||||
For a full example see the [multi_index example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -64,7 +64,7 @@ action_response smrtcontract::checkwithrv( name nm ) {
|
||||
}
|
||||
```
|
||||
|
||||
For a complete example of a smart contract that implements an action which returns a value see the [hello example smart contract](https://github.com/EOSIO/eosio.cdt/blob/develop/examples/hello/src/hello.cpp#L16).
|
||||
For a complete example of a smart contract that implements an action which returns a value see the [hello example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/hello).
|
||||
|
||||
## Next Steps
|
||||
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
content_title: Error handling
|
||||
---
|
||||
|
||||
Contracts can use `uint64_t` error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, EOSIO and EOSIO.CDT reserve certain ranges of the `uint64_t` value space for their own purposes. Contract developers must be aware of the following ranges and restrictions:
|
||||
Contracts can use `uint64_t` error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, Antelope and CDT reserve certain ranges of the `uint64_t` value space for their own purposes. Contract developers must be aware of the following ranges and restrictions:
|
||||
|
||||
1. $0 - 4,999,999,999,999,999,999$:
|
||||
Available for contract developers to assign error codes specific to their contracts.
|
||||
|
||||
2. $5,000,000,000,000,000,000 - 7,999,999,999,999,999,999$:
|
||||
Reserved for the EOSIO.CDT compiler to allocate as appropriate. Although the WASM code generated by the EOSIO.CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file).
|
||||
Reserved for the CDT compiler to allocate as appropriate. Although the WASM code generated by the CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file).
|
||||
|
||||
3. $8,000,000,000,000,000,000 - 9,999,999,999,999,999,999$:
|
||||
Reserved for the EOSIO.CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by EOSIO.CDT.
|
||||
Reserved for the CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by CDT.
|
||||
|
||||
4. $10,000,000,000,000,000,000 - 18,446,744,073,709,551,615$:
|
||||
Reserved for EOSIO to represent system-level error conditions. EOSIO will actually enforce this by restricting the ability for `eosio_assert_code` to be used to fail with error code values used within this range.
|
||||
Reserved by the Antelope protocol to represent protocol-level error conditions. Antelope will actually enforce this by restricting the ability for `eosio_assert_code` to be used to fail with error code values used within this range.
|
||||
|
||||
Therefore, contract developers should only reserve error codes from the first range above to use in their contracts.
|
||||
|
||||
@@ -4,7 +4,7 @@ link_text: "Understanding ABI Files"
|
||||
---
|
||||
## Introduction
|
||||
|
||||
ABI files can be generated using the `eosio-cpp` utility provided by `eosio.cdt`. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary.
|
||||
ABI files can be generated using the `cdt-cpp` utility provided by CDT. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary.
|
||||
|
||||
## What is an ABI
|
||||
|
||||
@@ -35,7 +35,7 @@ Start with an empty ABI, for exemplification we will work based on the `eosio.to
|
||||
An ABI enables any client or interface to interpret and even generate a GUI for your contract. For this to work consistently, describe the custom types that are used as a parameter in any public action or struct that needs to be described in the ABI.
|
||||
|
||||
[[info | Built-in Types]]
|
||||
| EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/EOSIO/eos/blob/76565937064d5acccb089b50aa8ea797cd92dc82/libraries/chain/abi_serializer.cpp#L90)
|
||||
| EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/AntelopeIO/leap/blob/6817911900a088c60f91563995cf482d6b380b2d/libraries/chain/abi_serializer.cpp#L88-L129)
|
||||
|
||||
|
||||
```json
|
||||
|
||||
@@ -81,7 +81,7 @@ void some_function(...) {
|
||||
}
|
||||
```
|
||||
|
||||
The code above will mark an arbitrary function as an entry point, which will then wrap the function with global constructors (ctors) and global destructors (dtors). This will allow for the eosio.cdt toolchain to produce WASM binaries for other ecosystems.
|
||||
The code above will mark an arbitrary function as an entry point, which will then wrap the function with global constructors (ctors) and global destructors (dtors). This will allow for the CDT toolchain to produce WASM binaries for other ecosystems.
|
||||
|
||||
## [[eosio::wasm_import]]
|
||||
```cpp
|
||||
@@ -113,4 +113,4 @@ Contract actions tagged read-only:
|
||||
* Cannot call `inline actions`.
|
||||
* The amount of data returned by read-only queries is limited by the action return value size. By default these are set to 256 bytes by `default_max_action_return_value_size`.
|
||||
|
||||
The `eosio-cpp` and `eosio-cc` tools will generate an error and terminate compilation if an action tagged read-only attempts to call insert/update (write) functions, `deferred transactions` or `inline actions`. However, if the command-line override option `--warn-action-read-only` is used, the `eosio-cpp` and `eosio-cc` tools will issue a warning and continue compilation.
|
||||
The `cdt-cpp` and `cdt-cc` tools will generate an error and terminate compilation if an action tagged read-only attempts to call insert/update (write) functions, `deferred transactions` or `inline actions`. However, if the command-line override option `--warn-action-read-only` is used, the `cdt-cpp` and `cdt-cc` tools will issue a warning and continue compilation.
|
||||
|
||||
@@ -11,5 +11,5 @@ link_text: Manually write/edit an ABI file
|
||||
- The Ricardian contracts should be housed in a file with the name `<contract name>.contracts.md` and the clauses should be in a file named `<contract name>.clauses.md`.
|
||||
- For each Ricardian contract the header `<h1 class="contract">ActionName</h1>` should be used, as this directs the ABI generator to attach this Ricardian contract to the specified action.
|
||||
- For each Ricardian clause, the header `<h1 class="clause">ClauseID</h1>` should be used, as this directs the ABI generator to the clause id and the subsequent body.
|
||||
- The option `-R` has been added to [`eosio-cpp`](../../03_command-reference/eosio-cpp.md) and [`eosio-abigen`](../../03_command-reference/eosio-abigen.md) to add "resource" paths to search from, so you can place these files in any directory structure you like and use `-R<path to file>` in the same vein as `-I` for include paths.
|
||||
- For exemplification see [hello.contracts.md](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/ricardian/hello.contracts.md).
|
||||
- The option `-R` has been added to [`cdt-cpp`](../../03_command-reference/cdt-cpp.md) to add "resource" paths to search from, so you can place these files in any directory structure you like and use `-R<path to file>` in the same vein as `-I` for include paths.
|
||||
- For exemplification see [hello.contracts.md](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/ricardian/hello.contracts.md).
|
||||
|
||||
@@ -100,7 +100,7 @@ extern "C" {
|
||||
Deploy it and push an action to it. It is assumed you have a `debug` account created and have its key in your wallet.
|
||||
|
||||
```bash
|
||||
$ eosio-cpp -abigen debug.cpp -o debug.wasm
|
||||
$ cdt-cpp -abigen debug.cpp -o debug.wasm
|
||||
$ cleos set contract debug CONTRACT_DIR/debug -p youraccount@active
|
||||
$ cleos push action debug foo '{"from":"inita", "to":"initb", "amount":10}' --scope debug
|
||||
```
|
||||
|
||||
@@ -89,9 +89,9 @@ Couldn't parse type_name
|
||||
|
||||
__Possible solution__: It is possible that you changed the type of the fields for the table struct definition? If you need to change the table structure definition there are some limitations and a couple of ways to do it which are explained in the [Data Design and Migration](./07_best-practices/04_data-design-and-migration.md) section.
|
||||
|
||||
## eosio-cpp process never completes
|
||||
## cdt-cpp process never completes
|
||||
|
||||
__Possible solution__: make sure you have at least 2 cores on the host that executes the eosio-cpp (e.g. docker container, VM, local sub-system)
|
||||
__Possible solution__: make sure you have at least 2 cores on the host that executes the cdt-cpp (e.g. docker container, VM, local sub-system)
|
||||
|
||||
## You can not find the `now()` time function, or the result of the `current_time_point` functions are not what you expected them to be
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
content_title: eosio::binary_extension
|
||||
---
|
||||
|
||||
You can find the implementation of `eosio::binary_extension` in the `eosio.cdt` repository in [binary_extension.hpp](https://github.com/EOSIO/eosio.cdt/blob/master/libraries/eosiolib/binary_extension.hpp).
|
||||
You can find the implementation of `eosio::binary_extension` within the CDT repository in the file [binary_extension.hpp](https://github.com/AntelopeIO/cdt/blob/main/libraries/eosiolib/core/eosio/binary_extension.hpp).
|
||||
|
||||
The primary concern when using this type is when you are adding a new field to a smart contract's data structure that is currently utilized in an `eosio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration.
|
||||
|
||||
@@ -360,7 +360,7 @@ Find below their corresponding sections in the `.abi` files:
|
||||
<hr>Start up a blockchain instance, compile this smart contract, and test it out.
|
||||
|
||||
```
|
||||
~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
```
|
||||
|
||||
```
|
||||
@@ -503,7 +503,7 @@ struct [[eosio::table]] structure {
|
||||
Next, upgrade the contract and try to read from table and write to table the original way:
|
||||
|
||||
```
|
||||
~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
@@ -155,7 +155,4 @@ class [[eosio::contract]] multi_index_example : public contract {
|
||||
```
|
||||
|
||||
[[warning | Not recommended warning]]
|
||||
| Be aware, it is not recommend to use `eosio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated!
|
||||
|
||||
[[info | Implementation location]]
|
||||
| The implementation for ABI `variants` can be found [here](https://github.com/EOSIO/eos/pull/5652).
|
||||
| Be aware, it is not recommend to use `eosio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated!
|
||||
@@ -4,10 +4,7 @@ content_title: Create an ABI File
|
||||
|
||||
## Overview
|
||||
|
||||
This tutorial provides instructions to create an ABI file.
|
||||
|
||||
[[warning]]
|
||||
| As of v1.2.0, the eosio.wasmsdk was decoupled from the core repository. This change has introduced an eosio-cpp regression where the legacy eosio-abigen is no longer bundled with eosio-cpp. Until a new ABI generator is introduced, you will need to hand-write your ABI files.
|
||||
This tutorial provides instructions to how to hand-write an ABI file. This should normally not be necessary since `cdt-cpp` can automatically generate an ABI file from your source code if it is properly annotated.
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -38,7 +35,7 @@ An ABI enables any client or interface to interpret and even generate an GUI for
|
||||
[[info]]
|
||||
|Built-in Types
|
||||
|
||||
EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/EOSIO/eos/blob/master/libraries/chain/abi_serializer.cpp#L65-L103).
|
||||
EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/AntelopeIO/leap/blob/6817911900a088c60f91563995cf482d6b380b2d/libraries/chain/abi_serializer.cpp#L88-L129).
|
||||
|
||||
Using **eosio.token** as an example, the only type that requires a description in the ABI file is `account_name`. The ABI uses "new_type_name" to describe explicit types, in this case `account_name`, and `account_name` is an alias of `name` type.
|
||||
|
||||
|
||||
+6
-13
@@ -1,20 +1,13 @@
|
||||
# EOSIO.CDT (Contract Development Toolkit)
|
||||
# CDT (Contract Development Toolkit)
|
||||
|
||||
EOSIO.CDT is a toolchain for WebAssembly (WASM) and set of tools to facilitate smart contract development for the EOSIO platform. In addition to being a general purpose WebAssembly toolchain, [Leap](https://github.com/AntelopeIO/leap) specific optimizations are available to support building EOSIO smart contracts. This new toolchain is built around [Clang 9](https://github.com/AntelopeIO/cdt-llvm), which means that EOSIO.CDT has the most currently available optimizations and analyses from LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available.
|
||||
Contract Development Toolkit (CDT) is a C/C++ toolchain targeting WebAssembly (WASM) and a set of tools to facilitate development of smart contracts written in C/C++ that are meant to be deployed to an [Antelope](https://github.com/AntelopeIO/) blockchain.
|
||||
|
||||
In addition to being a general purpose WebAssembly toolchain, specific features and optimizations are available to support building Antelope-based smart contracts. This new toolchain is built around [Clang 9](https://github.com/AntelopeIO/cdt-llvm), which means that CDT inherits the optimizations and analyses from that version of LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available.
|
||||
|
||||
## Upgrading
|
||||
|
||||
There's been a round of breaking changes, if you are upgrading from an older version please read [Upgrading CDT to Leap](./04_upgrading/eosio.cdt-to-leap.cdt.md).
|
||||
|
||||
## Contributing
|
||||
|
||||
See the [Contributing Guide](https://github.com/eosnetworkAntelopeIO/leap/blob/main/CONTRIBUTING.md)
|
||||
If you are upgrading to CDT version 3.0 or later from version 1.8.1 (or earlier) of [EOSIO.CDT](https://github.com/EOSIO/eosio.cdt), then please read [EOSIO.CDT to CDT](./04_upgrading/eosio.cdt-to-cdt.md).
|
||||
|
||||
## License
|
||||
|
||||
[MIT](./../LICENSE)
|
||||
|
||||
## Important
|
||||
|
||||
See LICENSE for copyright and license terms. 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 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, service or other resource 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.
|
||||
|
||||
[MIT](../LICENSE)
|
||||
|
||||
Reference in New Issue
Block a user