Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(c-api) Update wasm-c-api repository #1699

Merged
merged 30 commits into from
Oct 19, 2020

Conversation

Hywan
Copy link
Contributor

@Hywan Hywan commented Oct 9, 2020

This change is important because wasm.h contains new functions, like
wasm_name_new_from_string_nt, which are useful for the Go
implementation.

This change is important because `wasm.h` contains new functions, like
`wasm_name_new_from_string_nt`, which are useful for the Go
implementation.
Copy link
Contributor

@MarkMcCaskey MarkMcCaskey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me...

we may need to update some of our own tests as well if any behavior has changed

@@ -94,6 +94,7 @@ Currently, known implementations of this API are included in
* V8 natively (both C and C++)
* Wabt (only C?)
* Wasmtime (only C?)
* [Wasmer](https://github.com/wasmerio/wasmer/tree/master/lib/c-api) (only C, C++ coming soon)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to this PR but I want to put this idea out into the universe before I forget:

When doing the release we have c-api/docs/deprecated and we currently package that as README.md in the C API that we distribute...

We should probably make a note that it's the deprecated API and file an issue to start building docs for Wasmer with the Wasm C API!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Completely!

Copy link
Contributor Author

@Hywan Hywan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to the updates required by the changes in wasm.h, I've updated wasi/mod.rs (the wasm_get_imports function) to use a wasm_extern_vec_t, so that it matches the definition of wasm_instance_new, which is simpler and more consistent.

Comment on lines 416 to +419
typedef own wasm_trap_t* (*wasm_func_callback_t)(
const wasm_val_t args[], wasm_val_t results[]);
const wasm_val_vec_t* args, own wasm_val_vec_t* results);
typedef own wasm_trap_t* (*wasm_func_callback_with_env_t)(
void* env, const wasm_val_t args[], wasm_val_t results[]);
void* env, const wasm_val_vec_t* args, wasm_val_vec_t* results);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust implementation updated ✅

Comment on lines 431 to +432
WASM_API_EXTERN own wasm_trap_t* wasm_func_call(
const wasm_func_t*, const wasm_val_t args[], wasm_val_t results[]);
const wasm_func_t*, const wasm_val_vec_t* args, wasm_val_vec_t* results);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust implementation updated ✅

Comment on lines 518 to 521
WASM_API_EXTERN own wasm_instance_t* wasm_instance_new(
wasm_store_t*, const wasm_module_t*, const wasm_extern_t* const imports[],
wasm_store_t*, const wasm_module_t*, const wasm_extern_vec_t* imports,
own wasm_trap_t**
);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust implementation updated ✅

@Hywan
Copy link
Contributor Author

Hywan commented Oct 12, 2020

@MarkMcCaskey We must be very careful with the last update of wasm.h. The following code is now a common pattern:

wasm_val_vec_t args = WASM_EMPTY_VEC;

where WASM_EMPTY_VEC is a new macro such as:

#define WASM_EMPTY_VEC {0, NULL}

So basically, it creates a wasm_val_vec_t { .size = 0, .data = NULL }.

Why is it dangerous for us? Because our into_slice implementation for wasm_$name_vec_t returns None if data is null. Yup. So an empty array passed to into_slice will return None.

I don't know if we should change the behavior of into_slice. Maybe we should. At least to return an empty static slice ([])? Thoughts?

@Hywan
Copy link
Contributor Author

Hywan commented Oct 12, 2020

All wasm-c-api examples/tests are green. Let's migrate our own tests.

@Hywan
Copy link
Contributor Author

Hywan commented Oct 12, 2020

All good. All wasmer_c_api tests are green. Let's see how it impacts all the project.

@Hywan
Copy link
Contributor Author

Hywan commented Oct 12, 2020

bors try

bors bot added a commit that referenced this pull request Oct 12, 2020
@bors
Copy link
Contributor

bors bot commented Oct 12, 2020

try

Build failed:


let _traps = callback(*env, processed_args.as_ptr(), results.as_mut_ptr());
let _traps = callback(*env, &processed_args, &mut results);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not be the same, we should be careful of the difference between fat pointers and thin pointers.

as_ptr and as_mut_ptr generally pass word sized pointers, references to slices are double words and references to vecs are different data entirely

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

processed_args and results are now of kind wasm_val_vec_t. I believe it is safe to use & in this case.

lib/c-api/src/wasm_c_api/externals/function.rs Outdated Show resolved Hide resolved
lib/c-api/src/wasm_c_api/instance.rs Show resolved Hide resolved
@Hywan
Copy link
Contributor Author

Hywan commented Oct 16, 2020

bors try

bors bot added a commit that referenced this pull request Oct 16, 2020
@bors
Copy link
Contributor

bors bot commented Oct 16, 2020

try

Build failed:

@Hywan
Copy link
Contributor Author

Hywan commented Oct 16, 2020

bors try

bors bot added a commit that referenced this pull request Oct 16, 2020
@bors
Copy link
Contributor

bors bot commented Oct 16, 2020

try

Build failed:

@Hywan
Copy link
Contributor Author

Hywan commented Oct 16, 2020

bors try

bors bot added a commit that referenced this pull request Oct 16, 2020
Windows will raise a warning because `clang++` is used to handle C
code, so I previously add `-x c` to tell `clang++` to handle code as C
code. Bbut if code is treated as C, it will fail because
`static_assert` is not available for C on Windows.

So let's live with the warning.
@Hywan
Copy link
Contributor Author

Hywan commented Oct 16, 2020

bors try-

@Hywan
Copy link
Contributor Author

Hywan commented Oct 16, 2020

bors try

bors bot added a commit that referenced this pull request Oct 16, 2020
@bors
Copy link
Contributor

bors bot commented Oct 16, 2020

try

Build failed:

@MarkMcCaskey
Copy link
Contributor

bors try

bors bot added a commit that referenced this pull request Oct 17, 2020
@bors
Copy link
Contributor

bors bot commented Oct 17, 2020

@Hywan
Copy link
Contributor Author

Hywan commented Oct 19, 2020

bors r+

@bors
Copy link
Contributor

bors bot commented Oct 19, 2020

@bors bors bot merged commit aeea0d6 into wasmerio:master Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants