This patch provides errors for defs that are used only in
possibly-mutual recursion, and are not reachable outside of their
recursive closures. For example:
```
test_report!(
mutual_recursion_not_reached_nested,
indoc!(
r#"
app "test" provides [main] to "./platform"
main =
f = \{} -> if Bool.true then "" else g {}
g = \{} -> if Bool.true then "" else f {}
""
"#
),
@r###"
── DEFINITIONs ONLY USED IN RECURSION ──────────────────── /code/proj/Main.roc ─
These 2 definitions are only used in mutual recursion with themselves:
4│> f = \{} -> if Bool.true then "" else g {}
5│> g = \{} -> if Bool.true then "" else f {}
If you don't intend to use or export any of them, they should all be
removed!
"###
);
```
In #3352 an optimization to transform `ra = .field` into
```
ra = \#rcd -[ra]-> #rcd.field
```
rather than
```
__ra1 = \#rcd -[__ra1] -> #rcd.field
ra = LambdaSet { __ra1 }
```
was introduced. However, this optimization is not correct when `ra =
.field` is defined as a toplevel thunk, for in such situations we
indeed want the thunk `ra` to return the lambda set it resolves to,
rather than repointing at itself.
Besides reverting this change, another option would be to convert
accessors into closures before translation of Can to IR. However, this
complicates the translation algorithm more than it already is, and I'd
like to avoid additional special-cases.
Closes#4606
Previously, a program like
```
main =
f =
n = 1
\{} -[#lam]-> n # suppose lambda set = #lam
f {}
```
would be transformed to
```
main =
n = 1
f = \{} -[#lam]-> n
f {}
```
However, the IR lowering procedure is such that we would then associate
`f` as definining the procedure given the lambda set `#lam`. This is not
correct, as `f` is really a function pointer in this circumstance,
rather than the definer of `#lam`.
Instead, the transformation we want to perform is
```
main =
n = 1
#lam = \{} -[#lam]-> n
f = #lam
f {}
```
Which is what this patch does
Closes#2403
Previously this was a bit hacky, we worked around having to update
symbol substitutions by special-casing the rest of the program. There's
not need to do that.
Whether a module has a dependency on another module for specialization
is already accounted for when the build graph was initially populated,
and should not be modified again.
Closes#4622
