Description
Proposal
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 never have a field of the same name.
This PR adds a "$message_type" field to all 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.
Implementation at rust-lang/rust#115691
Edit: Why call the field $message_type and alternatives?
- The
$prefix avoids any possible collision with a real field name in any of the message structures. message_typeshould help readers understand that this is specifically the type of the message, vs some kind of "type" contained in any of the messages themselves.
The rationale for choosing type specifically was that, as a Rust keyword, it has a very low likelihood of collision with a real field name that we actually want to use. I think kind is a particular risk for that, since its so widely used as a synonym for type because of the keyword collision issue.
Secondly, type is accurate since it's basically a reflection of the underlying rustc type being serialized into the diagnostic output.
Thirdly, it is a common (perhaps even the conventional) name used for this purpose - for example in the serde documentation.
message_kind (etc) would work of course, but be a bit verbose. There's a risk that this kind of name could be misunderstood as being part of the message content itself rather than as a designator/disambiguator (i.e. effectively external to the payload of the serialized structure) - more of a risk than type.
type could be confusing at first glance because it could be interpreted as referring to a type name pertaining to the diagnostic. However in practice this is unlikely because 1: a field isn't going to be called type because of the keyword issue, and 2: while the content could technically look like a type name, in practice it doesn't look much like a real one.
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.