Skip to content

Commit ac061dc

Browse files
committed
Fix some out-of-date names of things in comments.
1 parent 3fda957 commit ac061dc

File tree

1 file changed

+7
-7
lines changed
  • src/librustc_data_structures/obligation_forest

1 file changed

+7
-7
lines changed

src/librustc_data_structures/obligation_forest/mod.rs

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@
99
//! `ObligationForest` supports two main public operations (there are a
1010
//! few others not discussed here):
1111
//!
12-
//! 1. Add a new root obligations (`push_tree`).
12+
//! 1. Add a new root obligations (`register_obligation`).
1313
//! 2. Process the pending obligations (`process_obligations`).
1414
//!
1515
//! When a new obligation `N` is added, it becomes the root of an
@@ -20,21 +20,21 @@
2020
//! with every pending obligation (so that will include `N`, the first
2121
//! time). The callback also receives a (mutable) reference to the
2222
//! 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`:
2424
//!
25-
//! - `Ok(None)` -> ambiguous result. Obligation was neither a success
25+
//! - `Unchanged` -> ambiguous result. Obligation was neither a success
2626
//! nor a failure. It is assumed that further attempts to process the
2727
//! obligation will yield the same result unless something in the
2828
//! surrounding environment changes.
29-
//! - `Ok(Some(C))` - the obligation was *shallowly successful*. The
29+
//! - `Changed(C)` - the obligation was *shallowly successful*. The
3030
//! vector `C` is a list of subobligations. The meaning of this is that
3131
//! `O` was successful on the assumption that all the obligations in `C`
3232
//! are also successful. Therefore, `O` is only considered a "true"
3333
//! success if `C` is empty. Otherwise, `O` is put into a suspended
3434
//! state and the obligations in `C` become the new pending
3535
//! obligations. They will be processed the next time you call
3636
//! `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
3838
//! error and return it from `process_obligations`, along with the
3939
//! "backtrace" of obligations (that is, the list of obligations up to
4040
//! and including the root of the failed obligation). No further
@@ -47,14 +47,14 @@
4747
//! - `completed`: a list of obligations where processing was fully
4848
//! completed without error (meaning that all transitive subobligations
4949
//! 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`,
5151
//! then `O` will be considered completed right away if `C` is the
5252
//! empty vector. Otherwise it will only be considered completed once
5353
//! all the obligations in `C` have been found completed.
5454
//! - `errors`: a list of errors that occurred and associated backtraces
5555
//! at the time of error, which can be used to give context to the user.
5656
//! - `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(_)`).
5858
//! This implies that all obligations were either errors or returned an
5959
//! ambiguous result, which means that any further calls to
6060
//! `process_obligations` would simply yield back further ambiguous

0 commit comments

Comments
 (0)