Support async read callbacks.

[MicahZoltu]

Ideally using modern techniques (meaning promises). At the moment, the readCallback is expected to return a result synchronously. This is impossible to do in the browser and against best practices in node. This function should instead be expected to return a Promise<string> and reject the promise with an Error on failure.

[chriseth]

This is currently not fixable due to the use of emscripten. They offer some ways to work around the problem, but as far as I know, it does not work properly yet.

[xpepermint]

Any progress on this?

[matheusaaguiar]

Closing for inactivity.

[talentlessguy]

Reopen please, I'm implementing Deno bindings for solc and there's no way for supporting URL imports because fetch is asynchronous

[matheusaaguiar]

Hi @talentlessguy !
When I closed the issue, it was only because of years of inactivity.
Coming back to it now, it seems that it would be necessary to generate separate binary versions with the async support (However, I am no expert in JS/Emscripten, so please correct me if I'm mistaken).
That being the case, at the moment, we are not planning on working on such task.

ps: Nice work with the solidity bindings for deno!

[talentlessguy]

@matheusaaguiar as far as I saw on Google, Asyncify is built-in to Emscripten: https://emscripten.org/docs/porting/asyncify.html

emscripten-core/emscripten#14728

Maybe solc binaries could come with async support without making a separate sync binary, just ship async by default

p.s. thank you!

[matheusaaguiar]

@talentlessguy It seems that could be the case. Nevertheless, we still would need to do some work, as, for example, maintaining compatibility in solc-js, including old binaries to be available for source verification. Essentially, that is undesired work that we are not planning in the near future.
However, we welcome discussions and proofs of the concept in the forum, which may help if we eventually decide going this route sometime in the future.