j7s_diagnostics_py/vendor/serde_core
James Pace 91e18fde3a Vendor deps. 2026-09-16 20:10:35 -04:00
..
src Vendor deps. 2026-09-16 20:10:35 -04:00
.cargo-checksum.json Vendor deps. 2026-09-16 20:10:35 -04:00
.cargo_vcs_info.json Vendor deps. 2026-09-16 20:10:35 -04:00
Cargo.lock Vendor deps. 2026-09-16 20:10:35 -04:00
Cargo.toml Vendor deps. 2026-09-16 20:10:35 -04:00
Cargo.toml.orig Vendor deps. 2026-09-16 20:10:35 -04:00
LICENSE-APACHE Vendor deps. 2026-09-16 20:10:35 -04:00
LICENSE-MIT Vendor deps. 2026-09-16 20:10:35 -04:00
README.md Vendor deps. 2026-09-16 20:10:35 -04:00
build.rs Vendor deps. 2026-09-16 20:10:35 -04:00

README.md

The serde_core crate contains Serde's trait definitions with no support for #[derive()].

In crates that derive an implementation of Serialize or Deserialize, you must depend on the serde crate, not serde_core.

In crates that handwrite implementations of Serde traits, or only use them as trait bounds, depending on serde_core is permitted. But serde re-exports all of these traits and can be used for this use case too. If in doubt, disregard serde_core and always use serde.

Crates that depend on serde_core instead of serde are able to compile in parallel with serde_derive even when serde's "derive" feature is turned on, as shown in the following build timings.


When serde_json depends on serde

When serde_json depends on serde_core