-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature(proc_macro) breaks attributes on custom derive #39347
Comments
cc @jseyfried |
@jseyfried I think I have an idea where to start on this but I'll need some guidance. |
This raises the following question: // Given a `#[proc_macro_attribute]` `foo`
use attrs::foo;
// and a custom derive `#[proc_macro_derive(Trait, attributes(foo))]`,
use derives::Trait;
#[derive(Trait)] #[foo] struct A; // (1)
#[foo] #[derive(Trait)] struct B; // (2) Should
For (1), the scope could be (b) or (c) -- I weakly prefer (b). For (2), the scope could be (a), (b), or (c) in descending order of my preference. |
Hmm, I would go for 'd' in both cases (the user has explicitly imported the name, whereas the inert attr is implicit from the user's POV). But it sounds like this can't be done. In which case I prefer 'b' for (1) because this feels like the least silent failure. And 'a' for (2) since it looks out of scope for the derive. In both cases the user can address the issue by renaming the import (which is good). |
We decided to
|
@jseyfried I'm ready to get started working on this but I'm not sure where to start. |
Fixed in #39572. |
macros: fix inert attributes from `proc_macro_derives` with `#![feature(proc_macro)]` This PR refactors collection of `proc_macro_derive` invocations to fix #39347. After this PR, the input to a `#[proc_macro_derive]` function no longer sees `#[derive]`s on the underlying item. For example, consider: ```rust extern crate my_derives; use my_derives::{Trait, Trait2}; #[derive(Copy, Clone)] #[derive(Trait)] #[derive(Trait2)] struct S; ``` Today, the input to the `Trait` derive is `#[derive(Copy, Clone, Trait2)] struct S;`, and the input to the `Trait2` derive is `#[derive(Copy, Clone)] struct S;`. More generally, a `proc_macro_derive` sees all builtin derives, as well as all `proc_macro_derive`s listed *after* the one being invoked. After this PR, both `Trait` and `Trait2` will see `struct S;`. This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice. r? @nrc
@abonander I think this bug reappeared. Example:
#[macro_use] extern crate diesel;
#[macro_use] extern crate diesel_codegen;
table!(
sessions(id) {
id -> Integer,
user_id -> Integer,
}
);
table!(
users(id) {
id -> Integer,
}
);
#[derive(Debug, Clone, Eq, PartialEq, Identifiable, Queryable, Associations)]
#[belongs_to(User)]
pub struct Session {
id: i64,
pub user_id: i64,
}
#[derive(Debug, Clone, Eq, PartialEq, Identifiable, Queryable)]
pub struct User {
pub id: i64,
}
fn main() {} The above compiles. But when adding
Tested with Or is this something else? |
@jseyfried would know more about this one. I never actually started on it. |
I am also encountering the issue/bug described by @LukasKalbertodt above, in almost exactly the same context, with a recent nightly |
Using
#![feature(proc_macro)]
in combination with attributes enabled by#[proc_macro_derive(MyTrait, attributes(mycrate))]
(e.g.#[mycrate(some_option = "something")]
) fails to compile on the current nightly witherror: macro undefined: 'mycrate!'
.Definition of custom derive:
Use which fails:
If
#![feature(proc_macro)]
is removed, compilation succeeds.Compiling the above fails with the following output:
Compilation fails on current nightly:
However, compilation succeeds on a week old nightly:
This is probably connected to
#[proc_macro_attribute]
which was merged in this timeframe (PR), and not the feature flag itself.serde_derive-based example failing the same way:
The text was updated successfully, but these errors were encountered: