116 releases

new 0.0.211 Apr 15, 2024
0.0.207 Mar 25, 2024
0.0.190 Dec 18, 2023
0.0.187 Nov 27, 2023
0.0.66 Jul 26, 2021

#142 in Programming languages

Download history 808/week @ 2023-12-23 1201/week @ 2023-12-30 2024/week @ 2024-01-06 2138/week @ 2024-01-13 1752/week @ 2024-01-20 1636/week @ 2024-01-27 1733/week @ 2024-02-03 1347/week @ 2024-02-10 1726/week @ 2024-02-17 3583/week @ 2024-02-24 1804/week @ 2024-03-02 1879/week @ 2024-03-09 1973/week @ 2024-03-16 1991/week @ 2024-03-23 1759/week @ 2024-03-30 1755/week @ 2024-04-06

7,700 downloads per month
Used in 10 crates (via ra_ap_ide)


12K SLoC

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.


~397K SLoC