The reason is that most things on windows handles unix line endings just
fine and this leads to terrible bugs when writing binary files.
fopen still allows opening of files without the "b".
This only has effect on Windows, but POSIX systems allows the "b" as a
noop.
* Wrote Data.{SortedBag,ArrowChain,PosNat}
* Added some more docs to Data.SortedBag
* Renamed ArrowChain to Chain
* Added `null` to Data.SortedMap
* Edited CHANGELOG
* Edited contrib.ipkg
* Fixed tiny typo
When building a package with foreign code and a makefile, the makefile
itself must find the compilation flags that Idris already knows
about. Moreover, the `idris` executable found by the makefile may not
be the same used to build the package. This change passes the build
flags to the makefile though environment variables.
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.
