Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support JSON errors #1523

Closed
paf31 opened this issue Oct 14, 2015 · 10 comments
Closed

Support JSON errors #1523

paf31 opened this issue Oct 14, 2015 · 10 comments

Comments

@paf31
Copy link
Contributor

@paf31 paf31 commented Oct 14, 2015

No description provided.

@paf31
Copy link
Contributor Author

@paf31 paf31 commented Oct 14, 2015

I've marked this as easy, meaning it should only require basic Haskell knowledge and a working knowledge of aeson, not because it will be a quick change.

@nwolverson
Copy link
Contributor

@nwolverson nwolverson commented Oct 20, 2015

This would be great, it's a pain to parse the current variable number of lines. As well as obviously line/column numbers, module/filename it would be really good to be able to have a short "headline" 1-line error message as well as the multiple line "explanatory" version

@kritzcreek
Copy link
Member

@kritzcreek kritzcreek commented Oct 20, 2015

I'll start writing some instances this evening :)

@paf31
Copy link
Contributor Author

@paf31 paf31 commented Oct 21, 2015

What about moving this to 0.8, since it is in the error-messages bucket?

@paf31
Copy link
Contributor Author

@paf31 paf31 commented Nov 14, 2015

Moving to 0.8, I think this could be really useful.

@paf31 paf31 modified the milestones: 0.8.0, Ideas Nov 14, 2015
@paf31 paf31 self-assigned this Nov 14, 2015
@paf31
Copy link
Contributor Author

@paf31 paf31 commented Nov 16, 2015

@kritzcreek @nwolverson Is there anything else you would like to have available in the JSON document?

  • Line and column numbers
  • Module name and file path
  • Short error message
  • Full error message
  • Link to the appropriate wiki page

I was going to try to keep things pretty simple, and just have a handful of fields like this, keeping the error message text formatted as it is now, but if you think there is benefit to breaking up the error message parts further (for example, for formatting in an IDE), let me know.

@jdegoes
Copy link

@jdegoes jdegoes commented Nov 16, 2015

For suggestions: Hints, as patches / diffs. 😄

Actually, that'd be nice in the non-JSON errors / warnings, too.

@paf31
Copy link
Contributor Author

@paf31 paf31 commented Nov 16, 2015

I like that idea, and it's easier to implement than trying to point at the offending location in ascii art 😄 I'll write it up.

@kritzcreek
Copy link
Member

@kritzcreek kritzcreek commented Nov 16, 2015

Having some kind of pretty printer to turn the AST into code would be nice for more advanced refactoring (extract/inline method, etc...) aswell so I'm all in for the patch/diff thingy.

One more field that would be nice is some "tag" that denotes the kind of error like "CantUnifyTypes", "UndefinedIdentifier"... I want to respond to errors which could correspond to mistyping with suggestions based on edit-distance.

We could of course shift that into the compiler so that we could provide it in the human readable errors aswell.

@nwolverson
Copy link
Contributor

@nwolverson nwolverson commented Nov 16, 2015

Severity (not sure if that's just error/warning or if we potentially have others later).

My view is that you have all the metadata an IDE/plugin needs, plus the full "compiler knows best" output which could be visible on request and would be in a "build log" type view.

paf31 added a commit that referenced this issue Nov 25, 2015
paf31 added a commit that referenced this issue Dec 12, 2015
@paf31 paf31 closed this in 11b2662 Dec 13, 2015
paf31 added a commit that referenced this issue Dec 13, 2015
Fix #1523, add --json-errors flag.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants