Add initial support for storing function source and getting it from func .toString()

[svaarala]

Placeholder for now.

Basic idea is to store _Source in the compiler when source support is enabled. Then, in Function.prototype.toString(), if source is available, use it as the toString() result directly.

So it's up to the compiler to come up with a useful _Source that matches ES6 requirements.

Later on it'd make sense to use some form of compression on the source code, e.g. bit packing optimized for ASCII and RLE compressing white space.

Or maybe an actual compression algorithm: for example, a 1kB footprint for a compression/decompression algorithm would be worth it if the ~3kB strings and built-ins init data was reduced to 2kB. Also, the more strings and built-ins are present (which increases over time), the better this trade-off would be.

[svaarala]

So initial, quite useless, output for now:

duk> ""+Math.cos
= "function cos() { [native code] }"
duk> ""+function foo(a,b,c) {}
= "XXX"

Where the "XXX" is stored as an internal _Source property of the function template and copied over to the instance.

[fatcerberus]

I experimented with this maybe a year ago, the wall I hit was that I couldn't figure out how to pass the input source code from the lexer/compiler to the point where it was actually needed (i.e. the point of function object creation).

[svaarala]

The approach here should allow that - for now, _Source is a string but more ideally it'd be a bit packed or compressed plain buffer which would be decompressed by Function.prototype.toString(). But one step at a time.

[svaarala]

Getting the function source is actually a little bit difficult because it doesn't exist as a full source at any point in the compilation. The input data is decoded on the fly to a lookup window which is used for tokenization. That window contains codepoints rather than string data, and the decoding process does e.g. surrogate creation so that raw input is not suitable as is as the source property.

So, to do this properly one may need to store the lexer position, reinitialize the lexer to the start of the function body, and decode codepoints until the end of the function. Then, encode the codepoints (on-the-fly of course) into a CESU-8 source text.

[svaarala]

But I won't work actively on this right now: just wanted to open this for discussion because it's been scattered into other issues/pulls and it's good to try to keep issues and pulls on topic.

[cheako]

humbletim/glm-js#10

For some reason they do this a lot.

[cheako]

You also need to stringify local variables, as in https://github.com/humbletim/glm-js/blob/aef4fd1b8a330c91b71565df7b3111f1b5968544/src/glm.common.js#L528