Add future-incompat entries to json diagnostic output

[pnkfelix]

Proposal

Add future-incompat entries to json diagnostic output. (Also, ensure we always run code for future-incompatibility lints, even if they are allowed.)

This is part of rust-lang/rust#71249 (rust-lang/rfcs#2834); it is the implementation of the rustc side of that feature.

This change is broken into these main parts:

• In JSON diagnostic mode, if a future-incompatibility lint is triggered for a crate, regardless of the current lint level, it will issue at least one additional JSON output describing the lint.
  • My current plan is to have all such output be emitted at the end, after all other diagnostics.
  • The emitted diagnostics will include span info, when availble, so that client code can choose how best to present feedback about the problem to the end user.
• For the initial deployment, use an allow-list so that only a subset of the current collection of future-incompatibility lints will actually trigger this new JSON emission. Over time we will increase the number of entries in the allow-list, with the hope of eventually removing the allow-list entirely once all the future-incompatibility lints are covered.
• Extend compiletest to be able to handle the generated JSON output.
  • I want to test this feature within rustc's test suite on its own; therefore, compiletest will convert these generated JSON entries to stderr diagnostics (as opposed to just discarding them, as it currently does for artifact notifications), even though a normal user running in human-readable diagnostic mode will not observe them.
• We need to also ensure that all future-incompatibility lint checks are executed (in order to observe this diagnostic) regardless of the current lint level. I have not yet surveyed the compiler to check the situation here.

Mentors or Reviewers

I have a prototype implementation: https://github.com/pnkfelix/rust/tree/prototype-rustc-side-of-report-future-incompat

I plan to mentor the work (or finish the above prototype).

Process

The main points of the Major Change Process is 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 merge on either the MCP or the PR.
• 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.

[rustbot]

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.

[nikomatsakis]

@rustbot second