Macro expansion bypasses #[derive_*] stability checks.

[eddyb]

One can use macro expansion to bypass all early attribute checks, directly:

macro_rules! evil {
    () => {
        #[derive_Debug]
        struct Foo;
    }
}
evil!();
fn main() {}

Or by using the built-in include! macro.

// foo.rs
#[derive_Debug]
struct Foo; 

include!("foo.rs");
fn main() {}

Found while investigating libpnet breakage.

This affects any use of #[derive(...)] in syntex, as virtually everyone uses include!.
Even though I don't like stabilizing this, there may be too many cases in the wild.

[pnkfelix]

cc #29644

[pnkfelix]

there are different possible outcomes for what we do here, depending on how hard it is to come up with a fix (@eddyb may already have one in the works), and what the impact of such a fix is according to crater.

[pnkfelix]

(assigning P-high to reflect the priority of deciding what to do.)

[eddyb]

Attempt at a fix and crater results can be found at #32671.
It looks like all the regressions are due to serde_codegen - sadly, that doesn't count crates which weren't compiling anyway (like pnet, where I observed this issue, which would compile if syntex were fixed).

In IRC @durka and I looked at the crates that depend on syntex and while most of them could be fixed by releasing a new version, pnet of all things has the serde version pinned, without even allowing patch releases.

And that doesn't count anyone who has a Cargo.lock around. The whole reason they're using syntex is to escape instability.

Some food for thought: @nrc's macro plans could eventually allow for #[derive(foo::Bar)]. At first you might think #[derive_foo::Bar] just doesn't work, and you'd be right, but what about #[foo::derive_Bar]?

It's not the worst that could happen, and I haven't seen specific plans for making #[derive] pluggable, other than that "template-based" scheme @Manishearth and I were discussing, which would still work fine (#[derivable(...)] trait Foo {...} on the trait would simply produce a derive_Foo attribute).

Note that you can't use #[derive] with non-builtin traits anyway without using a plugin, which is unstable, so the #[derive(SomeCustomTrait)] gating is pretty pointless by itself (and my tentative fix doesn't apply to it).
You could instead gate registering #[derive_*] decorator plugins, if you really wanted to.

That said, I leave this to @rust-lang/lang to decide. Do we just upload a new version of serde and/or do we ungate #[derive_*]?
I would personally do both (given the future-compatibility point above) and warn when #[derive_*] doesn't come from the compiler, just to make sure, but that's a bit overkill.

[mrmonday]

Chiming in, as primary libpnet author:

• Syntex is pinned because each release can break the API, causing the build to fail - it gets updated whenever I get around to it, and that doesn't necessarily imply a new cargo release (the cargo release process isn't streamlined yet, so happens when I have time or someone asks nicely)
• libpnet hasn't hit 1.0 yet, so breaking things isn't the worst thing, though I would rather it didn't happen.

Please contact me whenever about this - I believe Dropbox is using some subset of libpnet, but I don't know exact details.

I suspect there's a nice way to deal with this (at least in terms of libpnet), though I admittedly haven't been following particularly closely.