@@ -185,20 +185,20 @@ impl<K: DepKind> DepGraph<K> {
185
185
///
186
186
/// `A -> B -> C`
187
187
///
188
- /// Suppose that decoding the result of query `B` required invoking
189
- /// a query `D `. If we did not create a fresh `TaskDeps` when
190
- /// decoding `B`, we might would still be using the `TaskDeps` for query `A`
188
+ /// Suppose that decoding the result of query `B` required re-computing
189
+ /// the query `C `. If we did not create a fresh `TaskDeps` when
190
+ /// decoding `B`, we would still be using the `TaskDeps` for query `A`
191
191
/// (if we needed to re-execute `A`). This would cause us to create
192
- /// a new edge `A -> D `. If this edge did not previously
192
+ /// a new edge `A -> C `. If this edge did not previously
193
193
/// exist in the `DepGraph`, then we could end up with a different
194
194
/// `DepGraph` at the end of compilation, even if there were no
195
195
/// meaningful changes to the overall program (e.g. a newline was added).
196
196
/// In addition, this edge might cause a subsequent compilation run
197
- /// to try to force `D ` before marking other necessary nodes green. If
198
- /// `D ` did not exist in the new compilation session, then we might
197
+ /// to try to force `C ` before marking other necessary nodes green. If
198
+ /// `C ` did not exist in the new compilation session, then we could
199
199
/// get an ICE. Normally, we would have tried (and failed) to mark
200
200
/// some other query green (e.g. `item_children`) which was used
201
- /// to obtain `D `, which would prevent us from ever trying to force
201
+ /// to obtain `C `, which would prevent us from ever trying to force
202
202
/// a non-existent `D`.
203
203
///
204
204
/// It might be possible to enforce that all `DepNode`s read during
@@ -208,7 +208,12 @@ impl<K: DepKind> DepGraph<K> {
208
208
/// of `B`, this would result in an edge `B -> D`. If that edge already
209
209
/// existed (with the same `DepPathHash`es), then it should be correct
210
210
/// to allow the invocation of the query to proceed during deserialization
211
- /// of a query result. However, this would require additional complexity
211
+ /// of a query result. We would merely assert that the dep-graph fragment
212
+ /// that would have been added by invoking `C` while decoding `B`
213
+ /// is equivalent to the dep-graph fragment that we already instantiated for B
214
+ /// (at the point where we successfully marked B as green).
215
+ ///
216
+ /// However, this would require additional complexity
212
217
/// in the query infrastructure, and is not currently needed by the
213
218
/// decoding of any query results. Should the need arise in the future,
214
219
/// we should consider extending the query system with this functionality.
0 commit comments