mikros/serde
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Re-export is no longer just for optional serde cfg

Browse Source
This commit is contained in:
David Tolnay 2019-01-18 00:48:05 -08:00
parent face857d5e
commit 9ec68e5829
No known key found for this signature in database
GPG Key ID: F9BA143B95FF6D82
2 changed files with 1 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
serde/Cargo.toml
View File

@ -32,30 +32,7 @@ features = ["derive", "rc"]
[features] [features]
default = ["std"] default = ["std"]
# Re-export the derive(Serialize, Deserialize) macros. This is intended for # Provide derive(Serialize, Deserialize) macros.
# library crates that provide optional Serde impls behind a Cargo cfg of their
# own.
#
# Mainly this is a workaround for limitations associated with
# rust-lang/cargo#1286 in which a library crate cannot use one "serde" cfg in
# Cargo to enable dependencies on both serde and serde_derive crates.
#
# The recommended way to provide optional Serde support that requires derive is
# as follows. In particular, please do not name your library's Serde feature
# anything other than "serde".
#
# [dependencies]
# serde = { version = "1.0", optional = true, features = ["derive"] }
#
# Within the library, these optional Serde derives would be written like this.
#
# #[cfg(feature = "serde")]
# #[macro_use]
# extern crate serde;
#
# #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
# struct ...
#
derive = ["serde_derive"] derive = ["serde_derive"]
# Provide impls for common standard library types like Vec<T> and HashMap<K, V>. # Provide impls for common standard library types like Vec<T> and HashMap<K, V>.

34
serde/src/lib.rs
View File

@ -252,40 +252,6 @@ pub mod private;
// Re-export #[derive(Serialize, Deserialize)]. // Re-export #[derive(Serialize, Deserialize)].
// //
// This is a workaround for https://github.com/rust-lang/cargo/issues/1286.
// Without this re-export, crates that put Serde derives behind a cfg_attr would
// need to use some silly feature name that depends on both serde and
// serde_derive.
//
// [features]
// serde-impls = ["serde", "serde_derive"]
//
// [dependencies]
// serde = { version = "1.0", optional = true }
// serde_derive = { version = "1.0", optional = true }
//
// # Used like this:
// # #[cfg(feature = "serde-impls")]
// # #[macro_use]
// # extern crate serde_derive;
// #
// # #[cfg_attr(feature = "serde-impls", derive(Serialize, Deserialize))]
// # struct S { /* ... */ }
//
// The re-exported derives allow crates to use "serde" as the name of their
// Serde feature which is more intuitive.
//
// [dependencies]
// serde = { version = "1.0", optional = true, features = ["derive"] }
//
// # Used like this:
// # #[cfg(feature = "serde")]
// # #[macro_use]
// # extern crate serde;
// #
// # #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
// # struct S { /* ... */ }
//
// The reason re-exporting is not enabled by default is that disabling it would // The reason re-exporting is not enabled by default is that disabling it would
// be annoying for crates that provide handwritten impls or data formats. They // be annoying for crates that provide handwritten impls or data formats. They
// would need to disable default features and then explicitly re-enable std. // would need to disable default features and then explicitly re-enable std.