Not understandable fatal error from `asc`.

[maxime-petitjean]

I have this strange error from asc:

Fatal: Module::addExport: apply0<i16>> already exists

Steps to reproduce

Run this command line:

asc foo.ts bar.ts apply.ts --textFile module.wat

with these files:

• apply.ts

export class apply0<ReturnType, Runner0> {
  execute(typeId: i32): ReturnType {
    const runner = instantiate<Runner0>();

    if (typeId == 0) return runner.execute<ReturnType, i16>();
    if (typeId == 1) return runner.execute<ReturnType, i32>();
    if (typeId == 2) return runner.execute<ReturnType, i64>();

    throw new Error("Unknown typeId.");
  }
}

export class apply1<ReturnType, Runner1> {
  execute<Arg1Type>(typeId: i32, arg1: Arg1Type): ReturnType {
    const runner = instantiate<Runner1>();

    if (typeId == 0) return runner.execute<ReturnType, i16>(arg1);
    if (typeId == 1) return runner.execute<ReturnType, i32>(arg1);
    if (typeId == 2) return runner.execute<ReturnType, i64>(arg1);

    throw new Error("Unknown typeId.");
  }
}

• foo.ts:

import { apply0, apply1 } from "./apply";

function foo<T1, T2>(): i32 {
  return sizeof<T1>() + sizeof<T2>();
}

class runner0<T1> {
  execute<ReturnType, T2>(): ReturnType {
    return foo<T1, T2>();
  }
}

class runner1 {
  execute<ReturnType, T1>(typeId: i32): ReturnType {
    return new apply0<i32, runner0<T1>>().execute(typeId);
  }
}

export function fooWithTypeId(typeId1: i32, typeId2: i32): i32 {
  return new apply1<i32, runner1>().execute(typeId1, typeId2);
}

• bar.ts

import { apply0, apply1 } from "./apply";

function bar<T1, T2>(): i32 {
  return sizeof<T1>() + sizeof<T2>();
}

class runner0<T1> {
  execute<ReturnType, T2>(): ReturnType {
    return bar<T1, T2>();
  }
}

class runner1 {
  execute<ReturnType, T1>(typeId: i32): ReturnType {
    return new apply0<i32, runner0<T1>>().execute(typeId);
  }
}

export function barWithTypeId(typeId1: i32, typeId2: i32): i32 {
  return new apply1<i32, runner1>().execute(typeId1, typeId2);
}

WebAssembly Studio project

I was able to reproduce the crash (but without the strange message) here.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!

[maxime-petitjean]

We have a new error now (from WebAssembly Studio):
[error]: Task build failed: Cannot read property 'replace' of undefined

[MaxGraey]

@maxime-petitjean just remove apply.ts from inputs in gulpfile.js:
https://webassembly.studio/?f=olxyvws67el

[maxime-petitjean]

I know it compile without apply.ts, but it's a simple reproduction of my problem.
In my project, I need apply.ts to be in inputs. Any idea why it fails?

[MaxGraey]

In my project, I need apply.ts to be in inputs. Any idea why it fails?

You can't compile apply.ts only due to non-specify (generic) class. If you compile only apply.ts you got warning:

WARNING AS232: Exported generic function or class has no concrete instances.

but it will compile. However you can't use apply0 and apply1 on host side.

[maxime-petitjean]

I don't want to use apply0 and apply1 on host side, but I want to use other functions in this file (not visible in this bug), so I can't remove it from inputs.
How do you explain that it compiles with foo.ts and apply.ts, or with bar.ts and apply.ts, but not with foo.ts, bar.ts and apply.ts?
I think that's a bug and we should look why we get this error.

[dcodeIO]

For reference, the following error is emitted in the developer console:

Fatal: Module::addExport: apply0<i16>> already exists
e.<computed> @ console.js:35

Indeed looks like some sort of bug to me that I cannot immediately explain.

Other than that, as a temporary workaround perhaps, it appears that apply.ts does not need to be specified as an actual entry file, but can just be imported normally by other files. AS does not require specifying all the source files on the command line, as one might be used to from C. In fact, specifying all files is most likely not what one wants, as that most likely yields unnecessarily clumsy code that cannot DCE/tree-shake well.