Also change some tests with newly relaxed indentation requirements, and remove an irrelevant test (since unindented close parens are now perfectly valid, the test is no longer useful).
As previously discovered with #4464, it's easy to accidentally mis-use the State value returned on the Err path.
There were mixed assumptions about what that State represents: (1) the State where the error occurred, or (2) the State at the beginning of the thing we were just parsing.
I fixed this up to always mean (2) - at which point we don't actually need to return the State at all - so it's impossible for further discrepency to creep in.
I also took the liberty to refactor a few more methods to be purely combinator-based, rather than calling `parse` directly.
My concern with the previous wording is that:
- Beginners will be confused by "these are always open"
- Users advanced enough to understand what that actually means won't benefit from seeing it in this warning message!
This fixes a bug in the list pattern matching code that caused crashes
in the presence of list guards, and simplifies the pattern splitting
algorithm to avoid complexity and allocations. Previously we would place
arguments-to-be-matched of constructors and lists at the front of
specialized rows for exhaustiveness checking, but at the back for
redundancy checking. Now, we always place them at the back - this avoids
needless allocation, and is not any worse, since we can still recover
the non-exhaustive witnesses by looking at the end of a list, instead of
the front.
Programs like
```
after : ({} -> a), ({} -> b) -> ({} -> b)
fx = after (\{} -> {}) \{} -> if Bool.true then fx {} else {}
```
are legal because they always decay to functions, even if they may not
look like functions syntactically. Rather than using a syntactic check
to check for illegally-recursive functions, we should only perform such
checks after we know the types of values.
Closes#4291
