Differentiate between suggestions which are programmatically applicable and those which are not

[Manishearth]

@killercup has rustfix, which parses suggestion output and attempts to apply it.

However, sometimes the suggestions will have fillers (_ or ...) in them because they can't generate a snippet for that code. Or it is just not possible to generate an accurate suggestion.

We still want to generate these incomplete suggestions for human readers to manually go the last mile and apply, but JSON consumers probably should differentiate between the two.

It would be nice if the span_suggestion APIs had a bool argument (that is included in the output json) we could use to differentiate between suggestions which are programmatically applicable and those which aren't.

cc @jonathandturner @GuillaumeGomez

[killercup]

It might also be advisable to choose a specific placeholder for all fillers in suggestions, that is not valid Rust code and will immediately alert the user of a suggestion gone wrong. For examples, ####.

[GuillaumeGomez]

Suggestions are a bit broken in some (very few) cases, and I think that applying them might cause great troubles. As long as such problems exist (even if there are very few), I think we should not propose to apply provided suggestions.

[oli-obk]

duplicate of #37085 and #33691

[nrc]

As long as such problems exist (even if there are very few), I think we should not propose to apply provided suggestions

This seems wrong - we are not proposing automatically changing code, we are saying the user will run a tool and opt-in to each change, so there is a chance to verify the change, and if it is wrong they can undo (either literally in an IDE, or using a VCS or whatever). So, I don't think we have to be at all perfect to be useful (in fact I don't think we ever can be).

[Manishearth]

I'm thinking of adding this given that rustfix is maturing.

I'm going to add the boolean field to all the span_suggestion* methods, and do a rough audit of the suggestions in rustc and see when they're applicable. Alternatively, I could not add the field and let them all be applicable-by-default, and then add a separate method for this. Thoughts?

[killercup]

I'd go with making it opt-in to avoid burning people trying this, and also to ensure the suggestions have passed some amount of review. While we can't ensure that the suggestions always work, we can get a good estimate by only setting auto_applicable: true for suggestions we have tests for/that have been reviewed.

We should probably do a "help us review all our suggestions" thing, to get awareness of this feature once rustfix/fixing-in-vscode-via- RLS is more mature. And we can always add an override option for rustfix/rls to apply all suggestions for those who want to help test them. (Let's call it the "improve our error messages" initiative of 2018!)

[Manishearth]

Actually, it seems like most of the Rust ones are all machine applicable. I'll just add two new methods, and if @killercup discovers any bad suggestions we can migrate them over.

In clippy, I'd expect this to look like:

let machine = true;
// span_to_snippet sets `machine` to false if it ends up using the fallback
let snippet1 = span_to_snippet(e.span, "<type>", &mut machine);
...
span_lint_with_suggestion_approximate(cx, ....., machine)

The methods I'm adding do not take a bool parameter, but we'll add a helper in clippy that does.