As promised, here is the recap from the rustfix meeting.
Rustfix
The release of the 2018 edition also included a very cool new cargo subcommand: cargo fix. It enables you to quickly migrate over to the new edition by automatically applying the suggestions that are part of the compiler’s error/warning messages. But that is by far not the only use case this can have: The underlying mechanism (implemented in the rustfix library) is in theory able to apply any kind of suggestion the compiler can generate – as long as it can tell that the suggestion is unambiguous and leads to code that compiles.
The meeting we had in Berlin however was not about the general progress and future of rustfix or cargo-fix, though, but on one specific issue: Differentiating suggestions with multiple possible fixes from fixes that need to change multiple parts of a file. One issue we had in the past was that the JSON-based diagnostics output that rustfix gets from the compiler flattens the (otherwise recursive) structure of suggestions. This is not a problem for the unambiguous suggestions we get from the edition lints, but there are some lints in the compiler (or in clippy!) that require rustfix to make multiple edits (e.g. this). As a precaution, right now we treat these the same as suggestions with multiple possible fixes (e.g., this). At the meeting we discussed ways to lift that restriction and enable fixes for the first case.
You can find the meeting notes here.
We also plan to establish an official rustfix working group. Expect an announcement soon.