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
Comments
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? |
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. |
FYI: GCC 9 added support for outputting warnings and error messages in JSON format, just use 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: So it might be a good time to rethink the suggestion. |
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 (@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.) |
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. |
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. |
There is ongoing preliminary work in this direction in #9538. |
Gabriel Radanne (2020/05/09 08:08 -0700):
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.
That's part of the job I am supposed to do during my time with Cambium.
|
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. |
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.
The text was updated successfully, but these errors were encountered: