Add witness crates that demonstrate how each breaking change is breaking

[obi1kenobi]

What is and is not a breaking change is really tricky, and #5 contains many examples of breaking changes that are very much not obvious. We're already writing test crates that exemplify the breaking changes when implementing new lints: we add an old and new crate, where the new crate makes a breaking change. We also have some test crates (e.g. this PR) where we believe something is non-breaking, but would love to be sure.

It would be great to include additional witness crates that either:

• Demonstrate how each breaking change is breaking: they compile fine against the old crate, and fail to compile due to the breaking change.
  • This would complete the example of why that change is breaking, and would be constructive proof that we are indeed reporting an actually-breaking change.
• Demonstrate that some change is not breaking, by using the old and new code interchangeably in some tricky way.
  • Sometimes, it's not obvious whether a change will break some piece of code or not. The best way to prove it is to attempt to compile that exact scenario and see if it errors or not. See this PR for an example.

Mentioned in #203 and #337.

[Diggsey]

It would be cool (and not that hard?) to automatically generate a witness crate for the actual issue identified, not just a generic witness crate for that type of issue.

This could also be a good way to detect false-positives in advance, since it would be hard to write witness generation for a flawed lint... Certianly it would at least make you think about edge cases more.

edit:
This could also inform severity - eg. losing Sync trait might be considered a less severe breaking change if the type was never constructable. (Not being constructable would impact what kind of witness crate you could generate).

[obi1kenobi]

It would be cool (and not that hard?) to automatically generate a witness crate for the actual issue identified, not just a generic witness crate for that type of issue.

Cool idea! Would you perhaps be interested in prototyping it? It sounds like you have a viable approach in mind already.

edit: This could also inform severity - eg. losing Sync trait might be considered a less severe breaking change if the type was never constructable. (Not being constructable would impact what kind of witness crate you could generate).

It's certainly possible that losing Sync might not be breaking at all, even: if the type isn't directly constructible with a literal or any function that returns a value of that type. Any cascading losses of Sync on other types causing breaking changes can arguably be blamed on those types' loss of Sync in turn.