Compute proper module parent during resolution

[Aaron1011]

Fixes #75982

The direct parent of a module may not be a module
(e.g. const _: () = { #[path = "foo.rs"] mod foo; };).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

This same code is copied in rustdoc:

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Lines 750 to 767 in b385598

	// The immediate parent might not always be a module.
	// Find the first parent which is.
	loop {
	if let Some(parent) = self.cx.tcx.parent(current) {
	if self.cx.tcx.def_kind(parent) == DefKind::Mod {
	break Some(parent);
	}
	current = parent;
	} else {
	debug!(
	"{:?} has no parent (kind={:?}, original was {:?})",
	current,
	self.cx.tcx.def_kind(current),
	item.def_id
	);
	break None;
	}
	}

Maybe it's worth making this a query or method on tcx?

[Aaron1011]

@jyn514: It's not quite the same code - we don't have a tcx available in the resolver, so we need to go through the cstore methods directly. I think it's better to keep this separate, since going through a tcx is better when a tcx is available.

[petrochenkov]

So, the sad part here is that the Module in question is not actually a mod item, but any "module in resolve sense" aka "a container for named items", that includes blocks.

If

const _: () = {
    #[macro_export]
    macro_rules! my_macro {
        () => {};
    }
};

was written in the current crate, then get_module would indeed returned the constant's block (it would have ModuleKind::Block).

We don't track blocks for other crates, so we simply cannot produce a correct answer here.
This situation is specific to #[macro_export] macros which have unique ability to be visible to other crates while being written in very internal locations.

So, returning the closest mod item is not really correct, but at least it doesn't ICEs.
Thankfully, returning an incorrect parent module in this case shouldn't have any observable effect in theory (but it would be a different story if my_macro could use def-site hygiene).

[petrochenkov]

r=me with the test changes #77984 (comment)

[Aaron1011]

@petrochenkov: Your suggested test caught a bug in my implementation. We also need to perform the parent-walking in macro_def_scope (not just in get_module), since a macro_rules! might occur directly inside a const item.

[petrochenkov]

@bors r+

[bors]

📌 Commit 283053a has been approved by petrochenkov