replaces implicit passes array registered at runtime with explicit function calls; simplify compilation pipeline

[ringabout]

ref nim-lang/RFCs#503
follow up #21379

The processModule should handle all the logics by calling parser, sem, transf, codegen in order.

I'm keeping the passes interface for nimsuggest, nimfix and third-party library for backwards compatibilities.

[ringabout]

I have few questions.

It seems that I need to duplicate lots of code to replace passes. Could I only make the pipeline explicit for C like backends and keep the rest under the umbrella of the passes? And are there other changes I should make to make the pipeline explicit?

[arnetheduck]

as far as I'm concerned, in an ideal world the c backend is something that would not be invoked at all until semantics and transformations have completed, more or less - ie we should not be calling the c backend at all until we know there's a sound nim ast - this way, we shield the semantic and transformation passes from what the C backend ultimately does - it would also mean splitting out any "useful" pre-c-generation work that the C backend does (ie calling transformations)... of course, there are degrees to this ideal and it's important that transformations don't lose significant optimization information that the backends can exploit, so there's a balance here..

Effectively, what we end up with is a "mid-level" IR comprising of a subset of the full AST, that still can be used for "nim-level" optimizations, ie where knowledge of nim semantics allows the implementation of useful code transformations - after that, the C pipeline takes or (or in the case of nlvm, the llvm pipeline which presents several opportunities for optimizations that the C backend might struggle with (specially for things like callbacks, assumption checking, defects etc).

[arnetheduck]

ah, which brings me to the other point: it would be nice at some point to be able to replace the VM with a different one - in nlvm, the possibility exists to use the same IR for compile-time execution as for code generation - this means that if a function is used at compile time, it would be practical if llvm code generation could happen before the function is used in the VM: the benefit of this approach in nlvm is that the function only has to be transformed once to IR if the function is used both during compile and runtime - in particular, we can run llvm optimizers on the function before doing the compile-time execution.

This suggests that the pipeline might need some additional "plugin" points in the future, if this use case is to be covered - of course, this kind of stuff can also be maintained in an nlvm-specific fork of Nim.

[Araq]

Why is this still required?

[ringabout]

It is not required. It is kept for tools like nimsuggest, drnim and nimfix and backward compatibilities. I have removed passes imports from other modules in the compiler. I can remove passes from nimsuggest and nimfix as well.

[Araq]

Can be done in a followup PR.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from d51a392

Hint: mm: orc; opt: speed; options: -d:release
166204 lines; 8.110s; 612.531MiB peakmem