ewasm/ewasm-rust-api

Ewasm API for Rust

ewasm-rust-api's Issues

Implement "primitive allocator" which never frees

This is (probably) useful for precompiles.

Turn ewasm_api into a trait

And provide two implementations:

• native
• scaffolded (* maybe look for a better name)

The native one wraps around the C functions, while the scaffolded can be used for testing.

Add a set of helpers to acquire "entire" external data

This applies to calldata, code, externalCode, returndata.

I propose to have calldata_acquire, etc., which returns the entire available content.

Use no_std

Building binaries with funcs that return stdlib structs get really big, really fast.

Alternatively, we can either use pwasm's lib or write something similar for our purpose.
edit: and use a smaller allocator

consider adding a `main` function to `src\main.rs`

use ewasm_api::prelude::*;

fn entry() {
let a: Hash = block_hash(1);
finish_data(&a.bytes);
}

ewasm_entry_point!(entry);

error[E0601]: main function not found in crate myrust
|
= note: consider adding a main function to src\main.rs

error: aborting due to previous error

For more information about this error, try rustc --explain E0601.

Split log into log0/log1/log2/log3/log4

Create a macro for the entry point

Maybe #5 will solve this or we could iteratively add smaller features.

The suggestion is that we add a macro, which generates the right signature (main()) as a C function on the wasm32 target and generates a stub or a warning/error on other targets.

Such as:

ewasm!({
  ewasm_api::abort()
})

eei return: Trap condition: unreachable

Getting error: Trap condition: unreachable

To compare, I imported the return function manually and tried to return the same data, while calling the manually imported function the test pass without errors, I realized the only difference between the manually imported function and the ewasm-rust-api function is that ewasm-api function specifies that the function never returns (using return type -> !).

ewasm-rust-api/src/lib.rs

Line 8 in 30112f5

fn ethereum_return(dataOffset: *const u32, length: u32) -> !;

Introduce higher level data types

For the types:

• Address (160 bit)
• EtherValue (128 bit)
• StorageKey (256 bit)
• StorageValue (256 bit)
• Hash (256 bit)

It should not pull in any big dependency and there's no need to have an operators on these, only to wrap the underlying data type and expose some basic traits (as_slice, to_vec).

Write tests for the API functions

Rust makes this super easy using cargo test.

Turn the debug feature into a macro

From #58:

• remove the debug feature
• build it in debug mode, but not in release mode
• turn the functions into macros, which turn into nops in release mode

Add rustdoc to type aliases

See #25 (comment)

Publish documentation on gh-pages using circleci

Documentation

Documentation can be written and automatically generated using cargo doc. It is handled in-source using triple-slash comments, for example:

/// this trait does trait stuff
Would be helpful to document this for contract devs.

Cleaning up "features"

Right now we have:

• std/no_std
• wee_alloc/qimalloc/stdalloc
• one feature for each optional EEI: debug, experimental, bignum, eth2 (these would be merged into master once stable)

This is spawning this build hell as seen in #56.

Perhaps bignum could go under experimental. With time as these features mature, they wouldn't need to be conditionally enabled.

Maybe debug doesn't even need to be a feature, just made available. Idea by @jakelang to only enable the debug module when compiling in debug mode. Extending on that: how about making them macros which are compiled to nop in release mode?

Use wee_alloc by default

Apparently since 1.30 it works with stable.