diff options
| author | bors <bors@rust-lang.org> | 2023-11-21 06:30:14 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-11-21 06:30:14 +0000 |
| commit | 85c42b751e65bd77044163e35a3b73ed7d15bec3 (patch) | |
| tree | 58d7226a7952a6b611808b5f9fe5f03134e734b6 /src | |
| parent | 390e3c8b6615afb4f0b9bb2c3db3ad033ac75d78 (diff) | |
| parent | fe50c5359e863cfefe18382d7e63ba188c505f07 (diff) | |
| download | rust-85c42b751e65bd77044163e35a3b73ed7d15bec3.tar.gz rust-85c42b751e65bd77044163e35a3b73ed7d15bec3.zip | |
Auto merge of #115691 - jsgf:typed-json-diags, r=est31,dtolnay
Add `$message_type` field to distinguish json diagnostic outputs Currently the json-formatted outputs have no way to unambiguously determine which kind of message is being output. A consumer can look for specific fields in the json object (eg "message"), but there's no guarantee that in future some other kind of output will have a field of the same name. This PR adds a `"type"` field to add json outputs which can be used to unambiguously determine which kind of output it is. The mapping is: `diagnostic`: regular compiler diagnostics `artifact`: artifact notifications `future_incompat`: Future incompatibility report `unused_extern`: Unused crate warnings/errors This matches the "internally tagged" representation for serde enums.
Diffstat (limited to 'src')
| -rw-r--r-- | src/doc/rustc/src/json.md | 14 |
1 files changed, 11 insertions, 3 deletions
diff --git a/src/doc/rustc/src/json.md b/src/doc/rustc/src/json.md index 11d7b5b5938..9daa0810126 100644 --- a/src/doc/rustc/src/json.md +++ b/src/doc/rustc/src/json.md @@ -11,9 +11,11 @@ If parsing the output with Rust, the [`cargo_metadata`](https://crates.io/crates/cargo_metadata) crate provides some support for parsing the messages. -When parsing, care should be taken to be forwards-compatible with future changes -to the format. Optional values may be `null`. New fields may be added. Enumerated -fields like "level" or "suggestion_applicability" may add new values. +Each type of message has a `$message_type` field which can be used to +distinguish the different formats. When parsing, care should be taken +to be forwards-compatible with future changes to the format. Optional +values may be `null`. New fields may be added. Enumerated fields like +"level" or "suggestion_applicability" may add new values. ## Diagnostics @@ -29,6 +31,8 @@ Diagnostics have the following format: ```javascript { + /* Type of this message */ + "$message_type": "diagnostic", /* The primary message. */ "message": "unused variable: `x`", /* The diagnostic code. @@ -217,6 +221,8 @@ flag][option-emit] documentation. ```javascript { + /* Type of this message */ + "$message_type": "artifact", /* The filename that was generated. */ "artifact": "libfoo.rlib", /* The kind of artifact that was generated. Possible values: @@ -239,6 +245,8 @@ information, even if the diagnostics have been suppressed (such as with an ```javascript { + /* Type of this message */ + "$message_type": "future_incompat", /* An array of objects describing a warning that will become a hard error in the future. */ |
