fix(report): reference all figures

report/appendices/variance.typ

@@ -16,7 +16,7 @@
     lang: "python",
     read("../code/variance_inferrer.py")
   )),
-  caption: [Implementation of variance `VarianceInferrer`]
+  caption: [Implementation of `VarianceInferrer`]
 ) <fig:midas-variance-inferrer>
 
 #figure(
@@ -25,5 +25,5 @@
     lang: "python",
     read("../code/variance_manager.py")
   )),
-  caption: [Implementation of variance `VarianceManager`]
+  caption: [Implementation of `VarianceManager`]
 ) <fig:midas-variance-manager>

report/bachelor_thesis.typ

@@ -234,4 +234,18 @@ You can also change the order or the names of the sections, for instance, if you
   relationship: "supplement",
   mime-type: "application/pdf",
   description: "Midas User Manual"
-)
+)
+
+#context {
+  let targets = query(ref).map(x => x.target)
+  let figures = query(figure)
+  for fig in figures {
+    if fig.at("caption", default: none) != none and fig.at("label", default: none) == none {
+      panic(repr(fig) + " is missing a label")
+    }
+  }
+  let unreferenced = figures.map(x => x.at("label", default: none)).filter(x => x != none and not str(x).ends-with(regex(`:\d+`.text)) and x not in targets)
+  if unreferenced.len() > 0 {
+    panic("Unreferenced labels: " + unreferenced.map(str).join(", "))
+  }
+}

report/chapters/04_implementation/03_registry.typ

@@ -202,7 +202,7 @@ The trivial case where `type1` is the same as `type2` can be handled with a simp
   caption: [`is_subtype`: equal types]
 ) <fig:is_subtype-equal>
 
-Even if the types differ, some cases such as top types are still trivially handled. If `type2` is a top type, `type1` is by definition a subtype (#smallcaps[S-Any] and #smallcaps[S-Unknown] in @tab:typing-subtyping-top).
+Even if the types differ, some cases such as top types are still trivially handled as demonstrated in @fig:is_subtype-top. If `type2` is a top type, `type1` is by definition a subtype (#smallcaps[S-Any] and #smallcaps[S-Unknown] in @tab:typing-subtyping-top).
 
 #codly(
   ranges: ((5, 10), (71, 71)),

report/chapters/04_implementation/04_midas_language.typ

@@ -258,7 +258,7 @@ The first and simplest statement is the alias statement (`m.AliasStmt`). Its eff
 === Type Statement <sec:midas-type-stmt>
 
 Type statements work similarly to alias statements, though they wrap the defined type in a `DerivedType` or `GenericType` depending on whether there are parameters.
-Additionally, if parameters are given, they are processed and transformed into `TypeVar` instances, and registered in an internal `_local_variables` dictionary. This internal registry is used by `TypesRegistry.get_type` to resolve references to type variables inside generic types and `extend` statements.
+Additionally, if parameters are given, they are processed and transformed into `TypeVar` instances, and registered in an internal `_local_variables` dictionary, as shown in @fig:midas-visit_type_stmt. This internal registry is used by `TypesRegistry.get_type` to resolve references to type variables inside generic types and `extend` statements.
 
 #figure(
   ```python
@@ -414,7 +414,7 @@ By polarity, we mean that:
 - any _consumer_ position, such as a function parameter, is considered *negative*
 
 Algorithmically, when inferring the variance of a variable, we start at the root generic type with a positive polarity. The inference function identifies all possible positions (type body and members) and recurses with the current polarity multiplied by the position's polarity. For example, if the current polarity is positive and a variable is used in a producer position, the resulting polarity used when recursing is $+ times + = +$. If however the variable is used in a consumer position, the polarity becomes $+ times - = -$. A consumer or negative position basically _flips_ the current polarity. When the recursion reaches the bottom usage, i.e. a simple `TypeVar`, the polarity is recorded.
-This algorithm is implemented by the `VarianceInferrer` class in @fig:midas-variance-inferrer-walk.
+This algorithm is implemented by the `VarianceInferrer` class in @fig:midas-variance-inferrer-walk (omitted parts of the code are listed in @fig:midas-variance-inferrer).
 
 #codly(
   ranges: (
@@ -437,7 +437,7 @@ Its implementation is given in @fig:midas-variance-tracker.
 
 It should be noted that we also use a `VarianceManager` to orchestrate how all the types are processed. The naive approach is to simply iterate over each type and infer its variance. However, this breaks down when a type is referenced before it has been processed, or even inside itself. To counter such situations, we introduce a queue of types currently being processed. When walking through a type, if we encounter an `AppliedType`, we first check whether it is in the queue. If not, we ask the manager to infer its variance before continuing, as highlighted in @fig:midas-variance-inferrer-walk:42 to @fig:midas-variance-inferrer-walk:47.
 
-`VarianceManager` is a simple helper class. Its main method, `infer`, is shown in @fig:midas-variance-manager-infer.
+`VarianceManager` is thus a simple helper class. Its main method, `infer`, is shown in @fig:midas-variance-manager-infer. The complete class is given in @fig:midas-variance-manager.
 
 #codly(
   range: (12, 21),

report/chapters/04_implementation/05_python_checking.typ

@@ -292,7 +292,7 @@ Applying typing rules for literals (@tab:typing-literals) is only a matter of ma
   caption: [Python Typer: implementation of `visit_literal_expr`]
 ) <fig:python-visit_literal_expr>
 
-For literal list expressions, we will reuse the `TypesRegistry.reduce_types` method used in @fig:python-function-return-type to try and find a supertype of all item types.
+For literal list expressions, we will reuse the `TypesRegistry.reduce_types` method used in @fig:python-function-return-type to try and find a supertype of all item types, as can be seen in @fig:python-visit_list_expr.
 
 #figure(
   ```python

report/chapters/05_results_discussion.typ

@@ -18,7 +18,7 @@ This is more than enough to make Midas usable in a wide range of contexts, inclu
 
 == Weather Pipeline Example <sec:results-pipeline>
 
-As an example, we will consider a sample weather-data transformation pipeline as shown in @app:example-pipeline, also available in the repository in #code-ref(<example-pipeline>, "examples/02_demonstration/weather/").
+As an example, we will consider a sample weather-data transformation pipeline as shown in @app:example-pipeline (specifically @fig:example-pipeline-types and @fig:example-pipeline-code), also available in the repository in #code-ref(<example-pipeline>, "examples/02_demonstration/weather/").
 
 === Domain Specific Types <sec:pipeline-types>
 
@@ -85,7 +85,7 @@ In a second step, we might want to transform some values to more appropriate typ
 ) <fig:pipeline-convert>
 
 This does highlight two current weaknesses of Midas. The first is the need to copy the dataframe in @fig:pipeline-convert:16. This is due to the fact that Midas does not support reference types (see chapter 13 of #acr("TaPL")@tapl). This means the type checker is completely oblivious to the fact that modifying a dataframe somewhere might change other references in other places.
-The second issue, which is more of a possible optimization, is the fact that `cast` will re-check the whole dataframe at runtime, even though some checks are irrelevant given the parameter's type. This is made even more noticeable in @fig:pipeline-aggregation which will check base types again (e.g. `float`).
+The second issue, which is more of a possible optimization, is the fact that `cast` will re-check the whole dataframe at runtime, even though some checks are irrelevant given the parameter's type. This is made even more noticeable in @fig:pipeline-heat-index and @fig:pipeline-aggregation which will check base types again (e.g. `float`).
 
 #codly(
   range: (26, 37),