Repository navigation
Memory incoherence when using --path #2888
Description
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
Activity
amoffat commentedon Nov 23, 2024
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.
CountBleck commentedon Nov 23, 2024
My initial suspicion is that the same file is read and parsed twice, with different internal names...
amoffat commentedon Nov 23, 2024
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?CountBleck commentedon Nov 23, 2024
Entrypoints are compiled together...I don't think they affect whether this bug occurs.
CountBleck commentedon Dec 17, 2024
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 theutils/moduleimport.amoffat commentedon Dec 17, 2024
Is there a way to use
--path(so I can use non-relative imports) and compile thelib/utils/module.tswithout including it as an entrypoint?CountBleck commentedon Dec 17, 2024
Have you tried playing around with
--lib?