cargo fix: Can fixes be applied incrementally?

[alexcrichton]

Issues like #5775 keep cropping up where we have buggy lints in the compiler, and I don't think they'll ever stop unfortunately! Are there strategies that cargo fix can take to mitigate the impact of these bugs?

When I reduce test cases like #5775 I just manually apply all fixes until I get one that doesn't fail, then I go on to the next one, rinse, and repeat. Eventually there's a very small handful of suggestions left that can't be automatically applied for whatever reason, and that's where the bug is!

Perhaps we should build this in to cargo fix? If the fixes fail to compile we could abort entirely and then iteratively fix one at a time (perhaps warning the user that the process may take awhile).

@killercup WDYT?

[killercup]

Interesting idea, @alexcrichton! We can probably approach this a few different ways, with increasing slowness of cargo-fix:

• Apply one lint type at a time and recompile in between
• Apply lints for a source file at a time and recompile in between
• Apply each suggestion one by one and recompile in between
• Additionally, we can also try to recognize the compilation failures rustc generates and apply suggestions to files that show no compile error and apply the suggestions to other ones one by one.

Approach three will take the longest time but also give the best results. I'd be fine with implementing this as fallback (even an automatic one), and in the end present the user with a good error message to send to us.

[alexcrichton]

Yeah I think the third approach there is probably the best one. It'll take awhile but if we warn the user I think that's fine (and in general it's otherwise fast).

[alexcrichton]

Hm ok I'm going to close this because upon further reflection I'm not sure there's anything we can do about this. The specific motivation of unreachable_pub is particularly thorny, but we can remain vigilant for opportunities like this.