Links in doc comments to proc_macro_attribute functions cause rustdoc panic

[antonok-edm]

The following code builds successfully but causes a compiler panic when running cargo doc:
src/lib.rs

extern crate proc_macro;

/// [function_name]
#[proc_macro_attribute]
pub fn function_name(_attr: proc_macro::TokenStream, item: proc_macro::TokenStream) -> proc_macro::TokenStream {
    item
}

Cargo.toml

[package]
name = "causes-rustdoc-panic"
version = "0.1.0"

[lib]
proc-macro = true

Compiler error

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:355:21

Toolchain

rustc 1.31.0-nightly (4bd4e4130 2018-10-25) running on x86_64-unknown-linux-gnu

Changing function_name to another name, either in the doc comment or the actual function name (but not both), causes cargo doc to succeed with a warning that the link cannot be resolved, as expected.

Using a normal public function in a non-proc_macro library also does not cause a panic, e.g.

/// [function_name]
#[inline]
pub fn function_name(_attr: u8, item: u8) -> u8 {
    item
}

[euclio]

Same stack trace as #54100.

[antonok-edm]

@euclio Good find.

That one is also a procedural macro, might be appropriate to add a macro label to both.

[QuietMisdreavus]

Doing a little digging...

The first rustdoc code in that stack trace is this part in macro_resolve, which attempts to load up a macro definition for the given path text:

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Lines 432 to 437 in 9690917

	if let Ok(def) = resolver.resolve_macro_to_def_inner(&path, MacroKind::Bang,
	&parent_scope, false, false) {
	if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) {
	return Some(def);
	}
	}

The call to resolve_macro_to_def_inner successfully returns a Def, but it's the call to get_macro that's ultimately failing. The reasoning behind this can be explained in the resolve_macro_to_def 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:

rust/src/librustc_resolve/macros.rs

Lines 295 to 302 in 9690917

	Def::Macro(def_id, macro_kind) => {
	self.unused_macros.remove(&def_id);
	if macro_kind == MacroKind::ProcMacroStub {
	let msg = "can't use a procedural macro from the same crate that defines it";
	self.session.span_err(path.span, msg);
	return Err(Determinacy::Determined);
	}
	}

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 get_macro by looking at the Def returned by resolve_macro_to_def_inner and seeing whether it's a ProcMacroStub. That way, we can handle those differently and avoid the problematic call to get_macro.

[QuietMisdreavus]

Update: Skipping the call to get_macro for macros of kind ProcMacroStub seems to have fixed this issue! I've opened #57846 to fix this.