You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
when you call grain a.gr instead of getting the expected
a
b
c
in the console you get
b
c
It seems like we might be prematurely optimizing modules because when I add an export and use that export the program does whats expected. I think we need to consider side effects in tree shaking.
The text was updated successfully, but these errors were encountered:
I was looking into this a bit the other day, I think this is a problem in the linker, where we don't currently link with a module if there is no wasm import, and as we are not using anything from the module we dont have any imports to it.
I think the best way to fix this would be to read the imports from the cmi, or if we want an approach that makes the intermediate wasm slightly more correct, we could import the _start function and call it in the main modules _start function, though its important to keep in mind if we use the second approach that we cant just reoutput the _start section we would need to deduplicate and properly order the _start calls. I am a fan of method two as it works better with dynamic linking which we no longer support but its cool to leave the option open.
If you have module
b
with the contents:and module
a
with the contents:when you call
grain a.gr
instead of getting the expectedin the console you get
It seems like we might be prematurely optimizing modules because when I add an export and use that export the program does whats expected. I think we need to consider side effects in tree shaking.
The text was updated successfully, but these errors were encountered: