-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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] Revert back to eval in wasm InvokeJS with modularization support . #61212
Conversation
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsWrap code to evaluate in a function with MONO, BINDING, INTERNAL Fixes #61192.
|
Tests failed with |
@maraf if you want to run the bindings tests specifically when iterating on APIs like this, this will run a sizable (but not complete!) chunk of them:
(replace the folder with the location of your checkout) |
Also, please add the test case which @kg mentioned in the issue. |
Windows incantation for the test same is
|
Wrap code to evaluate in a function with MONO, BINDING, INTERNAL and module as local variables. Added tests for running js expressions. Co-authored-by: Pavel Savara <[email protected]>
3de1205
to
c952f06
Compare
Can you add a test that verifies the eval is not happening in global scope? I think it would invoke some JS like: (test_local_variable_name = 5, globalThis.test_local_variable_name) InvokeJS on that will return 5 in global scope, and return undefined otherwise |
@kg Was it intended to use an undeclared variable? As we are in the strict mode, one can't use undeclared variable. I can add a test with variable declaration, something like
|
Add test ensuring global scope separation.
If the only motivation is the compile warning, we can suppress the warning. |
I don't see a good reason for using function instance.
|
Wrap code to evaluate in a function with MONO, BINDING, INTERNAL
and module as local variables. Than use
eval
.Added tests for invoking js expressions.
Fixes #61192.