Lint to detect semantic versioning failures

[nikomatsakis]

It would be nice if cargo can give you warnings when you try to publish a new version of a package that obviously breaks the API of a previous version.

An important but easily overlooked part of this would be whether a type is sendable etc.

[thehydroimpulse]

Perhaps when a registry is online it could outright refuse (perhaps with an override) to push a new change when a breaking change happened and the semantic versioning has not been appropriately changed (i.e., they bumped the patch, but the change needs to bump the major).

[steveklabnik]

Yeah, there has been some small amount of discussion about attempting to determine breakage as part of the metatdata the central server has.

[wycats]

@thehydroimpulse yes, that's the idea 😄

[emberian]

The tool should be separate from cargo, with a subcommand that shells out to it.

[conradkleinespel]

I'm very much interested in this issue. I would like to help.

Given that this issue is marked as E-hard, how can I know if I would be able contribute in a meaningful way? Would you happen to have any pointers as to what I should look into? I'm thinking clippy might be a good way to learn about lints.

Even if I turn out not to be skilled enough to actually code the thing, I'd be happy to help with testing, documenting or anything else related to this issue.

Side note @cmr: why should this be separate from cargo?

[alexcrichton]

Yeah this is indeed unfortunately E-hard because it will involve some significant and independent design and implementation work. There's not much of a skeleton to go off today other than the idea that this would in theory boil down to an "AST diff" tool.

[jonas-schievink]

I've been thinking that we could use the incremental compilation infrastructure (once it's set up): Save incr. comp. data for the old version, and check what has changed in the new version. Of course, this would still need a set of "breakage rules" that dictate which changes are OK for which kind of version bump, but at least finding changes is then done by the compiler.

[conradkleinespel]

@alexcrichton Alright, thanks.
@jonas-schievink Oh, that sounds like a good idea. I'm off to read the relevant RFC then.

[dwijnand]

Looks (unless I'm confused) like GSoC 2017 led to the creation of https://github.com/rust-lang-nursery/rust-semverver, which seeks to address this. Looks like that needs more work, in anyone here is interested.