builtin,v.gen.wasm: support -b wasm -d no_imports

[Xyndra]

All currently existing WASM targets use some kind of imports by default. This one doesn't.

[spytheman]

I do not get it.

Why add another mode?

Your explanation that:

All currently existing WASM targets use some kind of imports by default. This one doesn't.

Does not make sense to me, because rg 'import ' vlib/builtin/wasm/ returns 0 results already.

[spytheman]

Can you please describe in more details, the use case/workflow, that is enabled by this, that was not available before, but will be in this PR?

[Xyndra]

I did not mean v imports, I meant WASM imports (the imports that the binary does). Browsers mode takes two functions:

fn JS.__panic_abort(&u8, int)
fn JS.__writeln(&u8, int)

Wasi also takes some:

@[wasm_import_namespace: 'wasi_snapshot_preview1']
fn WASM.fd_write(fd FileDesc, iovs &CIOVec, iovs_len usize, retptr &usize) Errno

@[wasm_import_namespace: 'wasi_snapshot_preview1']
@[noreturn]
fn WASM.proc_exit(rval int)

[Xyndra]

If you have a custom WASM runtime and can't easily offer the required functions (I am in that situation right now) this is very useful and there aren't any ways to do that at the moment because the requirements are inside the builtins and therefore not removable

[spytheman]

Why not use another mechanism for customization, for example -d no_whatever, and then @[if !no_whatever] fn ..., to allow for those usecases, which will only need local changes in a few places, rather than a whole new mode, that will have to be maintained, explained and documented separately from the other ones?

I am afraid, that we already do have too many wasm related modes, and adding more does not look to me like a good idea at all, from a maintenance point of view.

[Xyndra]

note that I also made custom comptime flags work with this

[Xyndra]

CI seems to have failed during installing dependencies (?), doesn't seem like V even ran

[spytheman]

Excellent work.

[spytheman]

Yes, the CI error is unrelated, and already fixed on master.