Greatly shrinks symbol sizes: keep all those generic type parameters
(and even closures) out of symbol names. A good change even independent
of serde_core.
Even for a simple data structure that would ordinarily expand to an impl
that only refers to the public Serde traits without serde::__private, we
still disallow a (renamed) serde_core dependency. This leaves the
liberty to new usage of private helpers in such impls over time. For
example, similar to the optimization of the standard library's
derive(Debug) that introduced debug_struct_field1_finish to improve
compile time of derived impls.
This prevents diagnostics being rendered like `serde_core::ser::Serialize`
and `serde_core:🇩🇪:Deserialize` in projects that have no direct
dependency on serde_core.
The attributes make error messages arguably sometimes worse than
pre-serde_core by always rendering `serde::Serialize` and never
`Serialize` when `use serde::Serialize` is in scope, which rustc's
default message construction knows to recognize. But this is probably
negligible.
I explored the alternative of setting `[lib] name = "serde"` in
serde_core/Cargo.toml which also prevents `serde_core::ser::Serialize`
in messages, but has the unwanted effect of also inserting the following
noise into every such error:
note: there are multiple different versions of crate `serde` in the dependency graph
--> $WORKSPACE/serde_core/src/ser/mod.rs:225:1
|
225 | pub trait Serialize {
| ^^^^^^^^^^^^^^^^^^^ this is the required trait
|
::: src/main.rs:1:1
|
1 | struct MyStruct;
| --------------- this type doesn't implement the required trait
...
4 | let _ = serde_json::to_string(&MyStruct);
| ----------
| |
| one version of crate `serde` used here, as a dependency of crate `serde`
| one version of crate `serde` used here, as a dependency of crate `serde_json`
|
::: $WORKSPACE/serde/src/private/de.rs:2347:1
|
2347 | pub trait IdentifierDeserializer<'de, E: Error> {
| ----------------------------------------------- this is the found trait
= help: you can use `cargo tree` to explore your dependency tree
The "this is the found trait" pointing to `IdentifierDeserializer` seems
like a compiler bug...
