This contribution uses the strict WriterT transformer over our parser stack with a
monoid over FC and what used to be spanFC to compute the span of
non-terminal parsers from the spans of trackExtent-wrapped parsers.
The net result is that the locations reported for errors and warnings is
much improved. Most errors now report the extent of the error, rather than a
point roughly preceeding it (or after it, sometimes). There are still cases
where FCs are recomputed as a point after parsing--I didn't fix these, to cut
the scope of this PR--though all file locations produced during parsing use
the new, spanning parsing combinators.
I would start reading at Idris.Parser.Stack, then Idris.Parser.Helpers.
Overview:
- *FC and non-*FC parsers (e.g. tokenFC and token, charLiteralFC and
charLiteral, etc.) have been elided and the FC suffix removed. Any
parser can be asked to report it's FC using the extent or withExtent
combinators.
- Extents reported for errors end at the last character of the token, rather
than on the following character.
- Now that all parsers can be queried for their spans, highlighting is
done with the highlight parser combinator, e.g.
highlight AnnQuasiquote (symbol "`{{" ...). These can be nested.
- Totality checking, in its current design, reports the extent of the first
equation. This is a bit more misleading now that the span is computed
correctly, since it could look like it's trying to indicate which clause is
non-total. We should fix this (hopefully as a separate PR.)
- The span of clauses is actually the span of the right-hand side, and so this
is reported when there is an error on the right-hand side or the left-hand
side. We should also fix this (hopefully as a separate PR.)
- There's probably cases where, owning to the improved granularity, we will now
notice errors were reported with FCs from the wrong object.
I haven't tested an IDE-mode client yet. They may need to be patched if they
are manually excluding the last character of tokens. Highlighting appears to
work fine without changes, though.
We've always said that the rules for binding names in patterns are the
same as the rules for binding names in implicits, i.e. a name beginning
with a lower case letter, not applied to anything, will be bound
implicitly, or treated as a pattern variable. This hasn't actually
always been quite true, even though it was supposed to be...
Correspondingly, added a warning for constructor names which may be
unexpectedly bound implicitly.
This patch changes the pattern binding rules so that it is the case.
Fixes#2653
The changes are as follows:
+ `print` is for putting showable things to STDOUT.
+ `printLn` is for putting showable things to STDOUT with a new line
+ `putCharLn` for putting a single character to STDOUT, with a new line.
Effects has been updated accordingly.
