cdt is missing support for the get_code_hash host function introduced with Antelope's GET_CODE_HASH protocol feature.

Verify that assumptions are matched for how the tool should function (dependency management, application construction, lib construction) as documentation is finalized

• Creation of antler-build #68
• Generation of base CMake #73
• Generation of CMake for dependencies #74
• Compile and Link core project #75
• Compile and Link tests #76
• Updates for DUNE to use antler-build
• Updates for eosio-lib to use antler-build
• Updates for eos-system-contracts to use antler-build

When building cdt with debug flags:

mkdir debug
cd debug
cmake -DCMAKE_BUILD_TYPE="Debug" -DTOOLS_BUILD_TYPE="Debug" -DLIBS_BUILD_TYPE="Debug" ..
make

Unit tests are still build in Release mode:

mikel@msi:~/repo/cdt/debug$ grep BUILD_TYPE tests/unit/CMakeCache.txt 
CMAKE_BUILD_TYPE:STRING=Release

Binary doesn't containg debug symbols:

mikel@msi:~/repo/cdt/debug/tests/unit$ objdump --syms asset_tests | grep debug
mikel@msi:~/repo/cdt/debug/tests/unit$

The same for tools.

Whereas remaining project is mostly build in Debug mode:

mikel@msi:~/repo/cdt/debug$ find . -type f -name "CMakeCache.txt"|xargs grep BUILD_TYPE
./libraries/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Debug
./cdt-llvm/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Release
./tools/toolchain-tester/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=
./tools/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Release
./tests/unit/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Release
./tests/integration/CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Debug
./CMakeCache.txt:CMAKE_BUILD_TYPE:STRING=Debug
./CMakeCache.txt:LIBS_BUILD_TYPE:UNINITIALIZED=Debug
./CMakeCache.txt:TOOLS_BUILD_TYPE:UNINITIALIZED=Debug

Probably something in CMakeLists.txt is overriding CMAKE_BUILD_TYPE.

Additionally adding to documentation how to build in debug mode would be useful for developers.

The following code:

#include <eosio/system.hpp>
#include <eosio/crypto_ext.hpp>

raise the following error:

include/eosiolib/core/eosio/crypto_ext.hpp:18:47: error: redefinition of 'capi_checksum256'
         struct __attribute__((aligned (16))) capi_checksum256 { uint8_t hash[32]; };
                                              
