Repository navigation
ctor-eval crashes when the same name is imported twice #8138
Description
Activity
Oh interesting, especially the part about importing the same name multiple times. Usually a function cannot have type
unreachable, and I wouldn't be surprised if that causes some assertions to fail somewhere, but maybe it would be ok in this special case.The rollback #8137 partially fixed this, but ctor-eval still fails if we happen to import the same name twice from a module named
env(because we still stub out the specialenvmodule):(module (import "env" "global" (global $global i32)) (import "env" "global" (global $global1 i32)) (func $foo (result i32) (i32.const 1) ) (export "foo" (func $foo)) )
python3 check.py ctor-eval --filter='*imports*' ninja: no work to do. [ checking wasm-ctor-eval... ] .. imports.wast executing: /usr/local/google/home/stevenfont/code/binaryen/bin/wasm-ctor-eval /usr/local/google/home/stevenfont/code/binaryen/test/ctor-eval/imports.wast -all -o a.wat -S --ctors foo Fatal: Module::addExport: global already exists Traceback (most recent call last): File "/usr/local/google/home/stevenfont/code/binaryen/check.py", line 436, in <module> sys.exit(main()) ~~~~^^ File "/usr/local/google/home/stevenfont/code/binaryen/check.py", line 419, in main TEST_SUITES[test]() ~~~~~~~~~~~~~~~~~^^ File "/usr/local/google/home/stevenfont/code/binaryen/check.py", line 121, in run_ctor_eval_tests support.run_command(cmd) ~~~~~~~~~~~~~~~~~~~^^^^^ File "/usr/local/google/home/stevenfont/code/binaryen/scripts/test/support.py", line 227, in run_command raise Exception(f"run_command `{' '.join(cmd)}` failed ({code}) {err or ''}") Exception: run_command `/usr/local/google/home/stevenfont/code/binaryen/bin/wasm-ctor-eval /usr/local/google/home/stevenfont/code/binaryen/test/ctor-eval/imports.wast -all -o a.wat -S --ctors foo` failed (1)
I'm changing the code to avoid generating stub modules and instead ignore imports and stop evaluation when we try to access any imported name.
- linked a pull request that will close this issueRevert "Stub out all imports in ctor-eval" #8137
on Dec 18, 2025 - added a parent issue
on Jan 15, 2026
Metadata
Metadata
Assignees
Labels
No labels
#8115 (comment)
Caused by #8115. We should create a stub only once for each qualified name. Also, if a name is imported multiple times with different types, we can try to make a stub with a common subtype that allows both imports to work (e.g. unreachable for functions since stubs can't be called anyway).