Tracking Issue for cargo report future-incompat

[pnkfelix]

This is a tracking issue for the RFC "Cargo report future-incompat" (rust-lang/rfcs#2834).
There is no feature gate for the issue (the changes are not language visible).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (cc @rust-lang/cargo -- but pnkfelix will either implement or write up mentoring instructions)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• There are future-incompatibility warnings emitted by cargo itself, such as discussed on rust-lang/cargo#6313 (comment). It shouldn't require much effort to incorporate support for such lints, but pnkfelix has not explicitly addressed nor seriously investigated this.
• This doesn't work in some editors. Some editor integrations don't display warnings from Cargo itself, because those warnings are not emitted as JSON (see Provide Cargo messages as JSON messages cargo#8283). I'm concerned that users may not see these warnings.
• There is a concern about the performance impact in Cargo where it needs to "replay" the output cache of every dependency for every command. In the normal case, only dependencies that generate future incompatible warnings will generate these files, and it is hoped that the number of dependencies that produce these is very small (preferably zero). However, if it becomes normal to have a large number of dependencies with warnings, this can introduce a nontrivial performance impact, particularly on Windows or slow hard drives.
• Color handling is awkward. One of the use cases is that the user runs cargo in an editor, sees the message that they need to run cargo describe-future-incompatibilities, they do that, and the message isn't colored. Ideally I would think the report data would be saved to the file in a more raw form, and then just re-render it as requested (instead of capturing the color at build time). DONE: Updates to future-incompatible reporting. cargo#9606
• I think the command should save at least a few reports in the on-disk file, so that if there are things like background jobs (like cargo watch), it doesn't make it difficult to view a report. I think it should save the reports as an array, and just trim it to at most N reports. It could also use monotonic numeric IDs instead of the strange random IDs (the next ID could be computed by 1+ the max ID in the file). Then the report command could default to showing the report with the greatest ID when not given an ID. DONE: Updates to future-incompatible reporting. cargo#9606
• The message to "run cargo describe-future-incompatibilities" could also include the target directory if using a non-default one.
• The Cargo Team is discussing introducing a cargo report subcommand that would subsume all user-report functionality (rather than having a bunch of top-level subcommands). This could replace describe-future-incompatibilities with something like cargo report future-incompatibilities. Add report subcommand. cargo#9438
• The RFC discussed a mechanism to silence the warnings (Annoyance modulation). I'm not sure exactly what that should look like, but un-silenceable warnings can be frustrating, especially if it is not possible to update the offending dependency (or no new version is available).
  • Related to above, will need to think about how these can be denied.
• With --future-incompat-report, if there are zero warnings, it should probably say so. Emit note when --future-incompat-report had nothing to report cargo#9263
• There is a concern that the current warnings and reports may be confusing or un-actionable for most users. See Tracking Issue for cargo report future-incompat #71249 (comment) and Tracking Issue for cargo report future-incompat #71249 (comment).

Implementation history

• Implement rustc side of report-future-incompat #75534: Implement rustc side of report-future-incompat
• Implement future incompatibility report support cargo#8825: Implement cargo side of report-future-incompat
• Emit note when --future-incompat-report had nothing to report cargo#9263: Emit note when --future-incompat-report had nothing to report
• Add report subcommand. cargo#9438: Rename to cargo report future-incompatibilities
• Updates to future-incompatible reporting. cargo#9606

[Aaron1011]

I'm interested in working on this.

Would it be better to add additional data to each JSON diagnostic message (e.g. future_compat: { breakage_release: "1.47.0" }), or emit a single 'summary' message at the end of compilation?

[pnkfelix]

Hi @Aaron1011 ; come on over to the zulip thread for the MCP and we can discuss more. (In the MCP I went with "single summary" at the end, but we can talk more about the options on zulip.)

[Aaron1011]

I have a pull request up at #75534