@@ -185,20 +185,20 @@ impl<K: DepKind> DepGraph<K> {
185185 ///
186186 /// `A -> B -> C`
187187 ///
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`
191191 /// (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
193193 /// exist in the `DepGraph`, then we could end up with a different
194194 /// `DepGraph` at the end of compilation, even if there were no
195195 /// meaningful changes to the overall program (e.g. a newline was added).
196196 /// 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
199199 /// get an ICE. Normally, we would have tried (and failed) to mark
200200 /// 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
202202 /// a non-existent `D`.
203203 ///
204204 /// It might be possible to enforce that all `DepNode`s read during
@@ -208,7 +208,12 @@ impl<K: DepKind> DepGraph<K> {
208208 /// of `B`, this would result in an edge `B -> D`. If that edge already
209209 /// existed (with the same `DepPathHash`es), then it should be correct
210210 /// 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
212217 /// in the query infrastructure, and is not currently needed by the
213218 /// decoding of any query results. Should the need arise in the future,
214219 /// we should consider extending the query system with this functionality.
0 commit comments