We want to have diagnostics that emit fixable suggestions based on multiple edits; and also have the ability to emit multiple incompatible suggestions.
The problem
At the moment, the current JSON output doesn’t have any way to disambiguate between a diagnostic with multiple suggestions affecting one span each and a single suggestion affecting multiple spans, because they’re represented in the same way. Rustfix and other tools needs to disambiguate between the two, so we need to encode this information in some way.
Possible solutions
Status quo
Split multiple solutions
Add ad-hoc field
One substitution with one span
Supported
Supported
Supported
One substitution with multiple span
Ambiguous
Supported
Supported
Multiple substitution with one span each
Ambiguous
Supported / Breaking
Supported
Multiple substitution with multiple spans each
Ambiguous
Supported / Breaking
Ambiguous
Splitting multiple solutions into multiple childs
Right now, the diagnostic output is based on recursive types, where the children property is a vector of diagnostics. We’d like to make use of that to split the two cases“multiple incompatible substitutions” and“one substitution that changes the code in multiple places”.
This solution is better because it supports all the current and future use cases, but it’s a breaking change for whoever handles multiple substitutions, like eh0uss reported on the issue. The breaking change is quite small and don’t actually break any code, it will just report one of the substitutions instead of all the available ones.
This solution only adds a new field to the existing objects that is true if the diagnostic contains only one substitution with multiple spans, while keeping the current behavior. This means all the existing code still works the same but it’s possible to opt into the ability to disambiguate multiple substitutions and a single one if someone explicitly wants it.
It doesn’t handle the case of multiple substitutions with multiple spans each, but the compiler doesn’t have them at the moment. There is a plan to create a version 2 of the JSON output, so concerns about the limits of this solution are less pressing(on the new JSON output we can add breaking changes freely).
Summary
The problem
Possible solutions
Splitting multiple solutions into multiple childs
Adding an ad-hoc field