Strict field initialization

[saulecabrera]

This PR addresses #482

It introduces a new kind of flags: FieldFlags in order to track the state of each field per flow. Under the hood, field flags are represented as Map<string, FieldFlags> in which each field is uniquely identified by its internal name. Field flags are only initialized when the current flow belongs to a constructor, in every other case they are null

A general overview of the changes:

• Dry up error reporting for this case, the code is almost identical when exporting a class and when instantiating one (Ensure constructors of exported classes #1154 helps on this)
• Handle conditional field assignment in the constructor
• Handle switch statement
• Fix self compilation errors
• Fix test errors regarding strict initialization
• Constructor inlining

[saulecabrera]

Flows was an interesting journey 😅

I've added support for conditional flows in the constructor in my last commits, in the test files you can find the use cases (https://github.com/AssemblyScript/assemblyscript/pull/1155/files#diff-5fa1688a93849f802b2ae2b7f3cbffe6R26)

I realized that we need the same behaviour for switch, I'm tackling that as part of my next commit.

[saulecabrera]

In 743ef7e I fixed self compilation and tests all around.

Self compilation seems to be OK on CI, anyhow I'm getting an index out of range exception on npm run astest, I've tracked this down and I believe it's here, but not sure what is causing it.

[MaxGraey]

It seems main reason on failure happened in setPedantic:
https://github.com/AssemblyScript/assemblyscript/runs/544024426#step:6:476

[dcodeIO]

Not necessarily, the error begins a few lines prior. Wondering how it is even able to print during console.log - as if inspecting would call something.

[saulecabrera]

I spent some time today on @MaxGraey's hint (debugging setPedantic) but couldn't find anything meaningful, then I started backtracking on all the changes in this PR with no luck, I was mostly trying to prove that all the fields that I marked with ! have an equivalent effect as prior to this change and that they have nothing to do with the error.

[saulecabrera]

So I was not terribly convinced that the fix that I introduced in 8c6a554 was the right way to go without knowing why. I've found the answer, it turns out that we're not compiling exported generic classes unless that this is done in a different code path or in a different way that I'm not aware of; that means that with the code that I had prior to 8c6a554 for a class like:

export class C<T> {
  prop: i32
}

the compiler won't report any compilation errors and even worse it will skip the initialization of prop: i32, this will eventually result in an out of range error.

@dcodeIO:

• Any insight on why we skip the compilation of exported generic classes?

[MaxGraey]

It's well known issue. And we even have PR for this: #981

[dcodeIO]

What should happen currently is, if one has

export class C<T> {
  prop: i32
}

there is nothing to export because we don't know what T will be, so there is no code to export. However, as soon as one does

export class C<T> {
  prop: i32
}
new C<i32>(); // here

we know that there is indeed a class C<i32> and we will create the exports for these, but not as C#xy but as C<i32>#xy, for each concrete class. Might be that this doesn't work a 100% currently, but that's the intended mechanism, with the issue linked above asking for an error if something is exported that is never instantiated.

[MaxGraey]

export class C<T> {
  prop: i32
}
new C<i32>(); // here

I guess even with this case we shouldn't export generics for host and throw the error / warning

[dcodeIO]

Hesitating a bit here due to all the someField! changes to the compiler sources. I think that since we need proper type checking anyway, and can reasonably default non-reference fields to zero, perhaps definite assignment should be the default, with the annotation being optional where necessary due to type checking issues with tsc?