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

WASM Support #96

Closed
SilentCicero opened this issue Nov 6, 2020 · 5 comments · Fixed by #390
Closed

WASM Support #96

SilentCicero opened this issue Nov 6, 2020 · 5 comments · Fixed by #390
Labels
enhancement New feature or request

Comments

@SilentCicero
Copy link

What is the WASM support status on this lib?

What needs to be done?

@gakonst
Copy link
Owner

gakonst commented Dec 24, 2020

Probably hard to get it working with async-trait.

wasm-pack inside ethers-providers has this error:
image

Could maybe be solved by switching our async-traits to not be Send, but that would mean we can't spawn them, which is not ideal

@gakonst gakonst added the enhancement New feature or request label Dec 24, 2020
@gakonst gakonst changed the title WASM Support Status WASM Support Dec 24, 2020
@gakonst gakonst mentioned this issue Dec 25, 2020
@mattsse
Copy link
Collaborator

mattsse commented May 17, 2021

@gakonst following up on this, because I just saw ethabi no_std https://github.com/darwinia-network/ethabi/tree/xavier-no-std

Would it actually be worth it to support wasm/no_std? I can't really think of a good use case...

That being said, I think we can get the problems in providers resolved for no_std

@gakonst
Copy link
Owner

gakonst commented May 17, 2021

I don't have a great use-case in mind either, and candidly, feels like doing async stuff over wasm/ffi would be a big pain :P I think it'd be great if the crate is in a state where it compiles with no_std/wasm-pack, so that if anybody ever wanted to build things that way, they'd be able to.

@prestwich
Copy link
Collaborator

async in wasm is not as bad as it seems. You can convert to/from promises relatively easily. To be honest, my approach would be to ensure that the wasm32-unknown-unknown target compiles, but not provide any official wasm interface. That gives people the option to use it, with very little work up front

@gakonst
Copy link
Owner

gakonst commented May 17, 2021

Agreed, exactly what I meant above

@mattsse mattsse mentioned this issue Aug 18, 2021
3 tasks
meetmangukiya pushed a commit to meetmangukiya/ethers-rs that referenced this issue Mar 21, 2022
* chore: update cargo lock

* test: add contract emitting all logs we want to check

* feat: add logic for finding debug logs and printing them

* feat(runner): add logs to the test result and print at cli

* feat(evm): require evm impls to return logs at end of call

* chore: empty debug logs vector for evmodin

* feat(evm): raw call returns executor log

non-cheatcode execcutors return empty

* feat(evm): move `logs` call to trait impl

* chore: adjust tests for new param

* feat(evm): return logs from setup fn call

* feat(sputnik): clear evm logs after call execution

* feat(runner): merge setup + normal execution logs

* feat(cli): make cli log output match upstream

* feat(evm): return logs from deployment call so we log constructor logs

* feat(runner): merge constructor logs with the rest

* chore: adjust tests for new params

* test: use logs from evm.call instead of manually querying them
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants