serde_macros incompatible with extern crate serde not in toplevel module

[whitequark]

To reproduce:

#![plugin(serde_macros)]
#![feature(plugin, custom_derive)]

mod x {
    extern crate serde;
    #[derive(Serialize)] struct S;
}

fn main() {}

[erickt]

Unfortunately I'm not sure if there's much we can do in this circumstance. I'm not sure if it's possible to resolve the location of the serde crate, so the most reliable location to find it is in the toplevel crate namespace.

[whitequark]

Hm, good point. This might be worth bringing up whenever custom derivers are being stabilized.

[erickt]

It's worse than that, I think we need name resolution to happen in order to find where the serde crate was imported, which may not get exposed to compiler plugins for a long time :(

[whitequark]

What if you did something like expanding it to...

mod internal {
  extern crate serde;
  impl serde::whatever for dunno {}
}
use internal::*;

but cleaner? Basically, hygiene for crate imports.

[grncdr]

hm, am I correct in understanding that #[derive(Serialize)] essentially won't work anywhere outside of the top-level of a crate? I was trying to derive these traits in a child module (e.g. separate file) and it seemed impossible to convince the compiler that the implementation was there.

[dtolnay]

@grncdr

hm, am I correct in understanding that #[derive(Serialize)] essentially won't work anywhere outside of the top-level of a crate? I was trying to derive these traits in a child module (e.g. separate file) and it seemed impossible to convince the compiler that the implementation was there.

It should work as long as extern crate serde is at the top level of your crate. The reason is the generated code expects to be able to use absolute paths like ::serde::ser::Serialize.

The following works for me:

#![feature(plugin, custom_derive)]
#![plugin(serde_macros)]

extern crate serde;

mod m {
    #[derive(Serialize)]
    pub struct Success;
}

fn main() {
    fn assert<T: serde::Serialize>(_: T) {}
    assert(m::Success);
}

[grncdr]

Thanks @dtolnay

[dtolnay]

In line with @whitequark's idea, I started implementing this as:

mod m {
    struct A { ... }
    #[derive(Serialize)]
    struct B { a: A }
}

// -->

mod m {
    struct A { ... }
    struct B { a: A }
    mod B_Serialize {
        use /* ??? */;
        extern crate serde;
        impl serde::Serialize for B { ... }
    }
}

I ran into trouble on the line marked ???. Without a use declaration, A and B are not in scope. Ideally I think I would want to write use super::* but that only seems to bring in public items so it only works if B is pub.

It works if I do use super::{A, B} so I guess we need to traverse the definition of B to figure out the individual things to import into B_Serialize. This is going to be nasty so let me know if anyone has a better idea. In particular, we will need to differentiate among:

1. Things we need to use, like A and B,
2. Generic type parameters like T, do not use.
3. Builtin types like isize, do not use.
4. Prelude types like Result, may need to use if prelude is disabled.

As far as I know, all of these "look" identical during macro expansion so it will be tricky to differentiate.

[dtolnay]

I think I have a much more promising approach. Apparently this is allowed...

const _IMPL_DESERIALIZE_FOR_S: () = {
    extern crate serde as _serde;
    impl _serde::Deserialize for S {
        // ...
    }
};

and it is way nicer than using a module to declare the impl because it does not affect the scope of imports.

I will work on a PR today.

[dtolnay]

@whitequark @erickt @oli-obk this was addressed in #298 and can be closed.

[oli-obk]

thanks @dtolnay

[dtolnay]

Unintended consequence: truly awful compiler diagnostics:

the trait bound `uuid::Uuid: Book::model::_IMPL_DESERIALIZE_FOR_Book::_serde::Deserialize` is not satisfied

[oli-obk]

we could probably fix this (in rustc) by checking if a path goes into an external crate, and invent a new display syntax along the lines of <extern crate serde>::Deserialize