mesabloo / diagnose Goto Github PK

The current functionality requires an output to a file handle, but allowing the conversion to a Prettyprinter.Doc format would enable this to be embedded in other Doc output and managed as needed by client applications. Would exporting prettyDiagnostic be a reasonable update?

The bounds for prettyprinter-ansi-terminal are given as ">=1.1.0 && <2":

However, these bounds are incorrect: diagnose requires prettyprinter-ansi-terminal >= 1.1.2, and compilation will fail if versions of prettyprinter-ansi-terminal lower than that are used.

Specifically, in module Error.Diagnose.Diagnostic.Internal, Prettyprinter.Render.Terminal is imported:

This module does not exist in versions of prettyprinter-ansi-terminal < 1.2 (see e.g. prettyprinter-ansi-terminal-1.1.1.2).

Repro

When using parsec-diagnose 1.7.1 and parsec 3.1.14.0 and GHC version 9.0.2 I get duplicated markers with the simple code here:

{-# OPTIONS_GHC -fno-warn-orphans #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}

import Error.Diagnose
import Error.Diagnose.Compat.Parsec
import Text.Parsec

import Data.Void
instance HasHints Void String where hints _ = []

type Parser = Parsec String ()

diagParse :: Parser a -> SourceName -> String -> Either (Diagnostic String) a
diagParse p filename content =
    either (Left . diag) Right (parse p filename content)
  where
    diag e = addFile (errorDiagnosticFromParseError Nothing "Parse error on input" Nothing e) filename content

parser :: Parser Char
parser = op' "\\" *> letter

main :: IO ()
main = either (printDiagnostic stderr True True) print $
  diagParse parser "issues/2.txt" "\\1"

-- smaller example
op' :: String -> Parser String
op' name = string name <* spaces

Output

[error]: Parse error on input
     ╭──▶ issues/2.txt@1:2-1:3
     │
   1 │ \1
     •  ┬ 
     •  ├╸ unexpected "1"
     •  ├╸ unexpected "1"
     •  ╰╸ expecting any of white space, letter
─────╯

Description

I stumbled on this while using the TokenParser from parsec:

import Text.Parsec.Token

op :: String -> Parser ()
op = reservedOp $ makeTokenParser LanguageDef {
    commentStart   = "{-"
  , commentEnd     = "-}"
  , commentLine    = "--"
  , reservedOpNames = ["\\"]
  , opStart        = oneOf "\\"
  , opLetter       = oneOf "\\"
  }

Using op as defined above I get:

[error]: Parse error on input
     ╭──▶ issues/2.txt@1:2-1:3
     │
   1 │ \1
     •  ┬ 
     •  ├╸ unexpected "1"
     •  ├╸ unexpected "1"
     •  ├╸ unexpected "1"
     •  ├╸ unexpected "1"
     •  ├╸ unexpected "1"
     •  ╰╸ expecting any of end of "\\", , letter
─────╯

Expected

I expect the above to only print a single line containing unexpected "1" for both cases.

In my fork of this repo, I bumped text and hashable to newer versions.
It seems to compile and work in my compiler, so maybe worth the time to upgrade?

You can find the commit here: 98653e2

The bounds for unordered-containers are given as "==0.2.*":

But this is incorrect: diagnose will not build with versions of unordered-containers < 0.2.11. It uses the !? function from Data.HashMap.Lazy, here:

and that function was not introduced into unordered-containers until version 0.2.11 (see here).

One of our Windows users is reporting problems due to the dependency on wcwidth. I have reported the problem upstream: solidsnack/wcwidth#7

I am currently investigating a solution to the problem

Here's my output:

1. The middle row does not get highlighted
2. I think the text associated with the multiline span would look better right under it's source, as opposed to the very bottom. It's also weird because there are no dots indicating there's a jump in lines between the first and the second source spans..

Thanks for making this awesome library!

"Columns" of text are not well-defined in the presence of unicode input. I'd suggest specifying that it means unicode code points, and maybe testing with some awkward unicode text.

It works fine with cabal build --allow-newer=text, so I assume you can relax the bounds on Hackage.

Currently addReport will prepend new reports to the report list. This causes the report generation to show the reports in the reverse order generated.

Here's a modified version of test/megaparsec/Spec.hs that captures multiple parse errors:

{-# LANGUAGE CPP #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}

{-# OPTIONS -Wno-orphans #-}

import Data.Bifunctor (first)
import Data.Char (isAlpha)
import Data.Text (Text)
import qualified Data.Text as Text (unpack)
import Data.Void (Void)
import Error.Diagnose
import Error.Diagnose.Compat.Megaparsec
import qualified Text.Megaparsec as MP
import qualified Text.Megaparsec.Char as MP
import qualified Text.Megaparsec.Char.Lexer as MP

instance HasHints Void msg where
  hints _ = mempty

main :: IO ()
main = do
  let filename :: FilePath = "<interactive>"
      content1 :: Text = "0000000123456"
      content2 :: Text = "00000a2223266"
      content3 = "aaa\naab\naba\na\nb\n"

  let res1 = first (errorDiagnosticFromBundle Nothing "Parse error on input" Nothing) $ MP.runParser @Void (MP.some MP.decimal <* MP.eof) filename content1
      res2 = first (errorDiagnosticFromBundle Nothing "Parse error on input" Nothing) $ MP.runParser @Void (MP.some MP.decimal <* MP.eof) filename content2
      res3 = first (errorDiagnosticFromBundle Nothing "Parse error on input" Nothing)
             $
             let a = MP.char 'a'
                 errSkip e = do MP.registerParseError e
                                _ <- MP.takeWhileP Nothing isAlpha <* MP.eol
                                return ""
             in MP.runParser @Void
                (MP.many (MP.withRecovery errSkip (MP.some a <* MP.eol)) <* MP.eof)
                filename content3

  case res1 of
    Left diag -> printDiagnostic stdout True True 4 (addFile diag filename (Text.unpack content1) :: Diagnostic String)
    Right res -> print res
  case res2 of
    Left diag -> printDiagnostic stdout True True 4 (addFile diag filename (Text.unpack content2) :: Diagnostic String)
    Right res -> print res
  putStrLn "------------- res3 ----------------"
  case res3 of
    Left diag -> printDiagnostic stdout True True 4 (addFile diag filename (Text.unpack content3) :: Diagnostic String)
    Right res -> print res

The above updated Megaparsec test demonstrates the inversion:

------------- res3 ----------------
[error]: Parse error on input
     ╭──▶ <interactive>@5:1-5:2
     │
   5 │ b
     • ┬
     • ├╸ unexpected 'b'
     • ╰╸ expecting 'a'
─────╯

[error]: Parse error on input
     ╭──▶ <interactive>@3:2-3:3
     │
   3 │ aba
     •  ┬
     •  ├╸ unexpected "ba"
     •  ╰╸ expecting 'a' or end of line
─────╯

[error]: Parse error on input
     ╭──▶ <interactive>@2:3-2:4
     │
   2 │ aab
     •   ┬
     •   ├╸ unexpected "b<newline>"
     •   ╰╸ expecting 'a' or end of line
─────╯

I would have expected the reports to be in the same order as the lines parsed. Perhaps addReport should append (and use Data.Sequence for performance), or else prettyDiagnostic should reverse the reports before generating them.

Thanks for your great library!

I use both Rust and Haskell, and have learned about error reporting libraries like ariadne and codespan-reporting for a while. Previously when working on a Rust project, I chose codespan-reporting because I preferred its formatting (formatting of ariadne is also beautiful, but a bit too fancy for me), given their interfaces are pretty similar. Is it possible to extend this library to have an alternative codespan-reporting-style formatting for the diagnostic messages? Or is there some design space to expose an API for custom report formatting?

FYI, here is a comparison of the said two styles (BTW it is amusing to see a more Haskell-like syntax for illustration in codespan-reporting the Rust library but a more Rust-like style here):

Name	Illustration
(current) ariadne-style
codespan-reporting-style

If this is deemed non-trivial, I am willing to work on this, in that case would you please provide some guidance?

The docs mention integration with LSP via the diagnosticToJson function, but no other information is given on how to do this.

I'm new to LSP myself, could you provide some pointers where to start looking for more information?
(Or add a section to Diagnose docs somewhere on how to quickly/easily integrate with LSP?)

Thanks!

Hello,

I'm currently testing your library and the diagnostics look really good!

I am just having one issue and it's unclear to me how to solve it from the docs. If I have content that spans over multiple lines and it breaks the layout. Is it possible to use say Docs instead of Text/String to create a Report? Or what would be the way of doing something like this? Say showing actual/expected types in a type error, or having a type that is long ( record type or function types for example ).