* Unify parsing of string literals and scalar literals, to (e.g.) ensure escapes are handled uniformly. Notably, this makes unicode escapes valid in scalar literals.
* Add a variety of custom error messages about specific failure cases of parsing string/scalar literals. For example, if we're expecting a string (e.g. a package name in the header) and the user tried using single quotes, give a clear message about that.
* Fix formatting of unicode escapes (they previously used {}, now correctly use () to match roc strings)
When we transform a top-level expect into an inline expect, we collect
all intermediate defs before the expect condition, then layer the defs
back on. Because the layering procedure builds an expression bottom-up,
we must layer on defs in reverse definition order.
Closes#4705
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