include/eosiolib/contracts/eosio/system.hpp:17:45: note: previous definition is here
      struct  __attribute__((aligned (16))) capi_checksum256 {

In CDTMacros.cmake the add_native_executable macro uses cmake_policy(SET CMP0002 OLD). Setting the OLD behavior for this policy has been deprecated in CMake which causes many warning when building CDT.

It is not clear to me why we are setting the OLD behavior for this policy, but we should figure out an alternative approach to avoid depending on deprecated behavior.

This issue encapsulates over all of the tasks that are required to complete the ANTLER Testing Environment
This task builds upon the work of #69

• Extend the native test framework to still allow for overriding the host functions, but have them default to extern 'C' so the shared object can link to those in the runner. #82
• Create a C and a C++ set of wrappers and abstractions for testing. #83
• Extend the runner to allow for another type of shared object (test object) to be loaded and run against the system. #84
• Extend the runner to accept a WASM file for the smart contract to 'test' against.
• Create a C and C++ set of wrappers for this higher level of testing (building on some of the primitives defined above). #85
• Updates for DUNE to use this new functionality.
• Update eos-system-contracts to use these new frameworks.

Empty https://github.com/AntelopeIO/cdt/wiki/Deprecations-and-Proposed-Deprecations-In-CDT-Software was created. Waiting for Bucky to provide details to fill up.

The varints unsigned_int & signed_int are just serialization wrappers for type uint32_t & int32_t. They should be compile-time constructible to be available for compile time constant expressions.

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 type std::map<time_point_sec, int64_t> and the second (rex_maturities) has type std::deque<std::pair<time_point_sec, int64_t>>. While it would be preferable to just use std::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 struct pair_time_point_sec_int64 is given by:

        {
            "name": "pair_time_point_sec_int64",
            "base": "",
            "fields": [
                {
                    "name": "key",
                    "type": "time_point_sec"
                },
                {
                    "name": "value",
                    "type": "int64"
                }
            ]
        },

When compiling with CDT v3.0.0-rc3, the ABI generated for rex_maturities has type B_pair_time_point_sec_int64_E[]) in which B_pair_time_point_sec_int64_E is a type alias that points to the same custom struct pair_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 becomes pair_time_point_sec_int64[] directly (without the type alias intermediary) and return_buckets is still a list of the custom struct (pair_time_point_sec_int64[]), however, now the ABI definition of pair_time_point_sec_int64 has changed to:

        {
            "name": "pair_time_point_sec_int64",
            "base": "",
            "fields": [
                {
                    "name": "first",
                    "type": "time_point_sec"
                },
                {
                    "name": "second",
                    "type": "int64"
                }
            ]
        },

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 the return_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 the return_buckets field and the ABI generated for the rex_maturities field is still B_pair_time_point_sec_int64_E[]. But now the ABI for the custom struct pair_time_point_sec_int64 uses first and second as opposed to key and value.

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 to first and value to second (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.

To make the release of 3.0 in time we had to cut the scope of the crypto extension wrappers for C++.

This work should include wrappers and datatypes for

alt_bn128_* functions to have more than just a basic C++ wrapper over those. I.e. create a point data types to take as input and as results.

use std::vector of pairs for alt_bn128_pair

Create bigint datatype for mod_exp.

And the same kind of thing for blake2_f by using std::vectors and std::string, etc.

In output_stream::push no check for buffer bounds can lead to buffer overrun.

I have large test sets where contract code invokes eosio::print* functions many times and the global std_out is not cleared through tests. Eventually the std_out overwrites std_err leading to segmentation fault.

This will build upon #65.

The tool should be extended to allow the end user to add, remove or update any dependencies of their project.

This tool should also be extended to pull in any dependencies that are listed for the project.

Given a project file the tool should produce a CMake project and CMakeLists.txt associated with it to be compiled for their project. For this first phase we can ignore dependencies.

Using the CMake that has been generated the tool should be able to build complex projects with multiple dependencies.

Extend the current 'native' testing framework in CDT to still allow for overriding of host functions, but have the default behavior use the wrapped host functions exposed by antler-run.

• Creation of the new tool antler-build
• CMake associated with the new binary and stub code for the tool
• Utilizing a consistent command line parser as the other tools

LLDB uses Python to extend its core functionality. We will create some simple functions to view table data and call actions.

For all newly created issues in the cdt repo, we'd like to

• Assign the "Team Backlog" project
• Assign the "triage" label

Example implemented for leap: https://github.com/AntelopeIO/leap/blob/main/.github/workflows/label_new_issues.yaml

Document crypto extension support in CDT along with examples.

• A new tool called antler-run will be created to run the smart contract WASM or native object.
• The CMake required to create the tool.
• Stub C++ code to create the tool.
• Consistent command line parser used in projects should be used.

Description of error:

When you run leap with the new cdt without enabling the crypto feature you get env.sha3 unresolveable, even when not using the feature.

Steps to reproduce:

Try and deploy a new cdt contract without enabling the crypto feature.

Desired behavior:

No error and when the feature is being used, a better error code perhaps that specifies the feature that needs to be enabled.

This task will be to create the C library to parse a project.yml file into some C structures and expose an API for working with project.yml files.

I am getting the following error when building for ubuntu 18 and compiling a contract.

⚡  EOSIO CONTRACT COMPILING

-- Configuring done
-- Generating done
-- Build files have been written to: /home/ubuntu/environment/ipfs-dapp-service/contracts/eos
⚫ Scanning dependencies of target ipfsconsumer
◼️ [ 11%] Creating directories for 'ipfsconsumer'
◼️ [ 22%] No download step for 'ipfsconsumer'
◼️ [ 33%] No patch step for 'ipfsconsumer'
◼️ [ 44%] No update step for 'ipfsconsumer'
◼️ [ 55%] Performing configure step for 'ipfsconsumer'
-- Setting up CDT Wasm Toolchain 3.0.0-rc2 at /usr
-- Setting up CDT Wasm Toolchain 3.0.0-rc2 at /usr
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ubuntu/environment/ipfs-dapp-service/contracts/eos/ipfsconsumer
◼️ [ 66%] Performing build step for 'ipfsconsumer'
⚫ Scanning dependencies of target ipfsconsumer
◼️ [ 50%] Building CXX object CMakeFiles/ipfsconsumer.dir/ipfsconsumer.cpp.obj
/usr/bin/cdt-cpp: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
◼️ make[6]: *** [CMakeFiles/ipfsconsumer.dir/ipfsconsumer.cpp.obj] Error 127
CMakeFiles/ipfsconsumer.dir/build.make:62: recipe for target 'CMakeFiles/ipfsconsumer.dir/ipfsconsumer.cpp.obj' failed
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/ipfsconsumer.dir/all' failed
Makefile:83: recipe for target 'all' failed
◼️ make[5]: *** [CMakeFiles/ipfsconsumer.dir/all] Error 2
◼️ make[4]: *** [all] Error 2
◼️ make[3]: *** [ipfsconsumer-prefix/src/ipfsconsumer-stamp/ipfsconsumer-build] Error 2
CMakeFiles/ipfsconsumer.dir/build.make:111: recipe for target 'ipfsconsumer-prefix/src/ipfsconsumer-stamp/ipfsconsumer-build' failed
◼️ make[2]: *** [CMakeFiles/ipfsconsumer.dir/all] Error 2
CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/ipfsconsumer.dir/all' failed
◼️ make[1]: *** [CMakeFiles/ipfsconsumer.dir/rule] Error 2
CMakeFiles/Makefile2:116: recipe for target 'CMakeFiles/ipfsconsumer.dir/rule' failed
Makefile:131: recipe for target 'ipfsconsumer' failed
◼️ make: *** [ipfsconsumer] Error 2
☹️ eos contracts compile failed, if you want to use docker add --docker=true

I built with:

git clone https://github.com/AntelopeIO/cdt
cd cdt/
git fetch
git checkout fix_nested_container
git log --name-status HEAD^..HEAD
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j $(nproc)
cd packages/
bash ./generate_package.sh deb ubuntu-18.04 amd64

Create new project with cdt-init:
$ cdt-init --project contract
Add an ricardian-clause contract file
$ echo "<h1 class="clause"> legalese </h1> text" > ./contract/ricardian/contract.clauses.md
Try to build contract
`
$ mkdir build
$ cd build
$ cmake ../contract/
$ VERBOSE=1 make -j1
.......
Re-run cmake no build system arguments
-- Setting up CDT Wasm Toolchain 3.0.1 at /usr
CMake Error at /usr/opt/cdt/3.0.1/lib/cmake/cdt/CDTMacros.cmake:17 (set_source_files_properties):
set_source_files_properties called with incorrect number of arguments.
Call Stack (most recent call first):
CMakeLists.txt:8 (target_ricardian_directory)

-- Configuring incomplete, errors occurred!
`

Much like how we build a few llvm/clang based tools in cdt, we will also go ahead and build lldb as part of the project.

In addition to loading the smart contract in question an additional input will be available to add integration test objects.

Description:

When running an action with the types seen below I get the following error Error: Unknown type: B_vector_int8_E. I'm also seeing a change in the ABI format which I've included below.

Example:

Before

        {
            "name": "pair_uint64_bytes",
            "base": "",
            "fields": [
                {
                    "name": "key",
                    "type": "uint64"
                },
                {
                    "name": "value",
                    "type": "bytes"
                }
            ]
        },

After

        {
            "name": "pair_uint64_B_vector_int8_E",
            "base": "",
            "fields": [
                {
                    "name": "key",
                    "type": "uint64"
                },
                {
                    "name": "value",
                    "type": "B_vector_int8_E"
                }
            ]
        },

Expected Behavior:

Trx should execute as it did previously. Perhaps the ABI type should also not be changed.

Steps to reproduce:

Install zeus and unbox ipfs-dapp-service box.

npm i -g @liquidapps/zeus-cmd
mkdir ipfs-dapp-service
cd ipfs-dapp-service
zeus box create
zeus unbox ipfs-dapp-service
# update CMake files in ./contracts/eos as needed to support new cdt
zeus compile # or cmake . && make in ./contracts/eos
zeus test ipfsconsumer --services ipfs --chain eos --single-chain

Overview:

I have an abi being compiled differently in 3.0.1 than in pre 3.0.0. This is the PR relating to the issue that changed this #34. There is no issue when I use 3.0.0.

This appears to be a break in backwards compatibility.

Pre 3.0.0 (I know it's pre 3.0.0 because I see the cmake file only supports eosio.cdt) I have this in the abi:

        {
            "name": "pair_uint64_bytes",
            "base": "",
            "fields": [
                {
                    "name": "key",
                    "type": "uint64"
                },
                {
                    "name": "value",
                    "type": "bytes"
                }
            ]
        },

get_filename_component(PROJ_NAME "${CMAKE_CURRENT_SOURCE_DIR}" NAME )
cmake_minimum_required(VERSION 3.5)
set(EOSIO_WASM_OLD_BEHAVIOR "Off")
project(${PROJ_NAME} VERSION 1.0.0)
if(EOSIO_CDT_ROOT STREQUAL "" OR NOT EOSIO_CDT_ROOT)
   find_package(eosio.cdt)
endif()
add_contract( ${PROJ_NAME} ${PROJ_NAME} ${PROJ_NAME}.cpp )
include_directories( ${PROJ_NAME} PUBLIC ./ )

In 3.0.1 I have:

        {
            "name": "pair_uint64_bytes",
            "base": "",
            "fields": [
                {
                    "name": "first",
                    "type": "uint64"
                },
                {
                    "name": "second",
                    "type": "bytes"
                }
            ]
        },

get_filename_component(PROJ_NAME "${CMAKE_CURRENT_SOURCE_DIR}" NAME )
cmake_minimum_required(VERSION 3.5)
project(${PROJ_NAME} VERSION 1.0.0)
set(EOSIO_WASM_OLD_BEHAVIOR "Off")

function(CheckHasModule Module)
  find_package(${Module} QUIET)
  if(NOT DEFINED ${Module}_DIR)
    set(HAS_MODULE_${Module} TRUE PARENT_SCOPE)
  elseif(${Module}_DIR)
    set(HAS_MODULE_${Module} TRUE PARENT_SCOPE)
  else()
    set(HAS_MODULE_${Module} FALSE PARENT_SCOPE)
  endif()
endfunction()

CheckHasModule(cdt)

if(HAS_MODULE_cdt)
   find_package(cdt)
else()
   find_package(eosio.cdt)
endif()
add_contract( ${PROJ_NAME} ${PROJ_NAME} ${PROJ_NAME}.cpp )
include_directories( ${PROJ_NAME} PUBLIC ./ )

And I receive the error:

Error: missing pair_uint64_bytes.first (type=uint64)

No code in the smart contract has changed between cdt versions.

Steps to recreate:

• install nodejs 16, can be done with nvm like here
• install zeus npm install -g @liquidapps/zeus-cmd
• install 3.0.1 cdt
• run mkdir ipfsconsumer; cd ipfsconsumer; zeus box create; zeus unbox ipfs-dapp-service; zeus test -c --services "ipfs" --single-chain --chain-type eos

Contract in question: https://github.com/liquidapps-io/zeus-sdk/blob/master/boxes/groups/services/ipfs-dapp-service/contracts/eos/ipfsconsumer/ipfsconsumer.cpp
Test failing: https://github.com/liquidapps-io/zeus-sdk/blob/master/boxes/groups/services/ipfs-dapp-service/test/ipfsconsumer.spec.js#L594

To swap between cdt versions in ./ipfs-dapp-service run

find ./contracts/eos/ -type d -name *prefix -prune -exec rm -rf {} \;
find ./contracts/eos/ -type d -name CMakeFiles -prune -exec rm -rf {} \;
find ./contracts/eos/ -type f -name 'CMakeCache.txt' -delete
find ./contracts/eos/ -type f -name 'Makefile' -delete
find ./contracts/eos/ -type f -name 'cmake_install.cmake' -delete

• update to 3.0.0 cdt
• re run the tests with zeus test -c --services "ipfs" --single-chain --chain-type eos

Clean up: EOSIO to Antelope

Clean up CDT repo of deprecated terms (e.g. EOSIO), broken links, obsolete content and code.

I'm getting another failing unit test with the latest CDT version for vRAM.

  15 passing (2m)
  1 failing

  1) IPFS Service Test Contract
       IPFS Load Manifest:
     Error: missing pair_uint64_bytes.first (type=uint64)
      at Object.serializeStruct [as serialize] (node_modules/eosjs/dist/eosjs-serialize.js:571:27)
      at Object.serializeArray [as serialize] (node_modules/eosjs/dist/eosjs-serialize.js:640:26)
      at Object.serializeStruct [as serialize] (node_modules/eosjs/dist/eosjs-serialize.js:564:28)
      at Object.serializeStruct [as serialize] (node_modules/eosjs/dist/eosjs-serialize.js:564:28)
      at serializeActionData (node_modules/eosjs/dist/eosjs-serialize.js:1041:12)
      at Object.serializeAction (node_modules/eosjs/dist/eosjs-serialize.js:1051:15)
      at Api.<anonymous> (node_modules/eosjs/dist/eosjs-api.js:278:71)
      at step (node_modules/eosjs/dist/eosjs-api.js:47:23)
      at Object.next (node_modules/eosjs/dist/eosjs-api.js:28:53)
      at fulfilled (node_modules/eosjs/dist/eosjs-api.js:19:58)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

Steps to reproduce:

Install zeus and unbox ipfs-dapp-service box.

npm i -g @liquidapps/zeus-cmd
mkdir ipfs-dapp-service
cd ipfs-dapp-service
zeus box create
zeus unbox ipfs-dapp-service
# update CMake files in ./contracts/eos as needed to support new cdt
zeus compile # or cmake . && make in ./contracts/eos
zeus test ipfsconsumer --services ipfs --chain eos --single-chain

See #15 for additional install instructions.

Last version this worked on was 3.0.0. Did not work on 3.0.1 with same error.

The following ticket (bug) has been closed despite it not even being resolved and it can still be reproduced in the latest 3.2.0. The bug completely prevents from uploading a contract. More info: EOSIO/eosio.cdt#280

Remove all references to Mandel or mandel from within the antelope-3.0 branch of cdt. The submodule repos referenced from the antelope-3.0 branch should not need any changes. There are mentions of mandel in cdt-llvm which are in reference to Mandelbrot and not the Mandel used in the context of EOSIO; these should not be touched.

Also, update the URLs referencing eosnetworkfoundation org repos to use the corresponding ones in the AntelopeIO organization.

After AntelopeIO/leap#1 has been completed, ensure that you can still build CDT with integration tests (has dependency on Leap/EOSIO). In addition, ensure you can still build https://github.com/eosnetworkfoundation/mandel-contracts (with tests enabled) using the antelope-3.1 branch of Leap and the antelope-3.0 branch of CDT. It shouldn't be necessary to change mandel-contracts code to get it to work.

It is acceptable to still have referenced to EOSIO in both Leap and CDT (even for package names and CMake files) even after this issue and AntelopeIO/leap#1 are completed.

Looks like the arm64 deb in release 3.0.1 is corrupted.

How to recreate the error:

1. Create a dockerfile

FROM ubuntu:18.04
RUN apt-get update -y && apt-get install -y build-essential git curl wget nano g++ clang-9 && wget https://github.com/AntelopeIO/cdt/releases/download/v3.0.1/cdt_3.0.1_arm64.deb && apt-get install -y ./cdt_3.0.1_arm64.deb

2. Build the dockerfile

docker build -t newantelopesdk:latest .

Error:

#6 13.15 Preparing to unpack /cdt_3.0.1_arm64.deb ...
#6 13.15 Unpacking cdt (3.0.1-1) ...
#6 14.70 dpkg-deb (subprocess): cannot copy archive member from '/cdt_3.0.1_arm64.deb' to decompressor pipe: unexpected end of file or stream
#6 14.71 dpkg-deb (subprocess): decompressing archive member: lzma error: unexpected end of input
#6 14.71 dpkg-deb: error: <decompress> subprocess returned error exit status 2
#6 14.71 dpkg: error processing archive /cdt_3.0.1_arm64.deb (--unpack):
#6 14.71  cannot copy extracted data for './usr/opt/cdt/3.0.1/bin/clang-9' to '/usr/opt/cdt/3.0.1/bin/clang-9.dpkg-new': unexpected end of file or stream
#6 14.74 Errors were encountered while processing:
#6 14.74  /cdt_3.0.1_arm64.deb
#6 14.75 E: Sub-process /usr/bin/dpkg returned an error code (1) #

Expected:
Successful installation of CDT to a docker container.

This issue encapsulates over all of the tasks that are required to complete the ANTLER Debug Environment

By building upon our native test framework we have in CDT, we will create a new way to debug smart contracts in a few ways. As we move into the future and move to technologies like NatiVM, then this type of system will be even better fitting.

• Compile smart contracts as a 'shared object' to be loaded by the 'runner' (extending the framework that exists with the native compilation system) #78
• Build the runner (functionality and API described in the ANTLER Project Design document). #79
• Build the leap plugin to expose host functions as an API endpoint for the runner to utilize and to 'pause' and direct control flow for a designated action on an account.
• Add LLDB as a build dependency of CDT to be used by end-users to debug their code. #80
• Add LLDB python module for smart contract dev usage. #81
• Extend DUNE to use this new functionality.

Extend and modify the current way that native test compilation is done to build as a shared object and not as an executable.

To aid in better support for smart contract APIs externally and to move to a more language agnostic approach of how we handle smart contract APIs.
The system should move to using Google Protobufs to define actions. This allows all languages we want to support in the future to have the same method of defining the API schemas, as they write a protobuf file and generate the code, as opposed to take C++ and generate JSON. ABI generation has been error-prone since its inception because we are trying to shoe-horn a massive complex language into JSON.

As we move into the future with features like read-only actions and transactions, the proposed path is to only have 'actions' as the API, meaning that database accesses would be done via an action, and retrieving Ricardian contracts would be done via an action. This allows for smart contracts to extend the API and conventions they use without having to update a static format that really shouldn't be defining those things to begin with.

Given a testing environment like 'catch2' as the basis, we will create a set of abstractions to allow a test to create a node, set contracts, push actions, check the results of those actions.

For the first version of this framework it will be pretty small, and as we get input from developers we would prioritize that as needed.

This issue encapsulates over all of the tasks that are required to complete the ANTLER Project Management System

• Write specification and initial C YAML parser (https://github.com/yaml/libyaml) to parse the project.yml files to C structures. #63
• Write the C++ abstraction over the C library for handling the project.yml files. #64
• Create a new tool (antler-pack antler-proj):
  • Functionality to create new projects via --init command with the described specification in the ANTLER Project Design document. #65
  • Add, remove, and update dependencies of a project. #66
  • Grab any dependencies that are listed in the project.yml. #66
  • Check that a given project (git project) is a valid ANTLER project, checking against the convention and specification from the design document. #67
• Update DUNE to wrap over the new functionality.
• Create symlink from antler-pack to cdt-pack for consistency for the interim.

Building upon #73 we will now create the CMake to link to and build the dependencies of the project.

The branch "docs/cdt_md_fixes" needs to be moved over from eosnetworkfoundation

SyntaxError: /Users/eric/eosnetworkfoundation/build_root/devdocs/cdt/05_features/30_binary-extension.md: Unterminated JSX contents. (610:16)
  608 | <li parentName="ul">{`wrap the type using an `}<inlineCode parentName="li">{`eosio::binary_extension`}</inlineCode>{` type.`}</li>
  609 | </ul>
> 610 |     </MDXLayout>
      |                 ^
  611 |   )
  612 | };
  613 | MDXContent.isMDXComponent = true
