|
12 | 12 | * match against the current list of values. If those patterns match, then
|
13 | 13 | * the arm listed in the match is the correct arm. A given arm may have
|
14 | 14 | * multiple corresponding match entries, one for each alternative that
|
15 |
| - * remains. As we proceed these sets of matches are adjusted. Anyway this |
16 |
| - * part I am pretty vague on. Perhaps I or someone else can add more |
17 |
| - * documentation when they understand it. :) |
| 15 | + * remains. As we proceed these sets of matches are adjusted by the various |
| 16 | + * `enter_XXX()` functions, each of which adjusts the set of options given |
| 17 | + * some information about the value which has been matched. |
| 18 | + * |
| 19 | + * So, initially, there is one value and N matches, each of which have one |
| 20 | + * constituent pattern. N here is usually the number of arms but may be |
| 21 | + * greater, if some arms have multiple alternatives. For example, here: |
| 22 | + * |
| 23 | + * enum Foo { A, B(int), C(uint, uint) } |
| 24 | + * match foo { |
| 25 | + * A => ..., |
| 26 | + * B(x) => ..., |
| 27 | + * C(1u, 2) => ..., |
| 28 | + * C(_) => ... |
| 29 | + * } |
| 30 | + * |
| 31 | + * The value would be `foo`. There would be four matches, each of which |
| 32 | + * contains one pattern (and, in one case, a guard). We could collect the |
| 33 | + * various options and then compile the code for the case where `foo` is an |
| 34 | + * `A`, a `B`, and a `C`. When we generate the code for `C`, we would (1) |
| 35 | + * drop the two matches that do not match a `C` and (2) expand the other two |
| 36 | + * into two patterns each. In the first case, the two patterns would be `1u` |
| 37 | + * and `2`, and the in the second case the _ pattern would be expanded into |
| 38 | + * `_` and `_`. The two values are of course the arguments to `C`. |
| 39 | + * |
| 40 | + * Here is a quick guide to the various functions: |
| 41 | + * |
| 42 | + * - `compile_submatch()`: The main workhouse. It takes a list of values and |
| 43 | + * a list of matches and finds the various possibilities that could occur. |
| 44 | + * |
| 45 | + * - `enter_XXX()`: modifies the list of matches based on some information about |
| 46 | + * the value that has been matched. For example, `enter_rec_or_struct()` |
| 47 | + * adjusts the values given that a record or struct has been matched. This is |
| 48 | + * an infallible pattern, so *all* of the matches must be either wildcards or |
| 49 | + * record/struct patterns. `enter_opt()` handles the fallible cases, and it is |
| 50 | + * correspondingly more complex. |
18 | 51 | *
|
19 | 52 | * ## Bindings
|
20 | 53 | *
|
|
0 commit comments