Merge #7431

7431: Handle `super` paths inside blocks correctly r=jonas-schievink a=jonas-schievink

We now intern `BlockLoc` and use `BlockId` to refer to block expressions. This is needed to keep `ModuleId` simple, since it would otherwise have to store an arbitrarily long chain of blocks and couldn't be `Copy`.

The `DefMap` hierarchy is now created as the caller descends into an item body. This is necessary to link the correct module as the block's parent, which is important for correct name resolution.

As a result, we can now resolve `super` paths inside block expressions by climbing the `DefMap` chain.

bors r+

Co-authored-by: Jonas Schievink <[email protected]>

1 files changed, 26 insertions, 0 deletions

diff --git a/crates/hir_def/src/nameres/tests/block.rs b/crates/hir_def/src/nameres/tests/block.rs
index 01d6326a7..470ca593e 100644
--- a/crates/hir_def/src/nameres/tests/block.rs
+++ b/crates/hir_def/src/nameres/tests/block.rs
@@ -95,3 +95,29 @@ fn outer() {
         "#]],
     );
 }
+
+#[test]
+fn super_imports() {
+    check_at(
+        r#"
+mod module {
+    fn f() {
+        use super::Struct;
+        $0
+    }
+}
+
+struct Struct {}
+"#,
+        expect![[r#"
+            block scope
+            Struct: t
+            crate
+            Struct: t
+            module: t
+
+            crate::module
+            f: v
+        "#]],
+    );
+}