SyntaxError: /Users/eric/eosnetworkfoundation/build_root/devdocs/cdt/09_tutorials/01_binary-extension.md: Unterminated JSX contents. (666:16)
  664 | <h2 {...{"id":"abi-binary-format"}}>{`ABI Binary format`}</h2>
  665 | <p><inlineCode parentName="p">{`$`}</inlineCode>{` can be included in type strings. No other changes.`}</p>
> 666 |     </MDXLayout>
      |                 ^
  667 |   )
  668 | };
  669 | MDXContent.isMDXComponent = true

Description:

I am trying to use the new k1_recover intrinsic and I am getting error: use of undeclared identifier 'k1_recover'.

Expected Behavior:

Should be able to access the intrinsic.

I noticed that the rest of the functions listed here intrinsics.cpp did not work with the exception of sha3 as it's defined in crypto.hpp.

Steps to Reproduce:

nodeos --version
v3.1.0-rc4

cdt-cpp -v
clang version 9.0.1 (https://github.com/AntelopeIO/cdt-clang 1baf03bbaa65a20b3de00fede1bc039666006c8c) (https://github.com/AntelopeIO/cdt-llvm 6a0991f5118ef11008c88c3f5e6ce2692642ffb8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/anon/Workspaces/example-eosio-coinbase-price-feed
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

cmake --version
cmake version 3.22.1

make --version
GNU Make 4.3

#include <eosio/eosio.hpp>
#include <eosio/crypto.hpp>

using namespace eosio;
using namespace std;

CONTRACT oracle : public eosio::contract {
  using contract::contract;
  public:

  [[eosio::action]] void test() {
    k1_recover();
  }
};

Building on #63, this task is to create the C++ wrapper over those functions to work with the project.yml files.

Using the testing environment project, extend the build system tool to build tests as part of the project.

The tool should be created to use the #64 library.

The functionality at the phase should be able to read and write a project.yml file.
Generate a new project given some inputs from the user and create a project.yml, specified directory structure and initial files.

I have contracts which use name as the type of the primary key in several of their tables. This exact use case is historically the cause for the name type to have been envisioned and created in the first place. Even the EOSIO core contracts made extensive use of this pattern, albeit, by bending over backward to protect the CDT templates from the true type of the key...

Well that's just a bunch of silliness! Updating the templates to handle name typed primary keys is trivial, so why not just solve the problem once and have it go away, rather than adding complexity to every other contract?

Extending the set of primitives we have available for testing with some smart contract focused functionality and macros.

Request: Could we please try to do versioning of CDT that matches the versions of antelope contracts?

For example a CDT 2.0.0 should work on all antelope 2.x.x contracts and vice-versa.

Currently, switching and monitoring CDT versions is nightmarish.