Procedural macro crates should require at most one definition per macro name

[alexcrichton]

Discovered by @alercah here, this crate should be rejected:

#![crate_type = "proc-macro"]

extern crate proc_macro;

use proc_macro::TokenStream;

#[proc_macro]
pub fn bad(_ : TokenStream) -> TokenStream { "".parse().unwrap() }

#[proc_macro_derive(bad)]
pub fn deriver(_ : TokenStream) -> TokenStream { "".parse().unwrap() }

[alexcrichton]

I believe this would be fixed by @petrochenkov suggestion here where definition of a macro inserts an entry into the macro namespace, although @petrochenkov correct me if I'm wrong!

[petrochenkov]

#[proc_macro_derive(bad)]

The issue solvable by inserting a dummy entry into macro namespace is not about inert attributes in derives, but about this case.

macro foo() {} // Should be future-proofed and report an error

#[proc_macro]
fn foo(...) -> ... { ... }

[petrochenkov]

Stabilization PR for proc macro definitions is in process of merge (#52081), so this should be fixed soon too.

[petrochenkov]

Fixed locally, will submit a PR today.