Replace throw new Error("not implemented") by compiler errors

[vgrichina]

It's very hard to debug "not implemented" message without context on what in source code triggered it.

See e.g. https://studio.nearprotocol.com/?f=ucpigts4w

[dcodeIO]

There are just a few occasions of throwing in the compiler itself and these usually don't trigger at all. Last time I checked this error was thrown by an outdated Binaryen build (possibly related to a caching issue on jsdelivr). @MaxGraey might know more.

[MaxGraey]

@vgrichina
See fixed version:
https://studio.nearprotocol.com/?f=pwkqd78je

Actually 10 ** dnaDigits always calculate as Math.pow(10, dnaDigits)and return f64 type so it equivalent to 1.0e17. But even if you assign it to u64 later you modulate it with u32. So I commented this lines.

@dcodeIO need better describe this errors by compiler

PS I have plan handle power operator ** with integers as ipow32 and ipow64. But currently I don't recommend use 10 ** 16 and instead use precalculated integer value

[dcodeIO]

Oh, so, this is actually something thrown by us?

[MaxGraey]

@dcodeIO
this should throw error:

const m = 16;
var a = 10 ** m;
var t: u32 = 1234;
var r = t % a; // <-  u32 % f64

But currently compile without errors.
But if we change u32 to u64. Compiler emit error as expected:

const m = 16;
var a = 10 ** m;
var t: u64 = 1234;
var r = t % a;

> ERROR TS2365: Operator '%' cannot be applied to types 'u64' and 'f64'.

 var r = t % a;

[vgrichina]

@dcodeIO @MaxGraey there are quite a few cases in compiler code like that (where throw new Error("not implemented") is used).

All of them should ideally at least point out source code line with problem, even if it's hard to provide meaningful message at the moment IMO.

[dcodeIO]

Looking through the sources after the resolver PR again, it seems that there are no "not implemented"s left that aren't intended stubs or part of the unfinished decompiler.