Hey everyone, I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found [here](https://github.com/haskellfoundation/tech-proposals/pull/50). In looking through the current implementation of the -ddump-json flag, I found a [note](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h...) which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of [LogAction](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h...), reproduced below: type LogAction = LogFlags -> MessageClass -> SrcSpan -> SDoc -> IO () So instead of taking in an SDoc, I could alter this signature to take a set of Diagnostics, though this may introduce other complications. In the first place, it seems log action is processing all of the diagnostics one at a time, though this particular JSON output should process all of them at once in order to place them all in a single JSON object. So, I am inclined to believe that this approach may not work. Another approach could be the one originally tried and mentioned in the note linked above, which is to keep track of all diagnostics in an IORef, and use this to produce a final JSON result at the end of GHC's execution. This approach seems invasive in a different way. Does anyone familiar with the handling of diagnostics throughout the compiler have any suggestions on how best to implement such a feature? You can find the work that I have done so far [here](https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump). All I am really doing is checking if the new flag is set in [printMessages](https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump#...). If it is, then I simply invoke the json function of the ToJson typeclass and use that to print the diagnostic. It is currently a bit messy, but I wanted to just see if the path that I am taking seems fruitful or if there are any obvious hurdles that I am not seeing. Thanks so much! Best, Ben Bellick
How feasible would it be to use something like https://jsonlines.org/ ? (In
short, newline-delimited json values.) This could be in addition to any
future single-json-value output format, or as a stepping stone to that goal.
On Mon, 10 Jul 2023 at 00:46, Ben Bellick via ghc-devs
Hey everyone,
I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found here https://github.com/haskellfoundation/tech-proposals/pull/50.
In looking through the current implementation of the -ddump-json flag, I found a note https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h... which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of LogAction https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h..., reproduced below:
type LogAction = LogFlags -> MessageClass -> SrcSpan -> SDoc -> IO ()
So instead of taking in an SDoc, I could alter this signature to take a set of Diagnostics, though this may introduce other complications. In the first place, it seems log action is processing all of the diagnostics one at a time, though this particular JSON output should process all of them at once in order to place them all in a single JSON object. So, I am inclined to believe that this approach may not work.
Another approach could be the one originally tried and mentioned in the note linked above, which is to keep track of all diagnostics in an IORef, and use this to produce a final JSON result at the end of GHC's execution. This approach seems invasive in a different way.
Does anyone familiar with the handling of diagnostics throughout the compiler have any suggestions on how best to implement such a feature?
You can find the work that I have done so far here https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump. All I am really doing is checking if the new flag is set in printMessages https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump#.... If it is, then I simply invoke the json function of the ToJson typeclass and use that to print the diagnostic.
It is currently a bit messy, but I wanted to just see if the path that I am taking seems fruitful or if there are any obvious hurdles that I am not seeing. Thanks so much!
Best, Ben Bellick _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Ben Bellick via ghc-devs
Hey everyone,
I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found [here](https://github.com/haskellfoundation/tech-proposals/pull/50).
In looking through the current implementation of the -ddump-json flag, I found a [note](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h...) which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of [LogAction](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.h...), reproduced below:
...
So instead of taking in an SDoc, I could alter this signature to take a set of Diagnostics, though this may introduce other complications. In the first place, it seems log action is processing all of the diagnostics one at a time, though this particular JSON output should process all of them at once in order to place them all in a single JSON object. So, I am inclined to believe that this approach may not work.
Taking all of the diagnostics at once is possible (and, with the addition of internal state, could even be done without changing the LogAction type). However, it would mean that downstream users wouldn't benefit from incremental reporting of errors. I don't honestly know whether how much value such incrementality has to the typical consumers you have in mind, but I think it could be easily preserved with something like the JSON Lines approach that Bryan suggests. Admittedly, this would be a change in the semantics of -ddump-json but I don't consider this to be a problem. Frankly, `-d` flags are intended primarily for debugging and are generally not considered to be stable interfaces. In fact, if we are going to improve the JSON output, I think we should probably rename the flag to something in the `-f` namespace and deprecate the old `-d` flag. Cheers, - Ben
participants (3)
-
Ben Bellick -
Ben Gamari -
Bryan Richter