📎 Extract semantic exports during scanning

[arendjr]

Description

Update: We had some discussion on Discord, where some valid concerns were raised with moving the semantic model to the scanner.

It’s still possible that moving the semantic model ends up being the right choice, but before assuming so, we need to consider:

• We want to 📎 Generalise the DependencyGraph #5333 . Even if we decide to move the semantic model, we may want to have an abstraction around it.
• The requirements for what we need in the scanner are actually much smaller than what the semantic model provides. At least at first, we care about looking up symbols at the global scope, but not necessarily things such as control flow. However, we may want to access the control flow later when implementing type inference.

Original description

Currently, our analyser operates in two phases: a syntax phase and a semantic phase. The idea is that rules that don't need the semantic model can operate in the syntax phase, while that same phase is also used for building the semantic model. Then a second pass is done where the semantic model can also be used.

However, we now have the scanner, which also does its own pass on the scanned files in order to build the dependency graph. This means we effectively have three passes now. What's more, to improve the dependency graph and allow for resolving imports to concrete declarations, we will need access to the semantic model in the scanner. The reason for this is that without semantic model, we cannot resolve the target for an export declared with export { foo }.

Of course, if we need to build the semantic model in the scanner, we would do best to persist it and run the analyser in a single phase afterwards.