Use fully qualified names in generic types

[dcodeIO]

This PR addresses a probable cause for the Type 'Foo' is not assignable to type 'Foo' issue. See also this comment.

most likely fixes #539 / cc @vgrichina

[vgrichina]

Looks like compiler OOMs after merging this, see:
https://github.com/nearprotocol/assemblyscript/tree/hang-demo/tests/near-bindgen

Trying to compile main.ts hangs and goes out of memory.

[dcodeIO]

Do you have a crash dump?

[vgrichina]

@dcodeIO

+ ../../bin/asc main.ts -o test.wasm

<--- Last few GCs --->

[5889:0x103802200]    25868 ms: Scavenge 1397.1 (1422.7) -> 1396.7 (1423.7) MB, 3.0 / 0.0 ms  (average mu = 0.095, current mu = 0.047) allocation failure 
[5889:0x103802200]    27214 ms: Mark-sweep 1397.4 (1423.7) -> 1397.0 (1423.2) MB, 1336.9 / 0.0 ms  (average mu = 0.070, current mu = 0.020) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0xd163e0dbe3d]
Security context: 0x280e1b49e6e1 <JSObject>
    1: /* anonymous */ [0x280e7037eaa9] [/Users/vg/Documents/assemblyscript/src/diagnostics.ts:~227] [pc=0xd163e69d103](this=0x280e533ca561 <Parser map = 0x280ed4b198b1>,code=1003,category=2,range=0x280e69102999 <Range map = 0x280ed4b31c19>,relatedRange=0x280e6c4022b1 <null>,arg0=0x280e6c4022b1 <null>,arg1=0x280e6c4022b1 <null>,arg2=0x280e6c4022b1 <null>)
   ...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003ae75 node::Abort() [/Users/vg/n/bin/node]
 2: 0x10003b07f node::OnFatalError(char const*, char const*) [/Users/vg/n/bin/node]
 3: 0x1001a7ae5 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/vg/n/bin/node]
 4: 0x100572ef2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/vg/n/bin/node]
 5: 0x1005759c5 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/vg/n/bin/node]
 6: 0x10057186f v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/vg/n/bin/node]
 7: 0x10056fa44 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/vg/n/bin/node]
 8: 0x10057c2dc v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/vg/n/bin/node]
 9: 0x10057c35f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/vg/n/bin/node]
10: 0x10054b6f6 v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::Heap::RootListIndex, int, v8::internal::Object*, v8::internal::PretenureFlag) [/Users/vg/n/bin/node]
11: 0x1004f2b1e v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/vg/n/bin/node]
12: 0x10078daff v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/vg/n/bin/node]
13: 0xd163e0dbe3d 
./test.sh: line 6:  5889 Abort trap: 6           $BASEDIR/bin/asc main.ts -o test.wasm

Is issue non-reproducible on your side?

[dcodeIO]

Can confirm, seems to hang in Parser#parseClassOrInterface on

    if (!tn.skip(Token.CLOSEBRACE)) {
      do {
        let member = this.parseClassMember(tn, declaration);
        if (member) members.push(<DeclarationStatement>member);
      } while (!tn.skip(Token.CLOSEBRACE)); // HERE
    }

[dcodeIO]

Seems there is a (possibly transform-generated) method somewhere looking like

setString(name: string, value: ~lib/string/String): void

which fails to parse because it uses a fully qualified type name for value. The compiler shouldn't hang on something like this ofc, but this issue must be addressed as well.

My assumption on the infinite loop is that since ~ isn't a valid identifier start the parser errors at it but doesn't advance, in turn trying to parse the same invalid token over and over again.

[dcodeIO]

For reference, this is how I debugged this: In test.sh, change the asc invocation to

node --inspect $BASEDIR/bin/asc model.ts --nearFile model_near.ts
node --inspect $BASEDIR/bin/asc main.ts -o test.wasm

and navigate to chrome://inspect in Chromium. Now, when test.sh is run, the inspect tab will show a prompt to inspect the process, which upon connect yields a detailed call stack right before OOM with code locations. Everything else was just a matter of console.logging tn.source.text.substring(tn.pos - 64, tn.pos + 64) to see what's currently processed.

It might be possible to simplify this process in the future by adding an --inspect option to asc itself, automatically wrapping itself in a node --inspect env, or, alternatively, forwarding node command line arguments like through appending -- --inspect.

[vgrichina]

wow, node --inspect is really cool, last time I tried debugging node (few years ago) it's been far more involved

[vgrichina]

ERROR TS1003: Identifier expected.

 setString(name: string, value: ~lib/string/String): void {
                                ~
 in model_near.ts(225,31)

Awesome, fix worked!

[dcodeIO]

Let me know when you think this PR is good to merge :)

[vgrichina]

@dcodeIO fix works for me, should be good to merge