|  | 
| 1 |  | -//! Deserialization of a `Value<T>` type which tracks where it was deserialized | 
| 2 |  | -//! from. | 
|  | 1 | +//! Deserialization of a [`Value<T>`] type which tracks where it was deserialized from. | 
|  | 2 | +//! | 
|  | 3 | +//! ## Rationale for `Value<T>` | 
| 3 | 4 | //! | 
| 4 | 5 | //! Often Cargo wants to report semantic error information or other sorts of | 
| 5 | 6 | //! error information about configuration keys but it also may wish to indicate | 
|  | 
| 8 | 9 | //! from configuration, but also record where it was deserialized from when it | 
| 9 | 10 | //! was read. | 
| 10 | 11 | //! | 
|  | 12 | +//! ## How `Value<T>` deserialization works | 
|  | 13 | +//! | 
| 11 | 14 | //! Deserializing `Value<T>` is pretty special, and serde doesn't have built-in | 
| 12 | 15 | //! support for this operation. To implement this we extend serde's "data model" | 
| 13 | 16 | //! a bit. We configure deserialization of `Value<T>` to basically only work with | 
| 14 | 17 | //! our one deserializer using configuration. | 
| 15 | 18 | //! | 
| 16 | 19 | //! We define that `Value<T>` deserialization asks the deserializer for a very | 
| 17 |  | -//! special struct name and struct field names. In doing so the deserializer will | 
| 18 |  | -//! recognize this and synthesize a magical value for the `definition` field when | 
| 19 |  | -//! we deserialize it. This protocol is how we're able to have a channel of | 
| 20 |  | -//! information flowing from the configuration deserializer into the | 
| 21 |  | -//! deserialization implementation here. | 
|  | 20 | +//! special [struct name](NAME) and [struct field names](FIELDS). In doing so, | 
|  | 21 | +//! the deserializer will recognize this and synthesize a magical value for the | 
|  | 22 | +//! `definition` field when we deserialize it. This protocol is how we're able | 
|  | 23 | +//! to have a channel of information flowing from the configuration deserializer | 
|  | 24 | +//! into the deserialization implementation here. | 
| 22 | 25 | //! | 
| 23 | 26 | //! You'll want to also check out the implementation of `ValueDeserializer` in | 
| 24 |  | -//! `de.rs`. Also note that the names below are intended to be invalid Rust | 
| 25 |  | -//! identifiers to avoid how they might conflict with other valid structures. | 
| 26 |  | -//! Finally the `definition` field is transmitted as a tuple of i32/string, which | 
| 27 |  | -//! is effectively a tagged union of `Definition` itself. | 
|  | 27 | +//! the [`de`] module. Also note that the names below are intended to be invalid | 
|  | 28 | +//! Rust identifiers to avoid conflicts with other valid structures. | 
|  | 29 | +//! | 
|  | 30 | +//! Finally the `definition` field is transmitted as a tuple of i32/string, | 
|  | 31 | +//! which is effectively a tagged union of [`Definition`] itself. You should | 
|  | 32 | +//! update both places here and in the impl of [`serde::de::MapAccess`] for | 
|  | 33 | +//! `ValueDeserializer` when adding or modifying enum variants of [`Definition`]. | 
|  | 34 | +//! | 
|  | 35 | +//! [`de`]: crate::util::context::de | 
| 28 | 36 | 
 | 
| 29 | 37 | use crate::util::context::GlobalContext; | 
| 30 | 38 | use serde::de; | 
|  | 
0 commit comments