diff options
author | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-03-25 11:38:46 +0000 |
---|---|---|
committer | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-03-25 11:38:46 +0000 |
commit | c4ead49361e4b8c0586b810399c8e96a468b891c (patch) | |
tree | 0b1ba767e34e3baef938f6b7672f95ce4572ec07 /README.md | |
parent | 8aedf9603df1bc68eafcd8dcf3c14e5a6a2c8638 (diff) | |
parent | 309716cffe93d065bcad0344b0f332425576c1e5 (diff) |
Merge #1034
1034: HIR diagnostics API r=matklad a=matklad
This PR introduces diagnostics API for HIR, so we can now start issuing errors and warnings! Here are requirements that this solution aims to fulfill:
* structured diagnostics: rather than immediately rendering error to string, we provide a well-typed blob of data with error-description. These data is used by IDE to provide fixes
* open set diagnostics: there's no single enum with all possible diagnostics, which hopefully should result in better modularity
The `Diagnostic` trait describes "a diagnostic", which can be downcast to a specific diagnostic kind. Diagnostics are expressed in terms of macro-expanded syntax tree: they store pointers to syntax nodes. Diagnostics are self-contained: you don't need any context, besides `db`, to fully understand the meaning of a diagnostic.
Because diagnostics are tied to the source, we can't store them in salsa. So subsystems like type-checking produce subsystem-local diagnostic (which is a closed `enum`), which is expressed in therms of subsystem IR. A separate step converts these proto-diagnostics into `Diagnostic`, by merging them with source-maps.
Note that this PR stresses type-system quite a bit: we now type-check every function in open files to compute errors!
Discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Diagnostics.20API
Co-authored-by: Aleksey Kladov <[email protected]>
Diffstat (limited to 'README.md')
0 files changed, 0 insertions, 0 deletions