incremental compilation review

[disruptek]

The diff is now like 40,000 lines, so I'm going to port it.

Before I do this, I want to see if we have any new ideas on the best way to implement IC. Here are the main features of the approach in my last version, the ic6 branch:

• We capture symbol location changes via little hacks everywhere, to associate the changes to backend modules. You may recall seeing this setLocation or clearRope notation in a review. Fairly painful as code smell goes. I will try to do this better next go 'round. It should already have been improved by the mangling branch.
• We also seal the PContext and prevent mutating the ast with similar hacks, though the mechanism is cleaner -- this is the witness stuff. I'd like to improve this, too; it's still pretty smelly.
• When we generate backend code, we do so against a clone of the module graph. Mutations are collected in the clone and then written to the database. This feels pretty expensive, but I'm hopeful that the expense will be relatively small, ultimately.
• To produce output, we playback mutations from the database against the original module graph. Whether they were produced recently or in a prior compilation makes no difference to us. We should be able to audit this pretty easily by comparing the results between the two graphs.

We discussed going straight to a compiler server, but I think dumping sqlite in favor of frosty is probably going to be a big enough first step that we don't need to complicate the user's workflow just yet. It's easy to create a separate server product if someone really wants it; this way, it's really an orthogonal problem.

Any feedback?

[disruptek]

Why don't we simply make symbol locations immutable in front-end AST and store them separately in the backend? We can start with a tiny adaptation to the mangler and then proceed further after IC is done. If you want to switch away from ropes, this is a good excuse to do that, too.

[Araq]

Fine with me, in fact, I think I proposed something similar before.