fix(c-api) Call wasi_env_delete manually

[Hywan]

Description

wasi_get_imports isn't taking ownership of wasi_env_t (despites
what is written in the documentation). And it must not take ownership
of it, since one could use it with the wasi_env_read_stdout &
sibling functions after having called wasi_get_imports.

Consequently, this patch calls wasi_env_delete to avoid leaking
memory.

Review

• Add a short description of the the change to the CHANGELOG.md file

[MarkMcCaskey]

Posted on Slack, but I think this is not symmetric with what we do in Rust and that the wasi_env_t is invalid so it's a bit odd to require manually deleting it in my opinion

[Hywan]

We don't take ownership of wasi_env_t. Just a reference:

wasmer/lib/c-api/src/wasm_c_api/wasi/mod.rs

Lines 536 to 542 in 3ed1e47

	#[no_mangle]
	pub unsafe extern "C" fn wasi_get_imports(
	store: Option<&wasm_store_t>,
	module: Option<&wasm_module_t>,
	wasi_env: Option<&wasi_env_t>,
	imports: &mut wasm_extern_vec_t,
	) -> bool {

And we just clone the inner value:

wasmer/lib/c-api/src/wasm_c_api/wasi/mod.rs

Line 564 in 3ed1e47

let import_object = generate_import_object_from_env(store, wasi_env.inner.clone(), version);

So WasiEnv is still available and fully working :-).

[MarkMcCaskey]

Alright, if it works then maybe that's a feature. The docs on the wasi_env_t type itself might need to be updated, I suspect they probably say that it does not need to be deleted.

[Hywan]

Documentation has already been updated for wasi_get_imports and wasi_get_unordered_imports.

[Hywan]

bors r+

[bors]

Build failed:

• Test on linux-aarch64

[Hywan]

I believe these is something bigger happening here. cc @MarkMcCaskey

[Hywan]

bors r+

[bors]

Build succeeded:

• Audit
• Code lint
• Test cross-compile on linux
• Test cross-compile on macos
• Test on linux-aarch64
• Test on linux-x64
• Test on macos-x64
• Test on windows-x64