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

Deliver OCaml Compiler Errors in JSON format (or Sexp) #7123

Closed
vicuna opened this issue Jan 11, 2016 · 9 comments
Closed

Deliver OCaml Compiler Errors in JSON format (or Sexp) #7123

vicuna opened this issue Jan 11, 2016 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Jan 11, 2016

Original bug ID: 7123
Reporter: jordojw
Status: acknowledged (set by @shindere on 2017-02-24T15:59:11Z)
Resolution: open
Priority: normal
Severity: feature
Category: compiler driver
Monitored by: @Drup @gasche @diml @hcarty

Bug description

It would be much easier to build tooling for the OCaml compiler if OCaml type errors (or any error for that matter), was delivered in a format such as JSON or sexp. Ideally, errors would be serialized into something loosely typed so that as new versions of the OCaml compiler don't break the compilation of build tooling. The serialized errors can include rich information such as the nature of the error, specific line numbers that are relevant, inferred/mismatched types - all encoded into an error structure that developer tooling can use to provide very nicely formatted/integrated feedback to developers.

Right now, the only other thing that can be done is to create giant banks of regexes that extract out very complicated structures of type errors. That approach could be crowd-sourced, but it will inevitably be fragile so I am requesting official compiler support for serializing rich information about errors.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @shindere

Not sure this will be implemented. However, it seems that for the moment errors are not numbered whereas warnings are. Perhaps assigning numbers to errors would help and at the same time be coherent with what is done for warnings?

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @Octachron

As a first step, having unique ids for errors might be nice, in particular for documentation purpose. This may warrant a separated issue however.

@XVilka
Copy link
Contributor

XVilka commented Mar 20, 2019

FYI: GCC 9 added support for outputting warnings and error messages in JSON format, just use -fdiagnostics-format=json option.

It seems getting more popular to produce machine-readable output of compilers, partially because of the rise of static analysis tools. For example in Rust: cargo rustc --message-format=json or Haskell: ghc -ddump-json

So it might be a good time to rethink the suggestion.

@gasche
Copy link
Member

gasche commented Mar 20, 2019

I'm not sure what you mean by "rethink the suggestion". Volunteers to work on this are welcome!

We have made some progress on the structure of error messages in 4.07 and 4.08, but I htink it will still take a bit of massaging of the codebase to finish moving from the previous "print stuff" approach to "return data that describes the failure, following a proper API" . I think we need to think a bit more about the design to know what we want -- for example, maybe a useful intermediate step would be to ensure that one can use compiler-libs to get a nice OCaml representation of the error messages and warnings during compilation.

(@jordwalke: feel free to get in touch if you would be interested in contributing to the compiler codebase upstream but are not sure how to proceed.)

@github-actions
Copy link

github-actions bot commented May 9, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 9, 2020
@Drup
Copy link
Contributor

Drup commented May 9, 2020

As before, I think this is something that is welcome, but it needs a volunteer to do the work. It seems half of it has already been done outside the compiler and it would be nice to upstream it.

@gasche gasche removed the Stale label May 9, 2020
@gasche
Copy link
Member

gasche commented May 9, 2020

There is ongoing preliminary work in this direction in #9538.

@shindere
Copy link
Contributor

shindere commented May 27, 2020 via email

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants