Tracking issue: OOM handling in the compiler

[mlugg]

The Zig compiler currently fails to handle OOM correctly in many cases.

Ideally, if semantic analysis OOMs, we would like to report an error message in zcu.failed_analysis. There are two problems with this:

• Adding the error message may itself trigger OOM.
• Upon OOM, important compiler state, such as incremental compilation dependency information, may not be valid.

To solve the second problem, we can probably throw out the new invalid incremental compilation state on updates. The reference information (zcu.all_references, zcu.all_type_references) will be a subset of the correct data, so we can still emit some correct error messages during this update. We must simply avoid saving the new state to disk, and if the compiler is running in listen mode, throw away the current Compilation state and reload it from disk.

If the first problem occurs, then we don't really have much choice but to bubble the OutOfMemory up to somewhere around Compilation.update. We could store information to a Compilation field to indicate what analysis caused the OOM, and report that from where we catch the error, terminating the update early.

The main important thing is that we leave the cache in a coherent state. Provided we throw out any updated state on OOM (i.e. don't call Compilation.saveState) and other cache writes are atomic, this is easily achievable.

We should make sure to carefully audit how the InternPool handles OOM, since if we ever want to continue analysis on OOM, it's important that no invariants are violated in the InternPool.