We used to have separate Call/CallImport in the IR, due to an ancient binaryen implementation detail, but we also handle CallImport a bit differently (CallImport targets not taken into account by gc-sections). This gets in our way of emitting objects compatible with C/C++ linking convention, thus this PR.
Drop callHint and handleCCall. It's a silly hack to workaround silly C imports that drop the results.
Drop anything CallImport related, calls to internal & imported functions are treated in a unified namespace, exactly the way wasm does it.
Make the linker complain loudly at link-time about missing functions.
We used to have separate
Call/CallImportin the IR, due to an ancientbinaryenimplementation detail, but we also handleCallImporta bit differently (CallImporttargets not taken into account by gc-sections). This gets in our way of emitting objects compatible with C/C++ linking convention, thus this PR.callHintandhandleCCall. It's a silly hack to workaround silly C imports that drop the results.CallImportrelated, calls to internal & imported functions are treated in a unified namespace, exactly the way wasm does it.