|
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