summary refs log tree commit diff
path: root/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2023-11-21 06:30:14 +0000
committerbors <bors@rust-lang.org>2023-11-21 06:30:14 +0000
commit85c42b751e65bd77044163e35a3b73ed7d15bec3 (patch)
tree58d7226a7952a6b611808b5f9fe5f03134e734b6 /src
parent390e3c8b6615afb4f0b9bb2c3db3ad033ac75d78 (diff)
parentfe50c5359e863cfefe18382d7e63ba188c505f07 (diff)
downloadrust-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.md14
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.
     */