Rework resolver infrastructure

[dcodeIO]

There are multiple issues outlining problems when trying to resolve members (of namespaces), both from within and from outside static scopes. This is caused by our lookup maps not being easily traversable respectively not including aliases for all possible scenarios.

• Namespaces for types don't work #423 shows what's the issue from outside
• ERROR AS200: Conversion from type '__near_JSONHandler_Todo' to '__near_JSONHandler_Todo' requires an explicit cast. #429 describes a mismatch between what's looked up
• Exported type not found #144 describes issues with the non-standard way we look up types
• Problems with calling methods from class under namespace #127 shows what's happening from the inside

So, this is a tracking meta issue for all those kinds of problems that should most likely be solved by reworking how our IR is linked with proper nested lookups, possibly also transitioning to symbol tables to avoid having to hash strings over and over again.

There are also multiple other issues that result from a different limitation of the resolver (can't resolve every kind of expression without first compiling it):

• Compiling never end with some code examples #439 displays catastrophic backtracking
• Can't call conditional expression #255 can't resolve conditional expressions
• Cannot call instance method and operator new in one place #207 can't call method on new expression

The latter are not directly tracked here but mentioned in case it turns out that there are ways to tackle them in one go.

[dcodeIO]

Alright, the first batch of resolver rework is merged now. This fixes #423, #144, #127 and potentially #429. Symbol tables have been prepared, but not yet switched to symbols yet.

The other issues mentioned haven't been solved, yet, and remain to do for follow-up PRs.

[vgrichina]

@dcodeIO what's proper way to determine if DeclarationStatement is top-level export after these changes?

[dcodeIO]

Maybe something like:

if (declaration.is(CommonFlags.EXPORT)) {
  let source = declaration.range.source;
  if (source.isEntry && source.statements.includes(declaration)) {
    ...
  }
}

Doesn't cover exports in exported namespaces though, that'd need traversal. Also doesn't catch variable declarations as these are wrapped in a top-level VariableStatement. And doesn't catch export { someDeclaration }. Actually doesn't cover quite a lot. Might make sense to provide a traverse(node).on(...) helper or something.

[vgrichina]

BTW, what is MODULE_EXPORT vs EXPORT difference?

[vgrichina]

Looks like #429 not fixed yet, I'll try to give repro later.

[dcodeIO]

The EXPORT flag represents the presence of an export token on the declaration, while the MODULE_EXPORT flag marks everything that becomes an actual module export, i.e. to apply proper integer wrapping on exported WASM functions. But: The latter flag is applied on IR right after program initialization is complete (not AST) and not yet available in the parsing stage. An afterInitialize hook that is called once program IR is set up might help, that would have been my next suggestion, but except full information there's not much that can be modified at this stage in the compilation progress.