Skip to content

Add -warn-json flag to produce warnings in JSON format [experiment]#9758

Closed
nojb wants to merge 1 commit intoocaml:trunkfrom
nojb:warn_json
Closed

Add -warn-json flag to produce warnings in JSON format [experiment]#9758
nojb wants to merge 1 commit intoocaml:trunkfrom
nojb:warn_json

Conversation

@nojb
Copy link
Copy Markdown
Contributor

@nojb nojb commented Jul 13, 2020

This PR is a weekend experiment adding a -warn-json <output-file> to output warnings in JSON format. The objective is to make it easier for other tools to interact with the compiler programmatically. Currently the warnings are not printed in human-readable format when this flag is passed.

For example, if

(* foo.ml *)

let f x y = y
let g = f; 12
module Q (M : sig type t end) = struct end

the command-line ocamlc -warn-json - -c foo.ml (the - argument to -warn-json means to output on stderr) produces

[
  {
    "id": "60",
    "message": "unused module M.",
    "is_error": false,
    "loc": {
      "loc_start": {
        "pos_fname": "foo.ml",
        "pos_lnum": 5,
        "pos_bol": 30,
        "pos_cnum": 40
      },
      "loc_end": {
        "pos_fname": "foo.ml",
        "pos_lnum": 5,
        "pos_bol": 30,
        "pos_cnum": 41
      },
      "loc_ghost": false
    },
    "sub_locs": []
  },
  {
    "id": "34",
    "message": "unused type t.",
    "is_error": false,
    "loc": {
      "loc_start": {
        "pos_fname": "foo.ml",
        "pos_lnum": 5,
        "pos_bol": 30,
        "pos_cnum": 48
      },
      "loc_end": {
        "pos_fname": "foo.ml",
        "pos_lnum": 5,
        "pos_bol": 30,
        "pos_cnum": 54
      },
      "loc_ghost": false
    },
    "sub_locs": []
  },
  {
    "id": "27",
    "message": "unused variable x.",
    "is_error": false,
    "loc": {
      "loc_start": {
        "pos_fname": "foo.ml",
        "pos_lnum": 1,
        "pos_bol": 0,
        "pos_cnum": 6
      },
      "loc_end": {
        "pos_fname": "foo.ml",
        "pos_lnum": 1,
        "pos_bol": 0,
        "pos_cnum": 7
      },
      "loc_ghost": false
    },
    "sub_locs": []
  },
  {
    "id": "10",
    "message": "this expression should have type unit.",
    "is_error": false,
    "loc": {
      "loc_start": {
        "pos_fname": "foo.ml",
        "pos_lnum": 3,
        "pos_bol": 15,
        "pos_cnum": 23
      },
      "loc_end": {
        "pos_fname": "foo.ml",
        "pos_lnum": 3,
        "pos_bol": 15,
        "pos_cnum": 24
      },
      "loc_ghost": false
    },
    "sub_locs": []
  }
]

The PR is very rough as it is an experiment. It would be great to hear from those developing external tools that interact with the compiler: what kind of information would you like to see in the JSON output? Would you like to have a similar treatment for errors? etc.

cc @jeremiedimino, since this could be relevant for dune.

@ghost
Copy link
Copy Markdown

ghost commented Jul 13, 2020

Something like this would definitely be nice for Dune :)

BTW, I remember that @Octachron mentioned to me that he had an outreachy intern working on this subject.

As a parenthesis, with #9538 this seems to be the second PR that is trying to add JSON output to OCaml. It'd be nice to have a discussion on caml-devel about what format we want to choose for the compiler to talk to other applications.

@trefis
Copy link
Copy Markdown
Contributor

trefis commented Jul 13, 2020

It'd be nice to have a discussion on caml-devel about what format we want to choose for the compiler to talk to other applications.

Agreed.
Since we're on that subject: in merlin we also output errors and warnings as json-objects, but we use a slightly simpler representation for locations:

{
  start: { line: XX, col: XX },
  end: { line: XX, col: XX }
}

We could definitely change that and update all the editors to understand the new format that you propose here. But are we sure these extra details are ever useful (for tools that are just processing error/warning reports that is)?

As for the PR itself: I understand this is an experiment, but I'd be surprised if we added support for warnings and not for errors.

@nojb
Copy link
Copy Markdown
Contributor Author

nojb commented Jul 13, 2020

It'd be nice to have a discussion on caml-devel about what format we want to choose for the compiler to talk to other applications.

Agreed.

I sent an email in this direction.

Since we're on that subject: in merlin we also output errors and warnings as json-objects, but we use a slightly simpler representation for locations:

{
  start: { line: XX, col: XX },
  end: { line: XX, col: XX }
}

We could definitely change that and update all the editors to understand the new format that you propose here. But are we sure these extra details are ever useful (for tools that are just processing error/warning reports that is)?

No, we are not :) I think it makes sense to use the simplified format you suggest. If merlin already has well-tested infrastructure to output warnings/errors in JSON format, perhaps it makes more sense to upstream that instead?

As for the PR itself: I understand this is an experiment, but I'd be surprised if we added support for warnings and not for errors.

Agreed.

@nojb
Copy link
Copy Markdown
Contributor Author

nojb commented Jul 13, 2020

@Octachron @muskangarg21 can you confirm you are working or planning to work on this issue? If yes, I would like to close the present PR to avoid duplicating efforts. Thanks!

@ulugbekna
Copy link
Copy Markdown
Contributor

ulugbekna commented Jul 13, 2020

I think this PR could be the first step to getting more structured warnings and errors, which could, for example, help us with this issue on the ocaml-lsp side.

(also pinging a related issue #7123)

@Octachron
Copy link
Copy Markdown
Member

@nojb , yes, in fact, we have a prototype that works for warnings, alerts, and error for the compilers, and also handles the debug (-dparsetree, -dlambda, ...) and expression output for the toplevels. We went a bit on a wild goose chase to handle the debug output for the compilers but I will try to extract the part that is already working in an independant PR soonish.

@nojb
Copy link
Copy Markdown
Contributor Author

nojb commented Jul 13, 2020

Thanks!

@nojb nojb closed this Jul 13, 2020
@ulugbekna
Copy link
Copy Markdown
Contributor

@Octachron I wonder how the PR is coming along; I'd volunteer to help if necessary :-)

@Octachron
Copy link
Copy Markdown
Member

The PR branch is here: https://github.com/muskangarg21/ocaml/commits/json-error. It only needs to be cleaned up a little, which I should have the time hopefully next week.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants