The second pass is done enough to move on to code generation. It:
Type checks everything, including non-declared symbols.
Builds full control flow graphs that contain execution-ordered defs/uses.
Adds in auto-declared variables; $result for functions, $i for loops, and $last for for loops.
I redid the way that generic types are done so that they implicitly track what known container types can / cannot match. This, plus the willingness to generate type-cased calls will allow me to avoid the problem of having to declare param types when the only thing you do to it is index it, for instance (which has always been the case in the Nim c4m). I don't think there is anything at all that needs a written type for disambiguation at the moment, and very little will require dynamic checks.
There are some things I'm leaving for later:
I have not done the walk of the CFG yet to generate error messages about use-before-def problems, returns on every branch, etc. But the graph is otherwise completely built.
While I erase $result from function scopes if it isn't used, I'm not yet erasing the loop variables when they're not used (I intend to deal when doing codegen).
Because of that lack of erasure, I don't yet warn when something like $i is ambiguous. However, there is a disambiguation scheme; if you label loops, label$i and, if appropriate, label$last are available. Again, I was planning on adding these warnings in code gen.
Most of the builtin operations (like addition, etc) are essentially converted into magic (polymorphic) function calls, like __add__. I am not yet statically binding where possible; this too I expect to do at code gen (generating type casing when static binding isn't possible).
Though I wasn't planning on re-doing constant folding until later, I didn't go ahead and do it :)
There are probably plenty of bugs / issues to shake out, including a few already on my list... most significantly, I keep forgetting to check, but I think I might have forgotten to make functions from imported modules available outside the module (which won't be much work, but will be natural to handle in codegen).
The second pass is done enough to move on to code generation. It:
$resultfor functions,$ifor loops, and$lastforforloops.There are some things I'm leaving for later:
$resultfrom function scopes if it isn't used, I'm not yet erasing the loop variables when they're not used (I intend to deal when doing codegen).$iis ambiguous. However, there is a disambiguation scheme; if you label loops,label$iand, if appropriate,label$lastare available. Again, I was planning on adding these warnings in code gen.__add__. I am not yet statically binding where possible; this too I expect to do at code gen (generating type casing when static binding isn't possible).