Merge #6033

6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink

This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports).

This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved").

I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed).

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763

Co-authored-by: Jonas Schievink <[email protected]>

1 files changed, 25 insertions, 14 deletions

diff --git a/crates/hir_expand/src/proc_macro.rs b/crates/hir_expand/src/proc_macro.rs
index 80255ea32..7505cb061 100644
--- a/crates/hir_expand/src/proc_macro.rs
+++ b/crates/hir_expand/src/proc_macro.rs
@@ -7,7 +7,7 @@ use tt::buffer::{Cursor, TokenBuffer};
 #[derive(Debug, Clone, Copy, Eq, PartialEq, Hash)]
 pub struct ProcMacroExpander {
     krate: CrateId,
-    proc_macro_id: ProcMacroId,
+    proc_macro_id: Option<ProcMacroId>,
 }
 
 macro_rules! err {
@@ -20,8 +20,14 @@ macro_rules! err {
 }
 
 impl ProcMacroExpander {
-    pub fn new(krate: CrateId, proc_macro_id: ProcMacroId) -> ProcMacroExpander {
-        ProcMacroExpander { krate, proc_macro_id }
+    pub fn new(krate: CrateId, proc_macro_id: ProcMacroId) -> Self {
+        Self { krate, proc_macro_id: Some(proc_macro_id) }
+    }
+
+    pub fn dummy(krate: CrateId) -> Self {
+        // FIXME: Should store the name for better errors
+        // FIXME: I think this is the second layer of "dummy" expansion, we should reduce that
+        Self { krate, proc_macro_id: None }
     }
 
     pub fn expand(
@@ -30,17 +36,22 @@ impl ProcMacroExpander {
         _id: LazyMacroId,
         tt: &tt::Subtree,
     ) -> Result<tt::Subtree, mbe::ExpandError> {
-        let krate_graph = db.crate_graph();
-        let proc_macro = krate_graph[self.krate]
-            .proc_macro
-            .get(self.proc_macro_id.0 as usize)
-            .clone()
-            .ok_or_else(|| err!("No derive macro found."))?;
-
-        let tt = remove_derive_attrs(tt)
-            .ok_or_else(|| err!("Fail to remove derive for custom derive"))?;
-
-        proc_macro.expander.expand(&tt, None).map_err(mbe::ExpandError::from)
+        match self.proc_macro_id {
+            Some(id) => {
+                let krate_graph = db.crate_graph();
+                let proc_macro = krate_graph[self.krate]
+                    .proc_macro
+                    .get(id.0 as usize)
+                    .clone()
+                    .ok_or_else(|| err!("No derive macro found."))?;
+
+                let tt = remove_derive_attrs(tt)
+                    .ok_or_else(|| err!("Fail to remove derive for custom derive"))?;
+
+                proc_macro.expander.expand(&tt, None).map_err(mbe::ExpandError::from)
+            }
+            None => Err(err!("Unresolved proc macro")),
+        }
     }
 }