ERROR TS2322: Type 'FooBar' is not assignable to type 'FooBar'.

[vgrichina]

➜  near-bindgen git:(number-types) ✗ ./test.sh 
+ BASEDIR=../..
+ ../../bin/asc model.ts --nearFile model_near.ts
+ ../../bin/asc main.ts --nearFile main_near.ts
ERROR TS2322: Type 'FooBar' is not assignable to type 'FooBar'.

     return foobars.map<ContainerClass>((it: FooBar, i: i32, arr: Array<FooBar>): ContainerClass => {
                                         ~~~~~~~~~~
 in main.ts(35,40)

ERROR: Compile error
    at Object.main (/Users/vg/Documents/assemblyscript/cli/asc.js:477:21)
    at Object.<anonymous> (/Users/vg/Documents/assemblyscript/bin/asc:4:60)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)

For repro see nearprotocol#23

Go to tests/near-bindgen and run ./test.sh.

It looks like #489 doesn't fully solve all name clash issues.

[MaxGraey]

Could you provide wasm or wat file with --debug and -O0 set flags?

[vgrichina]

@MaxGraey compiler errors out, how would I provide .wasm file?

To repro you can just check out my branch, do npm install and run test as described above and tweak compilation options as you like. It would work fine unless you are on Windows machine – then you'll have to create json subfolder and copy files from ../../node_modules/assemblyscript-json/assembly manually (really looking forward to #448).

[MaxGraey]

Ah, sorry, I missed this actually compiler error)

[MaxGraey]

@vgrichina I try to reproduce your issue in WAS with emulate generated "near_model" but everything compile in normal way:
https://webassembly.studio/?f=dcql4i6j09a

[MaxGraey]

btw with latest AS version you could simplify this to:

export function convertFoobars(foobars: FooBar[]): ContainerClass[] {
  return foobars.map<ContainerClass>(it => ({ foobar: it }));
}

[dcodeIO]

While working on the runtime branch I hit an issue that might, potentially, be related to this. Essentially, if you have:

namespace foo {
  export const bar: i32 = somethingGeneric<Bar>();
  class Bar {}
}
class Bar {}

the resolver picks up the outer Bar. Seems to affect only type arguments part of the expression, though, but this looks like there could be some sort of connection.

[dcodeIO]

Finally! It just so happened that I reproduced this issue:

namespace foo {
  export class Bar {
    a: i32;
  }
}
class Bar {
  a: f64;
}

function baz<T>(foo: T): i32 {
  return foo.a;
}

var fooBar = new foo.Bar();
fooBar.a = 1;
baz<foo.Bar>(fooBar);

var bar = new Bar();
bar.a = 1;
baz<Bar>(bar);

The underlying problem is that when a generic function becomes compiled, it is named after its type argument's name, ignoring nesting, hence the same function becomes shared for types of the same top-most name even though in different code locations, in turn leading to the described issue. The obvious fix here is to use a namespaced naming scheme, i.e. compile a baz<entry/foo.Bar> and a baz<entry/Bar> etc.

Sorry that it took so long to confirm.