Add a #[serde(crate_name = "…")] attribute

[SimonSapin]

servo/rust-url#327 proposes depending on multiple versions of serde at the same time, in order to add support for new (semver-incompatible) versions without removing support for old ones (which would be a breaking change). This is done by not depending on the serde crate directly, but depending on serde1 which itself depends on serde = "1.0" and re-exports pub use serde::*;.

However this prevents using derive because the code generated by derive includes its own extern crate serde;. I’d like an attribute to be added to control the name of the crate in the generated extern crate code. Something like:

#[derive(Serialize, Deserialize)]
#[serde(crate_name = "serde1")]
enum {
    Foo,
    Bar(u32),
    Baz(String),
}

[SimonSapin]

Attribute parsing happens in serde_derive_internals/src/attr.rs. The relevant generated code is generated in serde_derive/src/ser.rs and serde_derive/src/de.rs.

Before writing code though, I wanted to write a test case. It likely needs to be a separate crate so that a serde1 dependency is available but serde is not. @dtolnay, where in the repository should that directory go? What should I add to travis.sh?

[dtolnay]

I would test this by adding a crate alt_serde in test_suite/alt_serde that contains a pared down version of the serde traits (only the traits and method needed for the test to pass), and a case in test_suite/tests/test_gen.rs that derives impls for alt_serde and checks that the type implements Serialize and Deserialize from alt_serde. Then no change needs to be made to travis.sh.

That said, I am not quite ready to commit to a crate_name attribute.

If you put this attribute on any type in your crate, chances are you want it on every type that derives Serialize or Deserialize. Repeating it for a crate with lots of types will be obnoxious. Something like a macro might be better fit here - where serde_derive emits "extern_crate_serde!()" instead of "extern crate serde" so you can override it globally for your crate by overriding that macro. We would need to evaluate whether this is forward compatible with proc macro hygiene, and how scoping would work in the event that you do want to use different serde crates for different types in your crate.

As an attribute I would prefer #[serde(crate = "serde1")] over crate_name. This would require updating the version of syn (or a workaround).

I would also like to consider not just crate names but paths to where to find the serde crate - similar to how with accepts a crate name like "url_serde" as well as a path to a module that contains the right methods.

[dtolnay]

Closing because I don't intend to address this by adding a new attribute. For the url crate I would prefer to drop serde_derive and provide handwritten impls using their local name for the serde crate. More generally closing in favor of rust-lang/rust#54363 to centralize the discussion around referring to specific crates from the output of a proc macro.

[elichai]

@dtolnay I think this can be half solved by ditching the extern crate serde as _serde in favor of use serde as _serde, that way I can rename serde back to serde inside of the code using features and this should work.

#856 (comment)

[Xanewok]

For future code archaeologists, this seems to implemented and superseded by #1499 (#[serde(crate = "...")]).