This prevents diagnostics being rendered like `serde_core::ser::Serialize`
and `serde_core::de::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...
Allow deprecated in the `Serialize`/`Deserialize`
derive implementations. This allows you to
deprecate structs, enums, struct fields, or enum
variants and not get compiler warnings/errors
about use of deprecated thing. We only do this
if `#[deprecated]` or `#[allow(deprecated)]` exist
on the root object or the variants of the root
object (if it is an enum).
Resolves#2195
- Check that alias is not the same as name of other field (it still can be the name of owning field/variant)
- Check that aliases are unique, i. e. two different fields does not use the same alias
Previously if someone wrote an enum containing:
- `A` (untagged)
- `B` (tagged)
- `C` (tagged)
- `D` (untagged)
- `E` (tagged)
- `F` (untagged)
serde_derive would produce errors referring to B and E only, saying
you're supposed to put untagged variants at the end. The choice of B and
E for this error doesn't make a lot of sense because in order to resolve
the issue, the user must either:
- move A and D down
or:
- move B, C, and E up.
This commit changes the error to appear on A and D instead.
David Tolnay