|
9 | 9 | //! `ObligationForest` supports two main public operations (there are a |
10 | 10 | //! few others not discussed here): |
11 | 11 | //! |
12 | | -//! 1. Add a new root obligations (`push_tree`). |
| 12 | +//! 1. Add a new root obligations (`register_obligation`). |
13 | 13 | //! 2. Process the pending obligations (`process_obligations`). |
14 | 14 | //! |
15 | 15 | //! When a new obligation `N` is added, it becomes the root of an |
|
20 | 20 | //! with every pending obligation (so that will include `N`, the first |
21 | 21 | //! time). The callback also receives a (mutable) reference to the |
22 | 22 | //! per-tree state `T`. The callback should process the obligation `O` |
23 | | -//! that it is given and return one of three results: |
| 23 | +//! that it is given and return a `ProcessResult`: |
24 | 24 | //! |
25 | | -//! - `Ok(None)` -> ambiguous result. Obligation was neither a success |
| 25 | +//! - `Unchanged` -> ambiguous result. Obligation was neither a success |
26 | 26 | //! nor a failure. It is assumed that further attempts to process the |
27 | 27 | //! obligation will yield the same result unless something in the |
28 | 28 | //! surrounding environment changes. |
29 | | -//! - `Ok(Some(C))` - the obligation was *shallowly successful*. The |
| 29 | +//! - `Changed(C)` - the obligation was *shallowly successful*. The |
30 | 30 | //! vector `C` is a list of subobligations. The meaning of this is that |
31 | 31 | //! `O` was successful on the assumption that all the obligations in `C` |
32 | 32 | //! are also successful. Therefore, `O` is only considered a "true" |
33 | 33 | //! success if `C` is empty. Otherwise, `O` is put into a suspended |
34 | 34 | //! state and the obligations in `C` become the new pending |
35 | 35 | //! obligations. They will be processed the next time you call |
36 | 36 | //! `process_obligations`. |
37 | | -//! - `Err(E)` -> obligation failed with error `E`. We will collect this |
| 37 | +//! - `Error(E)` -> obligation failed with error `E`. We will collect this |
38 | 38 | //! error and return it from `process_obligations`, along with the |
39 | 39 | //! "backtrace" of obligations (that is, the list of obligations up to |
40 | 40 | //! and including the root of the failed obligation). No further |
|
47 | 47 | //! - `completed`: a list of obligations where processing was fully |
48 | 48 | //! completed without error (meaning that all transitive subobligations |
49 | 49 | //! have also been completed). So, for example, if the callback from |
50 | | -//! `process_obligations` returns `Ok(Some(C))` for some obligation `O`, |
| 50 | +//! `process_obligations` returns `Changed(C)` for some obligation `O`, |
51 | 51 | //! then `O` will be considered completed right away if `C` is the |
52 | 52 | //! empty vector. Otherwise it will only be considered completed once |
53 | 53 | //! all the obligations in `C` have been found completed. |
54 | 54 | //! - `errors`: a list of errors that occurred and associated backtraces |
55 | 55 | //! at the time of error, which can be used to give context to the user. |
56 | 56 | //! - `stalled`: if true, then none of the existing obligations were |
57 | | -//! *shallowly successful* (that is, no callback returned `Ok(Some(_))`). |
| 57 | +//! *shallowly successful* (that is, no callback returned `Changed(_)`). |
58 | 58 | //! This implies that all obligations were either errors or returned an |
59 | 59 | //! ambiguous result, which means that any further calls to |
60 | 60 | //! `process_obligations` would simply yield back further ambiguous |
|
0 commit comments