| 
1 | 1 | # Serialization in Rustc  | 
2 | 2 | 
 
  | 
3 |  | -Rust's compiler has to [serialize] and deserialize various data during  | 
4 |  | -compilation. Specifically:  | 
 | 3 | +rustc has to [serialize] and deserialize various data during compilation.  | 
 | 4 | +Specifically:  | 
5 | 5 | 
 
  | 
6 |  | -- Certain crate metadata, consisting mainly of query outputs, are serialized  | 
 | 6 | +- "Crate metadata", consisting mainly of query outputs, are serialized  | 
7 | 7 |   from a binary format into `rlib` and `rmeta` files that are output when  | 
8 | 8 |   compiling a library crate. These `rlib` and `rmeta` files are then  | 
9 | 9 |   deserialized by the crates which depend on that library.  | 
@@ -36,8 +36,8 @@ types, floating point types, `bool`, `char`, `str`, etc.  | 
36 | 36 | 
 
  | 
37 | 37 | For types that are constructed from those types, `Encodable` and `Decodable`  | 
38 | 38 | are usually implemented by [derives]. These generate implementations that  | 
39 |  | -forward deserialization to the `field`s of the `struct` or `enum`. For a  | 
40 |  | -`struct` those `impl`s look something like this:  | 
 | 39 | +forward deserialization to the fields of the struct or enum. For a  | 
 | 40 | +struct those impls look something like this:  | 
41 | 41 | 
 
  | 
42 | 42 | ```rust,ignore  | 
43 | 43 | #![feature(rustc_private)]  | 
@@ -73,14 +73,13 @@ impl<D: Decoder> Decodable<D> for MyStruct {  | 
73 | 73 | 
 
  | 
74 | 74 | ## Encoding and Decoding arena allocated types  | 
75 | 75 | 
 
  | 
76 |  | -Rust's compiler has a lot of [arena allocated types]. Deserializing these types  | 
77 |  | -isn't possible without access to the `arena` that they need to be allocated on.  | 
78 |  | -The [`TyDecoder`] and [`TyEncoder`] `trait`s are supertraits of [`Decoder`] and  | 
79 |  | -[`Encoder`] that allow access to a [`TyCtxt`].  | 
 | 76 | +rustc has a lot of [arena allocated types].  | 
 | 77 | +Deserializing these types isn't possible without access to the arena that they need to be allocated on.  | 
 | 78 | +The [`TyDecoder`] and [`TyEncoder`] traits are supertraits of [`Decoder`] and [`Encoder`] that allow access to a [`TyCtxt`].  | 
80 | 79 | 
 
  | 
81 |  | -Types which contain `arena` allocated types can then bound the type parameter  | 
82 |  | -of their [`Encodable`] and [`Decodable`] implementations with these `trait`s. For  | 
83 |  | -example  | 
 | 80 | +Types which contain `arena` allocated types can then bound the type parameter of their  | 
 | 81 | +[`Encodable`] and [`Decodable`] implementations with these traits.  | 
 | 82 | +For example  | 
84 | 83 | 
 
  | 
85 | 84 | ```rust,ignore  | 
86 | 85 | impl<'tcx, D: TyDecoder<'tcx>> Decodable<D> for MyStruct<'tcx> {  | 
@@ -149,7 +148,7 @@ and `Encodable`.  | 
149 | 148 | `Ty` can be deeply recursive, if each `Ty` was encoded naively then crate  | 
150 | 149 | metadata would be very large. To handle this, each `TyEncoder` has a cache of  | 
151 | 150 | locations in its output where it has serialized types. If a type being encoded  | 
152 |  | -is in cache, then instead of serializing the type as usual, the byte offset  | 
 | 151 | +is in the cache, then instead of serializing the type as usual, the byte offset  | 
153 | 152 | within the file being written is encoded instead. A similar scheme is used for  | 
154 | 153 | `ty::Predicate`.  | 
155 | 154 | 
 
  | 
 | 
0 commit comments