Commit Graph

5 Commits

Author SHA1 Message Date
Jason Felice
79351ee7ae Add blank line after "large" messages 2017-12-07 10:18:07 -05:00
Jason Felice
7d0c06b108 Put source code before error (like parse errors) 2017-12-07 10:18:05 -05:00
Jason Felice
f967817d5b Make warnings, non-parse errors pretty 2017-12-07 10:18:02 -05:00
Jason Felice
b1a4264f7c Improve error message locations (#4210)
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.
2017-11-30 12:18:36 +01:00
Colin Adams
d4d4ba6310 Added test case directive002 2016-05-06 18:29:31 +01:00