Change:
let parent_scope = resolver.dummy_parent_scope(); if let Ok(def) = resolver.resolve_macro_to_def_inner(&path, MacroKind::Bang, &parent_scope, false, false) { <del> if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); </del> <ins> if let Def::Macro(_, MacroKind::ProcMacroStub) = def { // skip proc-macro stubs, they'll cause `get_macro` to crash } else { if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); } </ins> } } if let Some(def) = resolver.all_macros.get(&Symbol::intern(path_str)) {

Discussion:
The following code builds successfully but causes a compiler panic when running : Compiler error Toolchain Changing to another name, either in the doc comment or the actual function name (but not both), causes to succeed with a warning that the link cannot be resolved, as expected. Using a normal public function in a non-procmacro library also does not cause a panic, e.g.
Same stack trace as .
Good find. That one is also a procedural macro, might be appropriate to add a label to both.
Doing a little digging... The first rustdoc code in that stack trace is this part in , which attempts to load up a macro definition for the given path text: The call to successfully returns a Def, but it's the call to that's ultimately failing. The reasoning behind this can be explained in the function, which we're not calling, but handles the same code with a bit more overhead. In that function, there's a branch that gives me a hint to what's going on: In effect: proc-macros are not available to the crate that defines them. This makes sense in terms of making sure they don't infinitely recurse, but leaves rustdoc out to dry when all it wants is to make sure that the macro in question is a Macros 2.0 macro. I'm waiting on a build right now, but we may be able to skip the call to by looking at the Def returned by and seeing whether it's a . That way, we can handle those differently and avoid the problematic call to .
Update: Skipping the call to for macros of kind seems to have fixed this issue! I've opened to fix this.

When I run on (branch refactor-datatypes) I receive an internal compiler error. Everything works fine on stable (). Also everything works if I remove the links in the doc comments. : Backtrace:
I removed the links in the latest commits so I can document on nightly. The latest commit that still contains the links is: Lythenas/rust-orgmode
I experimented a little more and found the following: When I have a doc comment with one link everything works: Also when specifying the link target it works: When there is more than one link in one doc comment the compiler panics: Even when one of them has a link target: But it works when both links have a target: Also this does not happen in the main crate only in the sub-crate. I followed the proc macro guide in the book and created a subfolder named "rust-orgmode-derive. And in the of the main crate I to the dependencies.
I just tried to document that commit you linked with , and it did not give the same ICE. It looks like this issue has been fixed?
With the above commit I still get the same error using .
I'm afraid i'm not seeing it. Is this the right commit?
Aha! I looked again and it turns out i'm documenting the wrong crate. It looks like fixes this issue as well!
Sorry I forgot to mention that you have to swap two lines to get it to compile. Because now you have to put attributes before derive, which was not the case when I wrote this. But thanks for fixing this :+1: