Skip to content

Commit 6864752

Browse files
committed
docs(gctx): intra doc links and grammartical fixes for Value
1 parent dad55a6 commit 6864752

File tree

1 file changed

+19
-11
lines changed

1 file changed

+19
-11
lines changed

src/cargo/util/context/value.rs

Lines changed: 19 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,6 @@
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>`
34
//!
45
//! Often Cargo wants to report semantic error information or other sorts of
56
//! error information about configuration keys but it also may wish to indicate
@@ -8,23 +9,30 @@
89
//! from configuration, but also record where it was deserialized from when it
910
//! was read.
1011
//!
12+
//! ## How `Value<T>` deserialization works
13+
//!
1114
//! Deserializing `Value<T>` is pretty special, and serde doesn't have built-in
1215
//! support for this operation. To implement this we extend serde's "data model"
1316
//! a bit. We configure deserialization of `Value<T>` to basically only work with
1417
//! our one deserializer using configuration.
1518
//!
1619
//! 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.
2225
//!
2326
//! 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
2836
2937
use crate::util::context::GlobalContext;
3038
use serde::de;

0 commit comments

Comments
 (0)