Rust: return of #39347: feature(proc_macro) breaks attributes on custom derive

[kardeiz]

Recent versions of Rust nightly seem to have the exact same issue as initially reported in #39347 (albeit with a slightly different error message: e.g., error: cannot find attribute macrobelongs_toin this scope).

See the recent comment on #39347 by LukasKalbertodt for more details.

I know nothing about Rust's internals, but it seems like the issue is overzealous checking by proc_macro in https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/macros.rs#L587.

[kardeiz]

This just got a whole lot more confusing (to me at least). I just discovered that I can successfully use serde's proc_macro_derive attributes, but not Diesel's.

So for example, evesteras's serde example in #39347 compiles fine, but LukasKalbertodt's Diesel example does not. This is within the same project, so rustc/cargo/enabled features, etc. are exactly the same.

I'm not familiar enough with the whole proc_macro environment to get what serde and Diesel are doing differently. Considering that Diesel's derive attributes work fine when the proc_macro feature is not enabled, it doesn't really seem like a bug in Diesel (although maybe there is a way to work around it)?

[kardeiz]

I looked into this a little more. When using Diesel, it is common for specific structs to derive multiple Diesel-related traits (e.g., Queryable, Identifiable, Insertable). These may each have their own permitted attributes (e.g. table_name, belongs_to). However, when proc_macro is enabled, it looks like only the first permitted attribute is let through—the others lead to the compilation error above.

This could be fixed by "namespacing"the attributes (e.g., #[diesel(table_name="something")]) or by listing out each potential attribute that might be used on a specific struct. So I guess this might not be a bug per se, but it will cause problems for at least some libraries if it goes forward like this.

[TheNeikos]

I have also his this issue

[flosse]

Are there any workarounds?

[kardeiz]

What I am doing to work around this is setting my project up as a workspace. I have all of my project in one main crate (in which I am using the proc_macro feature), except for my database stuff (since in my case Diesel is the only thing hitting this issue), which I am putting in a db subcrate (in which I do not use the proc_macro feature). This resolves the issue for me, and isn't too painful or clunky.

[flosse]

@kardeiz thanks for your help! I'll try to do the same :)

[sgrif]

This is still an issue on the most recent nightlies

[steveklabnik]

I cannot reproduce this issue today, and it's been over a year since the last comment. I'm going to give this a close, but let me know if I'm missing something!