Crate ide_diagnostics

Diagnostics rendering and fixits.

Most of the diagnostics originate from the dark depth of the compiler, and are originally expressed in term of IR. When we emit the diagnostic, we are usually not in the position to decide how to best “render” it in terms of user-authored source code. We are especially not in the position to offer fixits, as the compiler completely lacks the infrastructure to edit the source code.

Instead, we “bubble up” raw, structured diagnostics until the hir crate, where we “cook” them so that each diagnostic is formulated in terms of hir types. Well, at least that’s the aspiration, the “cooking” is somewhat ad-hoc at the moment. Anyways, we get a bunch of ide-friendly diagnostic structs from hir, and we want to render them to unified serializable representation (span, level, message) here. If we can, we also provide fixits. By the way, that’s why we want to keep diagnostics structured internally – so that we have all the info to make fixes.

We have one “handler” module per diagnostic code. Such a module contains rendering, optional fixes and tests. It’s OK if some low-level compiler functionality ends up being tested via a diagnostic.

There are also a couple of ad-hoc diagnostics implemented directly here, we don’t yet have a great pattern for how to do them properly.

Structs

• Diagnostic
• DiagnosticsConfig

Enums

• DiagnosticCode
• ExprFillDefaultMode

Functions

• full_diagnostics
  Request both syntax and semantic diagnostics for the given [FileId].
• semantic_diagnostics
  Request semantic diagnostics for the given [FileId]. The produced diagnostics may point to other files due to macros.
• syntax_diagnostics
  Request parser level diagnostics for the given [FileId].