Making SemVer Breakage Obvious – GSoC 2025

Oh, uh... hi! Didn't expect anybody to actually come read this... huh

I guess I should introduce myself real quick. I'm Talyn, a first year undergraduate comp-sci student, rust enthusiast and long time programmer. More relevantly, I'm also one of the Google Summer of Code contributors with the Rust Foundation for GSoC 2025! More specifically, I'll be working on adding automatic witness program generation to cargo-semver-checks over this summer. I'm very excited to be here as a part of GSoC this year, and I'm very optimistic for how it'll go. I decided to make this little blog post to give a very short overview of my plans and project, and just to introduce myself to the community!

So what is a witness program?

First off, if you aren't familiar with what semver is, or what cargo-semver-checks is, I recommend doing at least little reading before diving in. Alright, so what is a witness program? In simple terms, a witness program in this context means any valid, compilable Rust program that functions on a prior version of your crate, but fails to compile on the new version due to whatever breaking change was added. Sounds fairly simple, right? For example, if your crate used to export a struct, but then made that private, a witness program could just be a program that tries to import the struct, thus failing to compile on the new version. The complicated part here is making these witnesses automatically, no matter the crate we're testing.

How I plan to implement that whole thing I just described

Going based off my original proposal, and a little plan layout from Predrag Gruevski (my mentor), my plan for this summer will probably look something a bit like this:

1. Adding the actual basic witness generation system. Yes, that's a bit of a "draw the rest of the owl", but admittedly, the existing systems in cargo-semver-checks should actually make this somewhat trivial to implement. We just won't have any actual witnesses implemented for each lint, just the capability to theoretically do so.
2. Once we have the actual system that creates these witness, I'll need at least one or two simple witnesses just to work with, which should be hopefully be quite reasonable to implement.
3. Here's where it actually gets interesting. I'm not only going to be making a system that generates witnesses, but automatically tests them as well. That means importing both versions of the crate in question, and then getting the rust compiler to try and compile them. We should expect to see that the baseline compiles successfully, and the new version does not. Then, we can visibly show the user "See! It breaks, right there, just like that!". But what if that's not what we see? What if both version compile successfully? While this obviously means we can't report all that much to the user about their code, it's still quite useful to us, because it means we've got a bug somewhere!
4. That's where this stage comes in: diagnostics collection. More specifically, in the event that a generated witness doesn't create the expected behaviour during compilation, that means that cargo-semver-checks should collect as much data about that lint as possible, and pack it up for you (the user) to hopefully submit as an issue! This should ideally help us make a better, more consistent cargo-semver-checks experience, by allowing the capture of most false-positives.

So that's a lot... but also surprisingly feasible, and I'm very excited to get started!

Why I think you should care

Libraries are everywhere, external crates are an fairly integral part of the Rust ecosystem, and maintaining the contract promised by semantic versioning is important to avoid unintended breakages for crate users. I think that having tools like cargo-semver-checks available for anybody and everybody to use is a great way to help uphold that contract, because while we like to think we won't accidentally add a breaking change when we don't want to, it happens surprisingly often. That's a problem for pretty much everyone, and so if nothing, I'm hoping this summer to help improve the ease of avoiding semver violations, making for a better, more reliable and safe experience for everyone!

So what now?

Well, unfortunately, due to some personal issues I've had a bit of a bumpy start to Google Summer of Code, but hopefully it should start going a bit more smoothly from now on. Unfortunately, that does mean I don't have much to report on so far, but I'm planning to make more of these blogs as the summer goes on, so keep an eye for those!

In general though, it has been really good to meet some of the other GSoC contributors and mentors, and I'm extremely honoured to be here, as a part of it all. I hope if you read to the end of this little blog, that you enjoyed it! I will admit, my blog may be a little less "professional" than you might expect, but I really don't want to be some mysterious voice on the other side of your screen. After all, I'm just another person and I want to show that! So again, thanks for reading!