Summary

Use a Salsa accumulator for diagnostics to avoid double-emitting diagnostics for unpack assignments.

We now use a single CompileDiagnostic accumulator that stores all diagnostics. That includes IO errors, parse errors, and type check errors. I decided that we're beyond where String annotations are fun. That's why I introduced a Diagnostic trait with 5 implementations:

• ParseDiagnostic for parse errors
• SourceTextDiagnostic for IO errors
• TypeCheckDiagnostic for type inference errors
• RevealedTypeDiagnostic for reveal_type (info severity)
• CompileDiagnostic which is a cheap cloneable any diagnostic wrapper that implements salsa accumulator.

Using a structured diagnostic has the advantage of no longer needing manual parsing in the LSP.

A nice side effect of this is that mdtests now support tests with syntax errors because parse-errors are just another diagnostic :)

Performance regression

I expect this to hit performance pretty bad, especially the incremental benchmark. The problem is that there's currently no way to run an accumulator concurrently. That's why I had to resort to a hack where we run type checking in parallel, and then collect the diagnostics. This has the downside that Salsa first runs all queries (in parallel) but then has to iterate over all of them again to collect the diagnostics (even if there are none!). The queries are all cached, but it is still expensive because the query dependency tree is somewhat large.

This overhead is especially noticeable in the cache case. We'll need salsa-rs/salsa#568 to do the accumulation and checking in one go.

Test Plan

cargo test