Remove branches on determining how let-bindings are introduced to the
scope. This is maybe a little more inefficient, but I think it is a huge
simplification.
One additional change this required was changing how fx suffixes are
checked. The current implementation would add additional constraints for
patterns in let bindings conditionally. However, this is unnecessary. I
believe it is sufficient to check the fx suffix by running the checks on
all introduced symbols after the type is well known (i.e. the body is
checked).
In this initial commit, I have done the following:
- Added unit tests to roc_parse's ident.rs file to cover at least the
simplest Ident enum cases (Tag, OpaqueRef, and simple Access)
- Added '_' as a valid "rest" character in both uppercase and lowercase
identifier parts
- Updated the test_syntax snapshots appropriately
There is still a lot left to do here. Such as:
- Do we want to allow multiple '_'s to parse successfully?
- Handle qualified access
- Handle accessor functions
- Handle record update functions
- Remove the UnderscoreInMiddle case from BadIdent
- Write unit tests for Malformed Idents
I am not a "Rustacean" by any means, but have been through the Book in
years past. Any feedback on the way I wrote the tests or any other part
of the implementation would be very appreciated.
Notably:
* Unified how parens are formatted between (1) when we have a ParensAround, and (2) when we've decided an Apply needs to have parens
* Made unary minus require the be indented to the same level as any other expression continuation. (it used to accidentally have rules meant for binary operators applied)
* Don't apply extra indent to the backpassing continuation in the case that the call does itself require indentation
* Make `try@foo` correctly parse as `try @foo`, so that formatting doesn't change the tree when it adds that space
* Detect more cases where we need to outdent trailing e.g. {} blocks in applies
* Approximately a bagillion other things, 90% of which I added tests for, and none of which affected the formatting of examples or builtins
