-ddump-json

[Iavor Diatchki]

Hello,
it seems pretty reasonable to change it, but we should change the version
number as well (well, and add it if it is not there).  In general, having a
version number is probably good practice for any outward facing machine
readable format.
-Iavor


On Fri, Jan 29, 2021 at 11:51 AM Ben Gamari <ben at well-typed.com> wrote:

> Richard Eisenberg <rae at richarde.dev> writes:
>
> > Hi devs,
> >
> > In my work with Alfredo at revising our error message infrastructure,
> > we ran across some code that renders error messages as JSON. Given
> > that our data structures are changing, it seems natural to change the
> > JSON output, too, but it's unclear whether that's wise. The manual
> > currently lists -ddump-json in the chapter on "Debugging the
> > compiler", suggesting that a change is fine, but I'm not yet
> > convinced.
> >
> I think it would be fine to change the output. However, note that there
> is a reason why this flag is in the -d flag namespace and the "Debugging
> the compiler". The output is quite unstructured and we reserve the right to
> change the representation, largely because it was hard to do better
> without first fixing #8809.
>
> After we have the new rich errors infrastucture in place I think we will
> be in a much better place to discuss a properly-supported flag (via the
> proposal process, presumably). However, I think when we do so we should
> be careful to constrain the scope of the provided output. GHC is not a
> language server and I don't think it would be wise to make it one.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210129/e951e539/attachment.html>