Stream: t-compiler/rust-analyzer

Topic: What is needed for supporting attribute proc macro?


Charles Lew (Sep 17 2020 at 10:51, on Zulip):

I'm seeking for some low hanging fruit to get my hands wet.

Jonas Schievink [he/him] (Sep 17 2020 at 10:52, on Zulip):

Heh, I wouldn't call this low-hanging :)

Jonas Schievink [he/him] (Sep 17 2020 at 10:55, on Zulip):

Attribute macros have to integrate with name resolution, since we can't add an item that still has unresolved attributes on it (they could be macros that change/delete the item).

I guess a relatively simple thing to do would be to extend name resolution to look at attributes, and to somehow add rustc's list of built-in attributes to rust-analyzer. I'm not totally sure what the best way to do that is, since they can change in arbitrary ways between nightly releases.

Charles Lew (Sep 17 2020 at 13:46, on Zulip):

Thanks! So i think i needs to deal with builtin attributes first. One thing that annoys me a little is that i'm almost using thiserror in every crate i writes, but rust-analyzer currently cannot auto-complete thiserror::Error for me. So i think i'll start from supporting proc_macro_derive attribute first.

Charles Lew (Sep 17 2020 at 13:49, on Zulip):

So this code in thiserror:

#[proc_macro_derive(Error, attributes(backtrace, error, from, source))]
pub fn derive_error(input: TokenStream) -> TokenStream {
    let input = parse_macro_input!(input as DeriveInput);
    expand::derive(&input)
        .unwrap_or_else(|err| err.to_compile_error())
        .into()
}

is a function and provides a "Derive Macro" at the same time

Jonas Schievink [he/him] (Sep 17 2020 at 13:49, on Zulip):

Ah, yeah, that's because name resolution of proc macros isn't done by rust-analyzer, but by querying Cargo and the proc-macro server, so it doesn't integrate well. I've been meaning to change that, but IIRC @\matklad had objections.

Charles Lew (Sep 17 2020 at 13:51, on Zulip):

ok...

Charles Lew (Sep 17 2020 at 13:53, on Zulip):

But i think proc_macro_derive itself is not a proc-macro but a builtin attribute? Do we want to see it as a proc_macro itself in ra?

Jonas Schievink [he/him] (Sep 17 2020 at 13:57, on Zulip):

No, that should be built-in

Jonas Schievink [he/him] (Sep 17 2020 at 13:58, on Zulip):

We have to add the name used in that attribute to the name resolution scope

Charles Lew (Sep 17 2020 at 13:58, on Zulip):

yeah

Charles Lew (Sep 17 2020 at 14:01, on Zulip):

I imagine this would be enough for Error to come out when auto-completion.

Charles Lew (Sep 17 2020 at 14:07, on Zulip):

So, if i do this change, should i create a builtin_attribute.rs module under hir_expand?

Jonas Schievink [he/him] (Sep 17 2020 at 14:09, on Zulip):

That's one way to do it, yeah. rustc has a file like that, and it would be nice to have a way to keep them in sync more easily, but that can be done later.

Charles Lew (Sep 17 2020 at 14:23, on Zulip):

Thanks, i'll experiment to see what i can get :)

Kirill Bulatov (Sep 17 2020 at 16:09, on Zulip):

In case you want to get closer to practice, one good implication of that would be the attribute completion: currently it's all hardcoded.

Jonas Schievink [he/him] (Sep 17 2020 at 17:30, on Zulip):

Yeah, would be neat to find some way to load attribute and lint names from the sysroot at some point. But first this info has to actually be shipped through rustup.

Jonas Schievink [he/him] (Sep 17 2020 at 17:32, on Zulip):

(I noticed that the new "unresolved import" diagnostics are quite intrusive when macros are being imported, so maybe I'll come up with a fix for that, or mark them as experimental)

Charles Lew (Sep 17 2020 at 17:50, on Zulip):

I'm tracing through the code, and found that... it seems to me that, to properly support attributes, i'll need to "detach" the current derive-supporting code, implement builtin attributes dispatching, and then "reattach" the derive(..) support to it as a special case...

Charles Lew (Sep 17 2020 at 17:52, on Zulip):

does nameres stand for name resolution? it seems it's actually doing most of the expansion work

Jonas Schievink [he/him] (Sep 17 2020 at 18:14, on Zulip):

Charles Lew said:

does nameres stand for name resolution? it seems it's actually doing most of the expansion work

yeah, it should call into other crates to expand any macros

Jonas Schievink [he/him] (Sep 18 2020 at 15:53, on Zulip):

I've been working on the name resolution changes for proc macros I mentioned: https://github.com/rust-analyzer/rust-analyzer/pull/6033

Last update: Jul 28 2021 at 04:30UTC