assemblyscript
assemblyscript copied to clipboard
AssemblyScript
Memory incoherence when using --path
Bug description
If asc is used to compile multiple files, and one of those files is resolved via --path, then memory set in that file is not persisted. If --path is not used, the memory persists.
Steps to reproduce
index.html
<!DOCTYPE html>
<html>
<body>
<script type="module">
import { printThing, adjustThing } from "./main.js";
printThing();
adjustThing();
printThing();
</script>
</body>
</html>
main.ts
import { thing } from "utils/module";
export function printThing(): void {
console.log(`Thing value is ${thing.value}`);
}
lib/utils/types.ts
export class Thing {
value: i32 = 0;
}
lib/utils/module.ts
import { Thing } from "./types";
export const thing = new Thing();
thing.value = 123;
export function adjustThing(): void {
thing.value = 456;
}
Compile with
asc main.ts lib/utils/module.ts -o main.wasm --bindings esm --path lib
Run npx http-server
Open http://localhost:8080 and open the debug console.
The output should be:
Thing value is 123
Thing value is 123
This shows that the memory is not being set correctly.
Now to prove it is a --path issue, we will use relative imports, instead of path imports. Change main.ts to:
import { thing } from "./lib/utils/module";
export function printThing(): void {
console.log(`Thing value is ${thing.value}`);
}
Compile with
asc main.ts lib/utils/module.ts -o main.wasm --bindings esm
Visit in the browser (you may need to hard refresh). The output will be
Thing value is 123
Thing value is 456
This shows that the memory is being set correctly.
AssemblyScript version
0.27.31
Some more context:
I am trying to build a library that exposes some standard functions to the javascript host. However, because the functions exported in the library cannot manipulate any state that the main program has access to, they aren't useful.
My initial suspicion is that the same file is read and parsed twice, with different internal names...
My initial suspicion is that the same file is read and parsed twice, with different internal names...
Could it also be related to multiple entrypoints? In the first example (the broken one), I'm compiling two files with asc, and wouldn't those be considered separate entrypoints? In the second example, the first entrypoint is including the second entrypoint, so there's only one entrypoint. Are entrypoints separated in memory?
Entrypoints are compiled together...I don't think they affect whether this bug occurs.
On second thought, it looks like the cause is the second entry point, because you specify lib/utils/module.ts, which will resolve to a different internal name than that of the utils/module import.
Is there a way to use --path (so I can use non-relative imports) and compile the lib/utils/module.ts without including it as an entrypoint?