Added error message when using --noLib and not importing any builtins at all

[fcrick]

When you compile with --noLib and you don't import anything, the compiler gets confused because the required builtin function start is not available. It wasn't really clear to me if that needed to be addressed, but it seemed like making the error more clear about how to fix the problem would be a good start.

Seems like it should also say so if compilation fails, instead of saying "Cannot read property 'setOptimizeLevel' of undefined", but this change doesn't address that.

New first line of error output:

ERROR: AssertionError: builtin "start" missing. Try adding: import "builtins"

Existing error output:

ERROR: AssertionError: assertion failed
    at assert (C:\src\assemblyscript\std\portable\index.js:172:9)
    at Program.initialize (C:\src\assemblyscript\src\program.ts:623:21)
    at Compiler.compile (C:\src\assemblyscript\src\compiler.ts:320:13)
    at Object.compileProgram (C:\src\assemblyscript\src\index.ts:150:41)
    at stats.compileTime.measure (C:\src\assemblyscript\cli\asc.js:453:33)
    at measure (C:\src\assemblyscript\cli\asc.js:809:3)
    at C:\src\assemblyscript\cli\asc.js:452:28
    at Object.main (C:\src\assemblyscript\cli\asc.js:458:5)
    at Object.<anonymous> (C:\src\assemblyscript\bin\asc:3:60)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
C:\src\assemblyscript\node_modules\binaryen\index.js:5
if(n){var da,ea;a.read=function(b,e){var c=q(b);c||(da||(da=require("fs")),ea||(ea=require("path")),b=ea.normalize(b),c=da.readFileSync(b));return e?c:c.toString()};a.readBinary=function(b){b=a.read(b,!0);b.buffer||(b=new Uint8Array(b));assert(b.buffer);return b};1<process.argv.length&&(a.thisProgram=process.argv[1].replace(/\\/g,"/"));a.arguments=process.argv.slice(2);process.on("uncaughtException",function(b){if(!(b instanceof fa))throw b;});process.on("unhandledRejection",function(){process.exit(1)});



                                      ^

TypeError: Cannot read property 'setOptimizeLevel' of undefined
    at Object.main (C:\src\assemblyscript\cli\asc.js:495:10)
    at Object.<anonymous> (C:\src\assemblyscript\bin\asc:3:60)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:236:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:560:3)

[dcodeIO]

What do you think of including the builtins file even in the --noLib case instead? Or would that already provide "too much", and there should instead be an alternative more minimal builtins file that becomes included?

[fcrick]

I think including the builtins even with --noLib is ok with me. I was a bit confused by having start mixed in there, I guess, but if it's auto-included, that won't be an issue.

[dcodeIO]

Yeah, this exists because start needs to have a declaration somewhere to be a valid AST node, in case a diagnostic references it, i.e. when declaring a duplicate global start function.

[fcrick]

i guess a few of them seem like they could be somewhere else, like:

HEAP_BASE
__gc_iterate_roots

and maybe

ERROR
WARNING
INFO

My preference would be to split up things based on what they depend on, in general.

[dcodeIO]

ERROR, WARNING, INFO etc. could go to diagnostics.ts or something. But without HEAP_BASE, one won't be able to implement any sort of dynamic memory management when static data, i.e. strings, are present. __gc_iterate_roots will go away (moved to gc.ts) once the GC branch is ready.

[fcrick]

But without HEAP_BASE, one won't be able to implement any sort of dynamic memory management when static data, i.e. strings, are present.

That sounds like it should declared (or referenced) by those types, since its their dependency. Nothing else in builtins depends on HEAP_BASE, correct?

[dcodeIO]

Hmm, yeah, now that you mention it I think it could be moved to memory.ts.

[dcodeIO]

Things should be properly moved now, and the builtins file should always be included.