Change:
} fn visit_macro_def(&mut self, md: &'tcx hir::MacroDef<'tcx>) { <ins> // Non-opaque macros cannot make other items more accessible than they already are. </ins> if attr::find_transparency(&self.tcx.sess, &md.attrs, md.ast.macro_rules).0 != Transparency::Opaque { <del> self.update(md.hir_id, Some(AccessLevel::Public)); </del> <ins> // `#[macro_export]`-ed `macro_rules!` are `Public` since they // ignore their containing path to always appear at the crate root. if md.ast.macro_rules { self.update(md.hir_id, Some(AccessLevel::Public)); } </ins> return; }

Discussion:
rustdoc is showing the macro at the wrong path in libcore: says but really it is (and the same goes for ). Looks like is not handled correctly? Cc
cc
When a macro is marked as reexported, you can use it directly from the "top", so in this regard, isn't it the expected behavior?
AFAIK that is not true for macros, just for macros.
Note that there is no here. This macro is exported via , like normal items (functions, structs, ...).
Code example: So I think there is definitely a rustdoc bug here. The path it shows does not work.
Oh I see. Indeed, it's a bug.
Not sure if helpful, but the way we got public exports to work in rustdoc in was by creating a separate crate (), and then re-exporting from from the main crate. This enabled us to render  in rustdoc. This issue will also affect the upcoming  PR.
how hard is it to fix this problem, and what does the rustdoc team's prioritization for this look like? We'd like to stabilize , and I am not sure if we want to stabilize this while its docs are rendered incorrectly.
Sorry but no idea. I don't have much time lately so maybe someone else from the will give it a try? Otherwise I'll try to fix it as soon as I have time.
Yeah so the problem here is that we have TypeKind::Macro which forces all macros to live at the root. Given a Def or a Res, how do I tell if a macro is MBE or a newstyle macro? (There's a possibility that our current code actually handles this correctly already and we need to remove the special case for TypeKind::Macro)
Okay so here are the two offending bits of code: The latter is more about linking to these items rather than rendering them. So the problem is that by the time stuff gets to rustdoc, we're looking at the HIR and the two kinds of macros are squashed together on . The newstyle macros are not a variant of at all, they disappear from the HIR tree at that point and only exist as an array on the crate. It would be nice if MBEs stayed on and newstyle macros were actually Items or at least stored separately on the module.

We could handle these as we see their containing module, but that seems prone to issues when there are reexports and private modules in the mix. I think having newstyle macros live on rather than is a mistake.
An option to do this purely in rustdoc would be to check the and insert it in the appropriate modules after the fact, however this is kinda icky and i don't think this will be the last tooling problem encountered by newstyle macros living at the crate root in HIR.
will probably know best how to interpret this information; somehow macro name resolution also has to work with this, after all.
I don't think name resolution actually operates on the hir that way. But yeah, worth letting him answer.
I think you can recover the module they came from using the on it.
You can tell whether it's a macro or a by looking at .