Call for Beta Testers: New Flag `-fdiagnostics-as-json`

Announcements
1

Hey everyone,

I wanted to share the addition of a new GHC flag to help users more easily parse diagnostic information. This is meant to ultimately replace the usage of -ddump-json. It was merged into master ~1 month ago.
If you have already added the nightlies channel to your ghcup, then you can find it in the release e.g. 9.9.20240208 by performing:

> ghcup install ghc 9.9.20240208
> ghcup set ghc 9.9.20240208

Here is an example possible output:
> ghc bad.hs -fdiagnostics-as-json

[1 of 1] Compiling Bad              ( ../tmp/bad.hs, ../tmp/bad.o )
{"version":"1.0","ghcVersion":"ghc-9.9.20230817","span":{"file":"bad.hs","start":{"line":9,"column":3},"end":{"line":9,"column":14}},"severity":"Error","code":88464,"message":["Variable not in scope: printLineas :: String -> IO a1"],"hints":[]}
{"version":"1.0","ghcVersion":"ghc-9.9.20230817","span":{"file":"bad.hs","start":{"line":10,"column":3},"end":{"line":10,"column":9}},"severity":"Error","code":88464,"message":["Variable not in scope: blaksh :: String -> IO ()"],"hints":[]}

The idea is to make it easier for external tools to parse error messages to make them easier to use. You can see the PR discussed here. You can see the JSON schema that the output data will conform to here (it is also hyperlinked to in the compiler flags section of the docs.

Please try it out on an array of errors via the -fdiagnostics-as-json flag and let us know what you think! Thanks a ton :slight_smile:

12 Likes
2

Awesome work Ben congratulations on getting this merged :smile:! Really excited to try this out for static-ls. Out of curiosity what’s the best place to provide any feedback if we have any?

1 Like
3

Sorry to resurrect such an old thread! Is this a reasonable place to provide feedback about this feature? I recently added support for -fdiagnostics-as-json to Purple Yolk, my Haskell extension for VSCode:

It was mostly painless except for one thing: Now diagnostics go to STDERR but “compiling” messages go to STDOUT. Usually the “compiling” message can be used to clear diagnostics. But it seems like the order is no longer guaranteed. Sometimes I get a “compiling” message first, like before, but sometimes I get a diagnostic first. For example:

[60 of 64] Compiling Main             ( /Volumes/nvme/Developer/haskell-packages/cabal-gild/source/test-suite/Main.hs, interpreted )[cabal-gild-1.5.0.3-inplace-cabal-gild-test-suite]
{"version":"1.1","ghcVersion":"ghc-9.12.1","span":{"file":"/Volumes/nvme/Developer/haskell-packages/cabal-gild/./source/library/CabalGild.hs","start":{"line":11,"column":1},"end":{"line":11,"column":8}},"severity":"Warning","code":40910,"message":["Defined but not used: `warning'"],"hints":[],"reason":{"flags":["unused-top-binds"]}}
[61 of 64] Compiling CabalGild        ( /Volumes/nvme/Developer/haskell-packages/cabal-gild/source/library/CabalGild.hs, interpreted )[cabal-gild-1.5.0.3-inplace]

Note that I get a diagnostic from the CabalGild module before I get the “compiling” message about starting to compile that module. This makes collecting diagnostics more difficult because I need to clear them when the module is recompiled.

1 Like