ERROR AS200: Conversion from type '__near_JSONHandler_Todo' to '__near_JSONHandler_Todo' requires an explicit cast.

[vgrichina]

I get this error when compiling example here (clicking Deploy):
https://studio.nearprotocol.com/?f=mpijex6n4

ERROR AS200: Conversion from type '__near_JSONHandler_Todo' to '__near_JSONHandler_Todo' requires an explicit cast.

       handler.decoder = new JSONDecoder<__near_JSONHandler_Todo>(handler);
                                                                  ~~~~~~~
 in ../out/model.near.ts(79,65)

Code snippet with problem is:

export function __near_decode_Todo(
        buffer: Uint8Array, state: DecoderState):wrapped_Todo {
      let handler = new __near_JSONHandler_Todo();
      handler.buffer = buffer;
      handler.decoder = new JSONDecoder<__near_JSONHandler_Todo>(handler);
      handler.decoder.deserialize(buffer, state);
      return handler.value;
    }

Note clear why these types are treated as different.

[MaxGraey]

I tried minimal example on original WAS and can't reproduce this error:
https://webassembly.studio/?f=l27f9nm0zz

Also you could implicate new JSONDecoder<__near_JSONHandler_Todo>(handler) to new JSONDecoder(handler);

[vgrichina]

Also you could implicate new JSONDecoder<__near_JSONHandler_Todo>(handler) to new JSONDecoder(handler);

This doesn't help.

I think I know more now about how to trigger this. I actually had 2 different definitions of __near_JSONHandler_Todo. Which I can prevent and hopefully this will help working around bug. However these definitions shouldn't really be clashing names, cause they are in 2 different modules.

[dcodeIO]

If I understand this correctly there are two distinct classes with the same name and the same structural layout, being used interchangeable, is that correct?

If so, the error is expected because AS can't just rely on structural equality like TS does. One example where this would fail is when field order differs between two otherwise equal types, which TS would consider equal, but AS can't because AOT compiled load offsets on fields are actually different.

class A {
  a: i32; // offset 0
  b: f32; // offset 4
}

class B {
  b: f32; // offset 0
  a: i32; // offset 4
}

In this sense AS is more like C#/Java here (currently). Might well be that we'll have to tackle this at some point when it comes to interfaces.

[vgrichina]

If I understand this correctly there are two distinct classes with the same name and the same structural layout, being used interchangeable, is that correct?

No, this is not correct. See failing code snippet above. It cannot be referring to 2 distinct types. There is type with same name in 2 different modules. But only one should be available in namespace of the given module.

[dcodeIO]

Hmm, ok, still trying to understand what's going on there.

There's one __near_JSONHandler_Todo in

• [import] ./out/model.near.ts:15 (imported file) and one in
• [main] ./out/main.near.ts:53 (main file, imports just Todo from the first)

The error happens in [import] at

export function __near_decode_Todo(
  buffer: Uint8Array,
  state: DecoderState
): wrapped_Todo {
  let handler = new __near_JSONHandler_Todo();
  handler.buffer = buffer;
  handler.decoder = new JSONDecoder<__near_JSONHandler_Todo>(handler); // HERE
  handler.decoder.deserialize(buffer, state);
  return handler.value;
}

Which is called in Todo.decode. And there I lose it, since that function should not be able to see the other handler at all. JSONDecoder has no reference to any of them. What could be the case is that, when Todo.decode is called (and compiled), the resolver somehow tries to resolve from [main] due to the function being imported to it and the parent ref being off, or something like that. Indeed this seems somewhat related to #423, leading to #424.

Might need to isolate the issue, maybe copying it and deleting anything not relevant to the issue first, leaving just the gist leading to the error.

[dcodeIO]

Closing in favor of #473, which is our tracking issue for similar related issues now.

[dcodeIO]

The resolver PR that should fix this issue if our previous speculation was correct has been merged now. Could you check if the issue still persists?

[vgrichina]

@dcodeIO the issue still persists
nearprotocol#20

[dcodeIO]

It appears to me that this isn't actually an issue with the resolver, but is introduced by something else. Unfortunately, I find it hard to work with the fork because it requires dissecting code that is partly generated by hardcoded changes to the compiler and it is unclear to me how this all works. Perhaps it makes sense to first remedy the situation of having to do hardcoded changes at all as indicated by comments like // TODO: Make these generators pluggable? in your sources? I.e. so I can easily plug my local version of the compiler to your code?