Merge #8569

8569: Support inherent impls in unnamed consts r=jonas-schievink a=jonas-schievink

It turns out that some proc. macros not only generate *trait* impls wrapped in `const _: () = { ... };`, but inherent impls too. Even though it is questionable whether *custom derives* should produce non-trait impls, this is useful for procedural attribute macros once we support them.

bors r+

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

1 files changed, 9 insertions, 1 deletions

diff --git a/crates/hir_def/src/visibility.rs b/crates/hir_def/src/visibility.rs
index 9908cd926..d4b7c9970 100644
--- a/crates/hir_def/src/visibility.rs
+++ b/crates/hir_def/src/visibility.rs
@@ -123,11 +123,19 @@ impl Visibility {
         def_map: &DefMap,
         mut from_module: crate::LocalModuleId,
     ) -> bool {
-        let to_module = match self {
+        let mut to_module = match self {
             Visibility::Module(m) => m,
             Visibility::Public => return true,
         };
 
+        // `to_module` might be the root module of a block expression. Those have the same
+        // visibility as the containing module (even though no items are directly nameable from
+        // there, getting this right is important for method resolution).
+        // In that case, we adjust the visibility of `to_module` to point to the containing module.
+        if to_module.is_block_root(db) {
+            to_module = to_module.containing_module(db).unwrap();
+        }
+
         // from_module needs to be a descendant of to_module
         let mut def_map = def_map;
         let mut parent_arc;