internal: start new diagnostics API

At the moment, this moves only a single diagnostic, but the idea is
reafactor the rest to use the same pattern. We are going to have a
single file per diagnostic. This file will define diagnostics code,
rendering range and fixes, if any. It'll also have all of the tests.
This is similar to how we deal with assists.

After we refactor all diagnostics to follow this pattern, we'll probably
move them to a new `ide_diagnostics` crate.

Not that we intentionally want to test all diagnostics on this layer,
despite the fact that they are generally emitted in the guts on the
compiler. Diagnostics care to much about the end presentation
details/fixes to be worth-while "unit" testing. So, we'll unit-test only
the primary output of compilation process (types and name res tables),
and will use integrated UI tests for diagnostics.

1 files changed, 0 insertions, 14 deletions

diff --git a/crates/hir_def/src/nameres/tests/diagnostics.rs b/crates/hir_def/src/nameres/tests/diagnostics.rs
index ec6670952..c82deca9c 100644
--- a/crates/hir_def/src/nameres/tests/diagnostics.rs
+++ b/crates/hir_def/src/nameres/tests/diagnostics.rs
@@ -79,20 +79,6 @@ fn dedup_unresolved_import_from_unresolved_crate() {
 }
 
 #[test]
-fn unresolved_module() {
-    check_diagnostics(
-        r"
-        //- /lib.rs
-        mod foo;
-          mod bar;
-        //^^^^^^^^ UnresolvedModule
-        mod baz {}
-        //- /foo.rs
-        ",
-    );
-}
-
-#[test]
 fn inactive_item() {
     // Additional tests in `cfg` crate. This only tests disabled cfgs.