Predrag Gruevski's blog and personal site.

The Self-Cancelling Subscription

2026-04-01T00:00:00+00:00

Happy April 1st! This post is part of April Cools Club</a>: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy this true story, and rest assured that the tech content will be back soon!

One Friday night a few months ago, my family and I sat down to relax and enjoy a TV show on our streaming platform of choice. The subscription was a perk of one of our credit cards, and we had been satisfied customers for several months.

This time was different. Instead of a "Continue watching" button, we saw "Start your free trial."

Our streaming subscription had been deactivated.… 

Exponential growth continued — cargo-semver-checks 2025 Year in Review

2026-01-11T00:00:00+00:00

Last year's annual review post</a> observed that cargo-semver-checks</code>' lint library is undergoing exponential growth, doubling each year: 30 lints at the end of 2022, 57 lints in 2023, and 120 at the end of 2024. We bring 2025 to a close with 242 lints, more than doubling last year's total — and that's just one facet of what we accomplished. Let's look at the full picture, and the path for 2026 and beyond!
Ghosts in the Compilation 2025-10-31T00:00:00+00:00 Recently, a cargo-semver-checks</code> user reached out with a conundrum: cargo-semver-checks</code> reported being unable to build their crate, but when they ran cargo check</code> themselves, it always completed successfully. Something cursed was going on! The fix is part of the upcoming cargo-semver-checks v0.45</code> release—what better day than Halloween to talk about this ghost story!Unsoundness and accidental features in the #[target_feature]</code> attribute 2025-07-05T00:00:00+00:00 Researching the SemVer hazards of the #[target_feature]</code> attribute led to finding unexpected unsoundness, discovering an "accidental feature" in Rust, finding bugs</a> in rustdoc</a>, the creation of an RFC that evolves the Rust language</a>, and the addition of a dozen new SemVer lints. My work on cargo-semver-checks</code> benefits the Rust ecosystem in more ways than just preventing breakage! XORry Not Sorry: The Most Amusing Security Flaws I've Discovered 2025-04-01T00:00:00+00:00 Happy April 1st! This post is part of April Cools Club</a>: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy these true stories, and rest assured that the tech content will be back soon! The mouse started moving. Not the one on the desk, the pointer on the screen! First to the left, then down to the bottom corner. *Click!* The Windows Start menu came up. "cmd" wrote a silent hand on an invisible keyboard. It downloaded a file from a random-looking URL, then executed it. *Pop* went both the computer and the illusion of security. When is "this trait can be implemented" part of the trait's public API? 2025-03-08T00:00:00+00:00 cargo-semver-checks</code> v0.40 ships a massive upgrade to its system for detecting sealed traits. The new system is an all-around win-win: it improves the accuracy of a dozen existing lints, enables a new series of helpful lints, handles cyclic trait relationships, and is also faster than the old system. All that took a lot of work! Here's a look at how we made it happen. "We never update unless forced to" — cargo-semver-checks 2024 Year in Review 2025-01-21T00:00:00+00:00 cargo-semver-checks</code> ends 2024 having improved dramatically over the course of the year: 12 new releases featuring 63 new lints, with 1175 merged PRs from 57 authors across the many repos that make the project tick. Let's recap what we learned, the biggest things we shipped, and the facets of the project that made it to the conference and podcast circuits. Breakage! in the Cargo.toml — How Rust Package Features Work (And Break) 2024-12-04T00:00:00+00:00 cargo-semver-checks</code> v0.37</a> can now scan Cargo.toml</code> files for breakage! In this post: a primer on Rust package features, and how innocuous-looking Cargo.toml</code> changes can break your users. Is this trait sealed, or not sealed — that is the question 2024-09-03T00:00:00+00:00 cargo-semver-checks</code> v0.35</a> can determine whether Rust traits are "sealed", allowing it to catch many tricky new instances of SemVer breakage. Why is accurate sealed trait detection so important, and why is implementing it correctly so hard? How to Query (Almost) Everything 2024-07-22T00:00:00+00:00 In 2022, I gave a talk at a virtual conference with an unforgettable name: HYTRADBOI, which stands for "Have You Tried Rubbing a Database On It?"</a> Its goal was to discuss unconventional uses of database-like technology, and featured many excellent talks. My talk "How to Query (Almost) Everything" received</a> copious</a> praise</a>. It describes the Trustfall</a> query engine's architecture, and includes real-world examples of how my (now-former) employer relies on it to statically catch and prevent cross-domain bugs across a monorepo with hundreds of services and shared libraries. For example: The Wi-Fi only works when it's raining 2024-04-01T00:00:00+00:00 Happy April 1st! This post is part of April Cools Club</a>: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy this true story, and rest assured that the tech content will be back soon! That's what my dad said when I asked what was wrong with our home internet connection. "The Wi-Fi only works when it's raining." </figure> Let's back up a few steps, so we're all on the same page about the utter ridiculousness of this situation. At the time, I was still a college student — this was over 10 years ago. I had come back home to spend a couple of weeks with my parents before the fall semester kicked off. I hadn't been back home in almost a full year, because home and school were on different continents. My dad is an engineer who had already been tinkering with networking gear longer than I'd been alive. Through the company he started, he had designed and deployed all sorts of complex network systems at institutions across the country — everything from gigabit Ethernet for an office building, to inter-city connections over line-of-sight</a> microwave links. He is the last person on Earth who would say a "magical thinking"</a> phrase like that. "What?" I uttered, stunned. "The Wi-Fi only works while it's raining," he repeated patiently. "It started a couple of weeks ago, and I haven't had a chance to look into it yet." "No way," I said. If anything, rain makes wireless signal quality worse</a>, not better. Never better! Two weeks without reliable internet? I started a speed-run through the stages of grief... Denial</h2> I pulled open my laptop and started poking at the network. Pinging any website had a 98% packet loss rate. The internet connection was still up, but only in the most annoying "technically accurate" sense. Nothing loads when you have a 98% packet loss rate! The network may as well have been dead. I was upset. I had just started dating someone a few months prior, and she was currently on the other side of the planet! How was I to explain that I couldn't stay in touch because it wasn't raining?^{</label>^{ [Sidenote: Mobile data at the time was exorbitantly expensive, so much so that I didn't have a data plan at all for my cell service at home. I couldn't just use my phone's data plan to work around the problem, like one might do today in a similar situation.] }} I was pacing around the house, fuming. Grief, stage two! That's when the rain started. Bargaining</h2> Like a miracle, within 5 minutes of the rain starting, the packet loss rate was down to 0%! I couldn't believe my eyes! I was ready for the connection to die at any second, so I opened a million tabs at once — as if I don't normally do that anyway... The rain held up for about an hour, and so did the internet connection. Then, 15 minutes or so after the rain stopped, the packet loss rate shot back up to 90%+. The internet connection went back to being unusable. I was ready to do just about anything to get more rain. Thankfully, the weather stayed grey and murky for the next few days. Each time, the pattern stayed the same: The rain starts, and not even a few minutes later the internet connection is crisp and fast.</li> The rain stops, and within 15 minutes the internet connection is unusable again.</li> </ul> As much as I hated to admit it, the evidence was solid. The Wi-Fi only works when it's raining! At this point, I had a choice to make. I could keep going through the stages of grief: I could sulk and plan my calls with my girlfriend around the weather forecast. Or, I could break out of that downward spiral and get to the bottom of what was going on. "Magical thinking</a> be damned! Am I an engineer or what?" I told myself. That settled it. I wasn't going to take this lying down. Determination</h2> Some context on our home networking setup is in order. Remember how my dad's company had extensive experience with networking solutions? Well, we had a fancy networking setup at home too — and it had worked flawlessly for the best part of 10 years! My dad's office had a very expensive, very fast^{</label>^{ [Sidenote: For the time, of course.] commercial internet connection. The home internet options, meanwhile, weren't great! In my family, we are often stubbornly against settling for less unless there's absolutely no other choice.}}The office and our apartment were a few blocks away from each other along a small hill, with our second-floor apartment holding the higher ground. With a bit of work, my dad set up a line-of-sight Wi-Fi bridge — a couple of high-gain directional Wi-Fi antennas pointed at each other</a> — between the office and our apartment. This let us enjoy the faster commercial internet connection at home! I started poking around the network to figure out where the connection was breaking down. The local Wi-Fi router at home was working well — no packets lost. The local end of the Wi-Fi bridge was fine too. But pinging the remote end of the Wi-Fi bridge was showing a 90%+ packet loss rate — and so did pinging any other network device behind it. Aha, there's something wrong with the Wi-Fi bridge! But what? And why now, when the system had been working fine for almost 10 years, rain or shine?^{</label>^{ [Sidenote: Maybe}}years of work experience isn't a good metric</a> here either 😄] How can a rain storm fix a Wi-Fi bridge, anyway? So many confusing questions. Time to get some answers! Debugging</h2> Like any experienced engineer, the first thing I tried was turning everything off and then on again. It didn't work. Then I checked all the devices on the network individually: Maybe one of the devices has gone bad with age? Nope.^{</label>^{ [Sidenote: I physically connected my laptop to each device's local Ethernet, then ran diagnostics, pinged the devices over the wired connection, etc.] </li>}} Maybe a cable got unseated or came loose? Nope.</li> Maybe a power brick has become faulty over time? Nope.</li> Maybe an automatic firmware update failed and broke something? Nope.</li> Maybe an antenna connector has corroded from spending years outdoors? Nope.</li> </ul> Unlike debugging software, a lot of this hardware debugging was annoyingly physical. I had to climb up ladders, trace cables that hadn't been touched in 10 years, and do a lot of walking back and forth between our home and my dad's office. On my umpteenth back-and-forth walk, as I was bored and exasperated, I started noticing how much our neighborhood had changed in the many years I hadn't been living at home full-time.^{</label>^{ [Sidenote: Before college, I spent four years at a boarding high school. I was on our national math and programming teams for the}}IMO</a> and IOI</a>), so I even spent most of each summer away from home at prep camps and at the competitions themselves.] Many of the little neighborhood shops were new. Many houses had gotten a fresh coat of paint. Trees that used to be barely more than saplings had grown tall and strong. Then it hit me. Realization</h2> I ran home and climbed up onto the scaffolding holding up the Wi-Fi bridge's antenna. I was hanging precariously off the side of our apartment building, two stories up in the air.^{</label>^{ [Sidenote: In retrospect, a safety harness would have been a good idea... Things people do for internet! Don't forget, a girl was involved too — I wasn't doing this merely for Netflix or Twitter.] }} Then I looked downhill, at the antenna that formed the second half of the Wi-Fi bridge. Or at least, toward the antenna, because I couldn't see it — a tree in a neighbor's yard was in the way! Its topmost branches were swaying back and forth in the line-of-sight between the antenna pair. Bingo! The Problem and the Fix</h2> Here's what was going on. Many years ago, we installed the Wi-Fi bridge. For a long time, everything was great! But every year, our neighbor's tree grew taller and taller. Shortly before when I came back home that summer, its topmost branches had managed to reach high enough to interfere with our Wi-Fi signal. It was only barely tall enough to interfere with the signal, though! Every time it rained, the rain collected on its leaves and branches and weighed them down. The extra weight bent them out of the way of the Wi-Fi line-of-sight!^{</label>^{ [Sidenote: Interestingly,}}objects outside the straight line between antennas can still cause interference</a>! For best signal quality, the Fresnel zone</a> between the antennas should be clear of obstructions. But perfection isn't achievable in practice, so RF equipment like Wi-Fi uses techniques like error-correcting codes so that it can still work without a perfectly clear Fresnel zone.] Each time the rain stopped, the rainwater would continue to drip off the tree. Slowly, over the course of 15ish minutes, that would unburden the tree — letting it rise back up into the path of our bits and bytes. That's when the Wi-Fi would stop working. The fix was easy: upgrade our hardware. We replaced our old 802.11g devices</a> with new 802.11n ones</a>, which took advantage of new magic</del> math and physics to make signals more resistant to interference.^{</label>^{ [Sidenote: One such piece of magic new to 802.11n Wi-Fi is called "}}beamforming</a>" — it's when a transmitter can use multiple antennas transmitting on the same frequency to shape and steer the signal in a way that improves the effective range and signal quality. Modern Wi-Fi does beamforming with only a few antenna elements, but if we scale that number way up we get a phased array antenna</a>. Ever wondered how come Starlink antennas are flat</a> and not a "dish" like old satellite TV antennas</a>? They use phased arrays to aim their signal at the Starlink satellites streaking across the sky</a> — without any moving parts. Magic!</del> Physics!] A few days later, the new gear arrived and I eagerly climbed back up the scaffolding to install the new antennas. A few screws, zip ties, and cable connections later, the Wi-Fi's "link established" lights flashed green once again. This time, it wasn't raining. All was well once again. Hope you enjoyed this true story! April Cools</a> is about surprising our readers with fun posts on topics outside our usual beat. Check out the other April Cools posts on our website</a>, and consider making your own blog part of April Cools Club next year! If you liked this post, consider subscribing or following me on social media</a>. Thanks to Hillel Wayne</a> and Jeremy Kun</a> for reading drafts of this post. All mistakes are my own. SemVer in Rust: Tooling, Breakage, and Edge Cases — FOSDEM 2024 2024-03-18T00:00:00+00:00 Last month, I gave a talk titled "SemVer in Rust: Breakage, Tooling, and Edge Cases"</a> at the FOSDEM 2024</a> conference. The talk is a practical look at what semantic versioning (SemVer) buys us, why SemVer goes wrong in practice, and how the cargo-semver-checks</code> linter can help prevent the damage caused by SemVer breakage. TL;DR: SemVer is impossibly hard for humans, but automated tools can cover our greatest weaknesses.… Four challenges cargo-semver-checks has yet to tackle 2024-01-23T00:00:00+00:00 My last post</a> covered the key cargo-semver-checks</code> achievements from 2023. Here are the biggest challenges that lie ahead! Many of the remaining challenges in cargo-semver-checks are obvious: we all want more lints, fewer false-positives, etc. etc. Let's set those aside. Instead, let's talk about four non-obvious challenges we have yet to tackle: The Obvious in Retrospect</a></li> The Blocked Upstream</a></li> The Surprising Limitation</a></li> The Existential Threat</a></li> </ul> Highlights of 2023 for cargo-semver-checks 2024-01-16T00:00:00+00:00 2023 was a big year for cargo-semver-checks</code>! We saw ecosystem-wide adoption in projects of all shapes and sizes: the tokio</code></a> and PyO3</code></a> ecosystems, company-backed OSS projects from companies like Amazon</a> and Google</a>, and even in cargo</code> itself</a>. Here's a look back at the highlights of 2023! Checking semver in the presence of doc(hidden) items 2023-11-18T00:00:00+00:00 cargo-semver-checks</code> v0.25 squashes nearly all bugs related to doc(hidden)</code> items — its most common source of false-positives. What does doc(hidden)</code> mean in Rust, and why was handling it correctly so hard? Semver violations are common, better tooling is the answer 2023-09-07T00:00:00+00:00 This post is coauthored by Tomasz Nowak</a> and Predrag Gruevski. It describes work the two of us did together with Bartosz Smolarczyk, Michał Staniewski, and Mieszko Grodzicki. Anecdotally</a>, cargo-semver-checks</code> is a helpful tool for preventing the semver violations that every so often cause ecosystem-wide pain. This is why it earned a spot in the CI pipelines of key Rust crates like tokio</code></a>, and also why the cargo</code> team hopes to integrate it into cargo</code> itself</a>. While anedotal evidence is nice, we wanted to get concrete data across a large sample of real-world Rust code.… Breaking semver in Rust by adding a private type, or by adding an import 2023-05-08T00:00:00+00:00 A few days ago, I started polls on Mastodon</a> and Twitter</a> whether adding a new private type, or an import, can ever be a major breaking change. The consensus was that this should be impossible. I agree with that. It should be impossible. I've discovered a way to cause a previously-public type or function to disappear from a crate's public API by making innocuous-seeming changes like adding a private type or adding an import, etc. It is not a hypothetical problem, either — I've found at least one real-world Rust project that has been affected by it. A definitive guide to sealed traits in Rust 2023-04-05T00:00:00+00:00 For the longest time, I thought that "sealed trait" in Rust was a singular concept implementable in one specific way. To prevent downstream crates from implementing your traits, you make the traits sealed — done, end of story. I was wrong! It turns out there are multiple ways to seal traits</a>, forming a pleasant spectrum of options: Mediocrity can be a sign of excellence, and other stories 2023-04-01T00:00:00+00:00 Happy April 1st! This post is part of April Cools Club</a>: an effort to publish genuine posts on topics our usual audience would find unexpected. The tech content will be back soon! Over the many years I spent heavily involved in intern and full-time recruiting at $PREVIOUS_JOB</code>, multiple people have commented something to the effect of: "How come Predrag always gets the best people?" This post is a series of vignettes showing three of the less-obvious ideas that gave us an edge,… Re-exporting an enum with a type alias is breaking, but not major 2023-03-06T00:00:00+00:00 We've already explored some of the dark corners of Rust semantic versioning on this blog: Speeding up Rust semver-checking by over 2000x 2023-02-07T00:00:00+00:00 This post describes work in progress: how cargo-semver-checks</code></a> will benefit from the upcoming query optimization API in the Trustfall query engine</a>. Read on to learn how a modern linter works under the hood, and how ideas from the world of databases can improve its performance. Moving and re-exporting a Rust type can be a major breaking change 2023-01-31T00:00:00+00:00 I recently embarked on a quest: revamp the cargo-semver-checks</code> import-handling system so that moving and re-exporting an item stops being incorrectly flagged as a major breaking change. This is how crate authors can reorganize or rename items: just re-export the items in the original location under their original names, and downstream users shouldn't notice. Sounds simple, right? I thought so too. Then I started coming up with strange edge cases</a>, each more cursed than the last. But cargo-semver-checks</code> has to handle them correctly, cursed or not! So off I went down yet another Rust rabbit hole... After a few weeks of adventuring, I have emerged, seemingly^{</label>^{ [Sidenote: Only time will tell, won't it? It's looking good so far, though I did}}originally miss at least one edge case</a>.] victorious! Let me now regale you with some tales from my travels.^{</label>^{ [Sidenote: Although 'travails' might be a more accurate word choice.] }} Moving and re-exporting an item</h2> Say we have a crate called example</code> containing the following code: pub struct Foo {}</code></pre> Rust modules can include other modules' items in their own API: they can use pub use</code> to re-export the other module's item. Our example</code> crate's users won't notice if we do the following change: pub(crate) mod inner { pub struct Foo {} } // Users of this crate can import this // as `example::Foo` just as before. pub use inner::Foo;</code></pre> The re-export is allowed to rename the item: pub(crate) mod inner { // Renamed; used to be called `Foo`. pub struct Bar {} } // Users of this crate can import this // as `example::Foo` just as before. pub use inner::Bar as Foo;</code></pre> Re-exports can also use a "glob" pattern to select and re-export all public items in the target module: pub(crate) mod inner { pub struct Foo {} } // Users of this crate can import // `example::Foo` just as before, // because all public items in `inner` // are selected for re-export. pub use inner::*;</code></pre> So far so good! But now the fun begins... Using a type alias to re-export</h2> Rust's pub type</code> statement allows us to define a type alias</a>, an "equivalent name" for some Rust type. This isn't the same thing as pub use</code>, but in many cases^{</label>^{ [Sidenote: Ominous music starts...] can be used equivalently to pub use</code>. For example, we could use a pub type</code> to accomplish the same renaming that earlier used a pub use</code> by doing the following:}} pub(crate) mod inner { // Renamed; used to be called `Foo`. pub struct Bar {} } // Users of this crate can import this // as `example::Foo` just as before. pub type Foo = inner::Bar;</code></pre> Many crates use pub type</code> instead of pub use</code> to re-export items. Some crates actively encourage using pub type</code> instead of pub use</code>, for reasons that are out of scope here. They produce valid Rust code, and cargo-semver-checks</code> should support that code. Using pub type</code> as if it were a pub use</code> is fine ... most of the time. But every so often, it's a ✨ major breaking change! ✨ Accidental major breaking change via pub type</code></h2> Say our original crate had defined Foo</code> to be a unit struct instead of a plain struct: // Previously, `Foo` was defined // with curly braces like so: // `pub struct Foo {}` pub struct Foo;</code></pre> We now make the same completely innocuous-seeming change as before: pub(crate) mod inner { // Renamed; used to be called `Foo`. // This one is also a unit struct: // no curly braces this time. pub struct Bar; } // Is this `Foo` equivalent to the old one? pub type Foo = inner::Bar;</code></pre> 💥 Oops! 💥 What happened? The idiomatic way to construct a unit struct is to just name it: let _ = Foo</code>. But that doesn't work</a> if Foo</code> is a type alias to a unit struct! error[E0423]: expected value, found type alias `Foo` < ... > = note: can't use a type alias as a constructor</code></pre> The same thing happens if Foo</code> is a tuple struct: Foo(42)</code> works fine on the struct itself but doesn't work on the type alias</a>.^{</label>^{ [Sidenote: There's an}}open issue</a> suggesting that in a future Rust edition, this kind of pub type</code> may become completely equivalent to a pub use</code>. In that case, this would no longer be a breaking change. Thanks to this r/rust comment</a> for the link!] This seems like exactly the sort of thing one would find right after publishing a new version, when some poor user opens an issue saying their build is now broken. How cargo-semver-checks</code> handles this</h2> The immediate goal (achieved in v0.17) was to stop flagging re-exports as major breaking changes. In our philosophy, it's better to miss a real semver-major change than to falsely report a breaking change. Nobody likes it when CI turns red due to a tool being wrong. Prior to 0.17, cargo-semver-checks</code> would simply miss many re-exports and would claim that the type had been entirely removed from the API. That lint was obviously not correct — not even in the case of a pub type</code> of a unit or tuple struct as in the example above. We plan to add a new lint</a> to catch this case and explain the specific problem in detail, since we expect most users would be quite surprised to see a major breaking change reported there. Conclusion</h2> Did you notice the major breaking change above? Probably not, right? You are not alone! I only found it because someone pointed me in the correct general direction</a>. Semver in Rust is hard to get right</a>, example number zillion and one, right here. This is why we use automated tools. And I haven't even gotten a chance to bring up any truly cursed Rust examples of re-exports yet.^{</label>^{ [Sidenote: I wrote approximately 30 test crates while implementing this. Nearly all of them are more cursed than any code in this post. They are split between cargo-semver-checks</code>}}itself</a> and its dependency</a> crate</a> trustfall-rustdoc-adapter</code>, which allows cargo-semver-checks</code> to declaratively query</a> rustdoc JSON via the Trustfall query engine</a>.] If my adventure into Rust re-exports is like Frodo's journey in Lord of the Rings, then this post covers Frodo leaving his front yard. If you liked this post, let me know! Then I'll write up the rest of the trip to Mount Doom. Some Rust breaking changes don't require a major version 2023-01-26T00:00:00+00:00 I've been saying</a> for a while now</a> that semantic versioning in Rust is tricky and full of unexpected edge cases</a>. My last post</a> mentioned that some Rust structs can be converted into enums without requiring a major version bump. It introduced a non-exhaustive struct called Chameleon</code> that had no public fields, and claimed it was totally safe to turn it into an enum. But surely there was some sort of mistake, since syntax like let Chameleon { .. } = value</code> would break if the Chameleon</code> struct became an enum? Yes, that statement would break.^{</label>^{ [Sidenote: Thanks to the alert readers on r/rust and Mastodon that pointed it out and even provided Rust Playground links!}}This discussion</a> was particularly nuanced and interesting.] And yet, this breaking change does not require a major version under Rust's semantic versioning rules! How could a breaking change not be a semver-major change? Let's dig in and find out! All major changes are breaking, but not all breaking changes are major</h2> There are two authoritative sources for semantic versioning in Rust: the cargo semver reference</a>, and the API evolution RFC</a>. Here's what the API evolution RFC says about breaking changes: What we will see is that in Rust today, almost any change is technically a breaking change. For example, given the way that globs currently work, adding any public item to a library can break its clients [...] But not all breaking changes are equal. So, this RFC proposes that all major changes are breaking, but not all breaking changes are major. Rust API evolution RFC</a> </footer> </blockquote> This feels ... strange. Running cargo update</code> will by default update dependencies to the latest version in the same major version series, yet breaking changes are allowed without a new major version? Ultimately, I feel^{</label>^{ [Sidenote: I only recently got involved in Rust's semver story by working on cargo-semver-checks</code>, so I wasn't part of the discussion or decisions in the API evolution RFC. This post is on my personal blog, not the Rust blog, so you're reading my own opinion and interpretation.] this is a case of Rust choosing pragmatism — and in my opinion, getting it right. I'll try to convince you of this in the rest of this post.}} Let's take a look at two examples where breaking changes are explicitly not semver-major. Adding a new public item is technically a breaking change</h2> Let's pretend that in the below example, first</code> and second</code> are dependency crates of our library. pub mod first { pub struct Foo; } pub mod second { // what happens if we uncomment this? // pub struct Foo; } use first::*; use second::*; fn process(foo: &Foo) { // do stuff with foo }</code></pre> Our library uses globs to import all public items from first</code> and second</code>. This works fine!</a> Now imagine second</code> adds some new functionality: uncomment its pub struct Foo</code> line. This is a purely additive change: second</code> can still do everything it could previously do, and has gained some new functionality via the new type Foo</code>. Purely additive API changes are semver-minor, right? Try compiling the code</a> after uncommenting that line, though. 💥 Oops! 💥 error[E0659]: `Foo` is ambiguous --> src/lib.rs:13:18 | 13 | fn process(foo: &Foo) { | ^^^ ambiguous name | = note: ambiguous because of multiple glob imports of a name in the same module < ... fix suggestions omitted for brevity ... ></code></pre> The code that depends on both first</code> and second</code> was broken by second</code>'s purely additive change. Additive or not, it was unquestionably a breaking change.^{</label>^{ [Sidenote: If you read the API evolution RFC's}}section on adding public items</a>, you may have noticed that its example of breaking code by adding a public item is much shorter than the one here — and also that in today's Rust, that example isn't broken anymore! This is because Rust adopted another recommendation from that RFC: if a locally-defined item's name conflicts with a glob-imported name, the local item "wins" and shadows the other one instead of breaking with an ambiguous resolution error.] If Rust semver demanded that all breaking changes must be semver-major, here are a few ways this could work: Option 1: Nearly all API additions are semver-major. This obviously doesn't seem right.</li> Option 2: Glob imports are "last definition wins" (like in Python), or "first definition wins." I think this makes the problem worse, not better: now it's even less obvious which Foo</code> is getting imported, and we're setting ourselves up for even worse compilation errors than otherwise.</li> Option 3: Glob imports are removed from the language, since they play a part in causing this problem. That also means no more prelude</code> modules designed for glob-importing, harming the ergonomics of awesome crates like pyo3</code> and futures</code>. This isn't good either.</li> Option 4: When we write code like &Foo</code>, a tool (say, cargo</code> or rustc</code>) immediately replaces Foo</code> with its fully-qualified name: in this case, first::Foo</code>. Glob imports serve only to tell that tool where to look while rewriting our code. This solution has way too many moving pieces, and doesn't feel particularly ergonomic, either.</li> </ul> None of these options are good. Rust opted to go in another direction: adding public items is semver-minor;</li> glob imports are discouraged, to minimize (but not prevent) breakage, and</li> maintainers of crates with prelude</code> modules are encouraged to be mindful of what they add to the prelude, again to minimize but not prevent breakage.</li> </ul> A similar problem exists with trait methods: implementing a public trait for any existing type is also technically breaking</a>, and is also explicitly defined as semver-minor despite the breakage.^{</label>^{ [Sidenote: The}}RFC states that</a> the breakage occurs if the breakage-causing trait already existed prior to being implemented. But in the RFC's example code, it's actually sufficient for the trait to make its way into crate B's scope. For example, crate B glob-importing of all of crate A's public items would cause the same breakage even if the conflicting trait did not previously exist.] Breakage of patterns is not always semver-major</h2> Pattern-matching on structs is always allowed in Rust, even if the struct being matched has no visible fields: playground link</a>. // say this is in some other crate pub mod other { pub struct Foo(i64); } fn process(value: &other::Foo) { // Foo's field is not visible here! // This `let` does nothing useful: // - it can't extract any fields, and // - can't learn anything else about `value`. let Foo { .. } = value; }</code></pre> Some kinds of changes to Foo</code> can cause let Foo { .. } = value;</code> to break. The RFC is unambiguous here</a>: statements like let Foo { .. } = value</code> serve no purpose other than to be broken if Foo</code> changes, and its breakage is not sufficient to make this change semver-major.^{</label>^{ [Sidenote: Again, the}}RFC's example for this case</a> doesn't quite work as written: Rust has evolved in the nearly 8 years since that RFC was written. But its point stands regardless.] There are cases where the Foo { .. }</code> pattern is useful to aid type inference, for example: if let Some(x @ Foo { .. }) = x.downcast_ref()</code>.^{</label>^{ [Sidenote: Thanks to}}this r/rust comment</a> for this excellent example!] However, those cases are specifically addressed in the RFC as well (original emphasis retained): For example, changes that may require occasional type annotations or use of UFCS to disambiguate are not automatically "major" changes. [...] any breakage in a minor release must be very "shallow": it must always be possible to locally fix the problem through some kind of disambiguation that could have been done in advance (by using more explicit forms) or other annotation (like disabling a lint). Principles of the policy, Rust API evolution RFC</a> </footer> </blockquote> This is why turning Chameleon</code> from a struct into an enum in the last post</a> did not require a new major version: the only breakage that could happen was in type inference or in a statement that did not serve any purpose. Barring some kind of exceptional situation (e.g., potential for ecosystem-wide breakage, definitely not the case here), the API evolution RFC explicitly disqualifies both of those categories from triggering a semver-major change. Conclusion</h2> Before reading this post, did you know that not all breaking changes require a new major version under Rust's semantic versioning principles? Semver in Rust is hard for many reasons. There are a zillion strange ways to cause major breaking changes: example</a>, another example</a>. There's even "spooky action at a distance" where adding a field to a type can cause traits to silently stop being implemented for that type</a>. And as we saw here, not all breaking changes are semver-major! As if to prove my point, cargo-semver-checks</code> was recently broken</a> by a dependency crate's semver-incompatible (and now yanked</a>) release.^{</label>^{ [Sidenote: This is why installing with cargo install --locked</code> is a good idea! Locked installs didn't break.] Breaking semver is not shameful, and is not a sign of maintainers' carelessness, poor skill, or anything of the sort. It's just another language ergonomics problem solvable by better tooling.}} This is the raison d'être for cargo-semver-checks</code>. Turning a Rust struct into an enum is not always a major breaking change 2023-01-24T00:00:00+00:00 EDIT: The Rust API evolution RFC</a> distinguishes between breaking changes and changes that require a new semver-major version (called major changes). All major changes are breaking, but not all breaking changes are major. Changing a struct to an enum is always breaking (as pointed out on r/rust</a>) but is not always major (equivalent to this case</a>). In this post, we're trying to avoid making a major change.^{</label>^{ [Sidenote: The title and content has been slightly edited since the original publication for clarity on the "major vs breaking" point.] }} Upholding semantic versioning is critical in the Rust ecosystem</a>. But semver has a million non-obvious edge cases. It's unreasonable to expect</a> all Rustaceans to master semver trivia to be able to safely publish crates — and it doesn't make for a welcoming, inclusive environment, either. cargo-semver-checks</code> cares about the edge cases of semver compliance so you won't have to. To do that, it must also correctly implement all those edge cases. Every so often, my work on cargo-semver-checks</code> leads me to a semver edge case that surprises me. For example: turning a Rust struct into an enum doesn't necessarily require a major version! Here's how! Our protagonist in this post is pub struct Chameleon</code>. Our goal is to turn it into pub enum Chameleon</code> without needing to release v2.0 of our (fictional) crate. Not every struct is capable of this feat, so we'll show how our little camouflaged friend manages to blend into the environment so well. Implemented methods and traits</h2> One possible major breaking change is removing the implementation of a method or trait on pub enum Chameleon</code> when that method or trait were implemented for the old pub struct Chameleon</code>. Any code that relies on that method or trait will be broken when the method or trait disappears. In fact, many kinds of major breaking changes are possible within impl</code> blocks. To make things easy on ourselves: We won't change or remove any #[derive(...)]</code> or similar derive-macro attributes that already existed on the struct.</li> We'll be careful when altering existing impl Chameleon</code> or impl SomeTrait for Chameleon</code> blocks. Removing or altering methods, changing implemented traits' associated types, or changing the bounds on a trait implementation can all be major breaking changes.</li> We'll keep an eye on our type's auto-traits</a> — we don't want to find out our new type is not Send</code> or Sync</code> like in a prior post</a>.</li> </ul> As of v0.16.0, cargo-semver-checks</code> can automatically check some of this: The inherent_method_missing</code> lint</a> ensure that all inherent methods (ones in impl Chameleon</code>, not impl Foo for Chameleon</code>) continue to exist.</li> Other lints check that methods did not change their number of parameters</a>, did not stop being const</code></a>, did not become unsafe</code></a>, etc.</li> The auto_trait_impl_removed</code></a>, sized_impl_removed</code></a>, and derive_trait_impl_removed</code></a> lints check that auto-traits</a>, the special Sized</code> marker trait</a>, and built-in traits used in #[derive(...)]</code></a> did not stop being implemented.</li> As of v0.16, cargo-semver-checks</code> is not able to check method parameter or return types, trait associated types, or generic bounds. Here's our tracking issue for not-yet-implemented lints</a>.</li> </ul> Public fields</h2> Rust structs may have publicly-visibile fields: pub struct NotChameleon { pub name: String, }</code></pre> Given such a struct, code in another crate is allowed to read or mutate that field directly: fn rename(value: &mut NotChameleon) { println!("Current name: {}", value.name); // reading the field value.name = "Not a chameleon".to_string(); // mutating the field }</code></pre> Rust enums cannot have fields — they only have variants</a>. If pub struct NotChameleon</code> here became an enum, all accesses of the name</code> field would be broken since that field no longer exists! This is why our pub struct Chameleon</code> must not expose any fields directly. Instead, it uses accessor methods to provide both immutable and mutable access to its contents: pub struct Chameleon { name: String } impl Chameleon { pub fn name(&self) -> &str { &self.name } // one option: an explicit setter pub fn set_name(&mut self, name: String) { self.name = name; } // another option, useful to allow appending // to the existing string without copying first pub fn name_mut(&mut self) -> &mut String { &mut self.name } }</code></pre> The implementation of these accessor methods may need to change as a result of the switch from struct to enum, but those changes are internal implementation details. The methods' callers will remain blissfully ignorant of the change. Since the NotChameleon</code> struct has public fields, attempting to turn it into an enum without incrementing the major version will trigger a lint in cargo-semver-checks</code></a>. Our friend Chameleon</code> has no public fields, and won't have that problem. Surprise! One more thing to consider</h2> Just for fun, let's now say that Chameleon</code> has no fields whatsoever — not even private fields. Perhaps it's a unit struct like pub struct Chameleon</code> or an empty tuple struct like pub struct Chameleon()</code>, or even an empty plain struct like pub struct Chameleon {}</code>. Quick aside: did you know that changing between those three struct kinds can be a major breaking change? Don't worry, cargo-semver-checks</code> has you covered</a> with its lints</a>. Anyway... Since the struct has no fields, there are no field accesses to worry about when changing it to an enum. We'll leave all the impl</code> blocks and #[derive(...)]</code> attributes untouched, so all the methods and traits will be fine. Looks good to me, ship it! 🚀 💥 Oops!! 💥 We broke semver 😬 Thankfully cargo-semver-checks</code> runs in our release pipeline before cargo publish</code></a>: </figure> Here are examples of struct literal syntax for unit, tuple, and plain structs: let _ = UnitStruct; let _ = EmptyTupleStruct(); let _ = EmptyPlainStruct {};</code></pre> If the Chameleon</code> struct was usable like this, converting it to an enum would be a major breaking change. We couldn't create an enum value like this — we have to specify a particular enum variant, not just supply the enum's name with parens or curly braces. Fortunately, Rust's built-in #[non_exhaustive]</code> attribute</a> can prevent other crates from using the literal syntax to directly create Chameleon</code> values, instead requiring them to use a constructor like Chameleon::new()</code>. But be careful: adding #[non_exhaustive]</code> to an existing type or enum variant is itself a major breaking change — one that cargo-semver-checks</code> will</a> always</a> catch</a>. So for the Chameleon</code> struct with no fields to be able to become an enum without a major change, it must have been marked #[non_exhaustive]</code> at the time it was originally added to the public API. One day, cargo-semver-checks</code> might even start suggesting that you consider adding #[non_exhaustive]</code> when you add a type like this to your crate's public API — but that's a topic for a future post. Conclusion</h2> Semver violations are much like memory safety violations: They can happen to anyone, even if you're extremely careful.</li> There's an overwhelming amount of real-world evidence of the above.</li> Automated tools can prevent semver violations, or at least significantly reduce their likelihood.</li> </ul> cargo-semver-checks</code> is not yet a perfect tool. For example, it catches an ever-growing yet still incomplete list of semver issues</a>. At the same time, adopting cargo-semver-checks</code> v0.16 today means 40 fewer possible kinds of semver violations in your crate's API. Specifically, it will prevent exactly the semver violations that have already happened in past versions of clap</code>, pyo3</code>, and many other top crates</a>. What's stopping your crate from adopting cargo-semver-checks</code> today? I'd love to hear about it</a> and resolve it! cargo-semver-checks today and in 2023 2022-12-23T00:00:00+00:00 cargo-semver-checks</code> ends 2022 with 40,000 downloads from crates.io</a>, able to prevent 30 different kinds of semver issues, and having done so in real-world use cases</a>. Inspired by Yoshua Wuyts' "Rust in 2023 (by Yosh)"</a> post, here are my thoughts on cargo-semver-checks</code> in 2022, and what I look forward to in 2023 and beyond. Following semver in Rust is a perfect example of a workflow worth automating: Important to get right, painful if done wrong: cargo</code> requires all crates to follow semver, so breaking semver in one crate can have a ripple effect across the ecosystem.^{</label>^{ [Sidenote: I recently}}re-learned this lesson</a> myself, for the umpteenth time.] But if done right, semver is completely invisible.</li> Countless complex rules: There are hundreds of ways to cause a breaking change, many of them non-obvious.^{</label>^{ [Sidenote: }}The tracking issue</a> for not-yet-implemented lints in cargo-semver-checks</code> lists 60+ ways, and is far from an exhaustive list. I'm currently reading Rust for Rustaceans</a> and discovering new ways to break semver, each more surprising than the last. For a quick taste, check out my previous blog post</a>.] </li> Code that violates semver doesn't look wrong: No code reviewer can be expected to reliably flag most of the semver issues, even assuming they are well-versed in all the semver rules. The evidence</a> on this</a> point is</a> particularly</a> overwhelming</a>.</li> </ul> Some might say the solution is to "git gud"</a>. I deeply respect operational excellence</a>, but this is not the way. Civilization advances at the rate at which we develop robust abstractions. I am writing this on a computer I cannot build, under a blanket I cannot weave, having enjoyed a meal with ingredients I cannot grow. I dedicated ten years to math competitions,^{</label>^{ [Sidenote: And developing test-taking strategies aimed at}}getting a perfect score given limited time!</a>] and I can't even calculate a logarithm by hand! Can you?^{</label>^{ [Sidenote: If my life depended on it, I'd use the}}Newton-Raphson method</a> to approximate my way to it, but there's zero chance that's actually the best way. My friends with aero-astro engineering degrees still find it hilarious that I once used binary search to calculate orbital maneuvers</a> for Kerbal Space Program, instead of the closed-form formula that apparently existed 😅] Gatekeeping to only include people with a PhD in "Semver in Rust" won't cut it. Yosh Wuyts quotes another Rust contributor</a> as saying: "The job of an expert is to learn everything about a field there is to learn, and then distill it so that others don't have to."^{</label>^{ [Sidenote: I'll gladly put their name here if the quote is confirmed as coming from them. I wasn't present when this was said, and didn't want to risk misattributing.] I couldn't agree more!}} 2022: Rust + semver - tedium = 💖</h2> cargo-semver-checks</code> was born in mid-July 2022, when I realized that building a semver linter boils down to only two things: a list of machine-checkable rules, and</li> a system to check them.</li> </ul> At a high level, that's all cargo-semver-checks</code> is: a checklist</a>, and a for-loop over it</a>. As is usually the case: I wasn't the first person to realize this. cargo-semver-checks</code> isn't the first attempt at a semver linter for Rust.</li> cargo-semver-checks</code> stands on the shoulders of giants: without rustdoc JSON and serde, the same work would have taken ten times as long.</li> </ul> The novel trick in cargo-semver-checks</code> is that lint rules are written declaratively. Given the need to have hundreds of different lints defined over an ever-changing data format,^{</label>^{ [Sidenote: The rustdoc JSON format is unstable and frequently has breaking changes — sometimes even multiple times per week in nightly Rust.] this is a huge win.}} But creating a good declarative query language is a much harder problem than semver! Generally one shouldn't replace an easier problem with a harder one. This is why linters rarely build their own query language. Fortunately, I spent the last 7+ years of my career working on high-performance query languages for heterogeneous data</a>, so I didn't need to start from scratch. Instead, I just plugged in my existing Trustfall query engine</a> which is able to query any data source(s)</a> no matter whether they are local files, remote APIs, or a terabyte-scale SQL cluster.^{</label>^{ [Sidenote: Ever wonder}}which lints do popular crates like itertools</code> allow in their code</a>? Or maybe you're curious which GitHub or Twitter users comment on HackerNews stories about OpenAI</a>? The answers are one browser-executed query away!] Thanks to Trustfall, each cargo-semver-checks lint is a type-checked structured query in Trustfall's GraphQL-like syntax. (More on this in future blog posts!) In practice, this means: New lints are super easy to add: writing a new lint takes only 1-2 minutes. The vast majority of effort can then be spent on great test cases that reflect the diversity of use cases for each Rust language construct.</li> Lints are not tied to a specific rustdoc JSON format version. Even though the rustdoc JSON format changes frequently, the changes are absorbed by the Trustfall adapter for rustdoc and are completely invisible to the lints — an airtight abstraction layer.</li> cargo-semver-checks</code> benefits from the performance and correctness guarantees of Trustfall, whose optimizations and test suite are far more intricate than would be feasible to write for a semver-checker alone. (If you'd like to hear more, tell me</a> and I'll write more blog posts!)</li> </ul> All this allowed us to go from zero to 30 different semver lints in just five months. We are ending 2022 on a particularly high note: four students</a> have begun contributing to cargo-semver-checks</code> as part of their Bachelors' theses! The pace of development has sped up dramatically thanks to their hard work, and the codebase is healthier than ever. Looking ahead to 2023</h2> At RustConf 2022 I had the pleasure of meeting several cargo</code> team members, and we decided that the end goal for cargo-semver-checks</code> is merging into cargo</code> itself</a>. Another goal for cargo-semver-checks</code> is adding even more lints</a> to prevent more kinds of semver violations. These goals are self-explanatory, and I won't dig into them further. Instead, I'll mention three of my personal favorite things I'd like to see in cargo-semver-checks</code> in 2023. Proactively discover and prevent false-positives</h3> A false-positive error in cargo-semver-checks</code> is when the tool incorrectly claims it found a semver violation. I consider false-positives extremely serious bugs^{</label>^{ [Sidenote: Much more serious than false-negatives! A false-negative means there was a semver violation but the tool didn't find it. There are dozens of ways to break semver that cargo-semver-checks</code> can't yet detect, each of which is a false-negative.] because they give the user incorrect advice, confusing them and slowing them down while also hurting the credibility of cargo-semver-checks</code> itself.}}Unfortunately, in 2022 our users reported</a> multiple</a> false-positive</a> errors</a>. I am grateful to everyone that spent their precious time helping debug problems that shouldn't have happened in the first place. We have already begun strengthening</a> the cargo-semver-checks</code> test systems to discover and prevent future false-positives, so our users won't have to. In the process, we already discovered and fixed three</a> previously-unknown</a> false-positives</a>. In 2023, we plan to take a page from Rust's book: testing cargo-semver-checks</code> on the most popular crates on crates.io</a> as part of our release process. This would have a dual benefit: in addition to proactively discovering false-positives, it would also ensure cargo-semver-checks</code> is ready to be adopted by those crates at their maintainers' convenience. And if we happen to discover more semver issues in the wild, that'll be a nice bonus! Faster semver-checking via rustdoc caching</h3> A cargo-semver-checks</code> run consists of two steps: generating rustdoc JSON, and running lints over the generated JSON files. The "run the lints" step is much faster^{</label>^{ [Sidenote: Even though we've put in negligible effort at optimizing them beyond what Trustfall provides out of the box.] than the process of generating the rustdoc, which can take a few minutes in CI environments with low core counts like GitHub Actions.}} In 2023, we'll implement rustdoc caching to limit how often the rustdoc has to be rebuilt. We expect to cut rustdoc generation time in half: we'll still have to generate the current version's rustdoc, but we can avoid repeatedly rebuilding rustdoc for crate versions that are already published on crates.io</a>. Semver-check PRs, not just cargo publish</code></h3> Currently, cargo-semver-checks</code> is most ergonomic when used right before cargo publish</code>: it checks whether the publish step with the specified version^{</label>^{ [Sidenote: If the version in Cargo.toml</code> is already on}}crates.io</a>, it assumes a patch version bump.] would result in a semver-compliant release. But wouldn't it be nice to know about breaking changes in a pull request before merging it and committing to a major version bump? Multiple</a> projects</a> have already begun running cargo-semver-checks</code> like this, generally via custom scripts they've adapted specifically for that purpose. In 2023, I hope we're able to make this an officially-supported mode of operation, complete with a GitHub Action. Bonus points if the Action reports semver issues as inline PR comments using the lints' span information! Onwards!</h2> I'm thrilled and humbled by the response that cargo-semver-checks</code> has received in the Rust community. I've never been more excited about building the future with Rust, and I'm excited to see what 2023 has in store for cargo-semver-checks</code> and the Rust ecosystem as a whole. Falsehoods programmers believe about undefined behavior 2022-11-27T00:00:00+00:00 Undefined behavior (UB)</a> is a tricky concept in programming languages and compilers. Over the many years I've been an industry mentor for MIT's 6.172 Performance Engineering course</a>,^{</label>^{ [Sidenote: An excellent class that I highly recommend. It's very thorough and hands-on, at the expense of also requiring a lot of work at a very fast pace. When I took it as an undergrad, that was a great tradeoff, but YMMV.] I've heard many misconceptions about what the compiler guarantees in the presence of UB. This is unfortunate but not surprising!}} For a primer on undefined behavior and why we can't just "define all the behaviors," I highly recommend Chandler Carruth's talk</a> "Garbage In, Garbage Out: Arguing about Undefined Behavior with Nasal Demons." You might also be familiar with my Compiler Adventures blog series</a> on how compiler optimizations work. An upcoming episode is about implementing optimizations that take advantage of undefined behavior like dividing by zero, where we'll see UB "from the other side." Undefined behavior != implementation-defined behavior</h2> Undefined behavior is not the same as implementation-defined behavior.^{</label>^{ [Sidenote: Undefined behavior is also not the same as}}unspecified behavior</a>, which is similar to implementation-defined behavior minus the requirement that the implementation document its choices and stick to them. Here we're focusing on undefined behavior, not unspecified behavior, so we'll lump unspecified behavior and implementation-defined behavior together.] Program behaviors fall into three buckets, not two: Specification-defined: The programming language itself defines what happens. This is the vast majority of every program.</li> Implementation-defined: The exact behavior is defined by your compiler, operating system, or hardware. For example: how many bits exactly</a> are in a char</code> or int</code> in C++.^{</label>^{ [Sidenote: The specification guarantees at least 8 bits for char</code> and at least 16 bits for int</code>. The rest is implementation-defined.] </li>}} Undefined behavior: Anything is allowed to happen, and you might no longer have a computer left after it all happens. No outcome is a bug if caused by UB. For example: signed integer overflow in C, or using unsafe</code> to create two &mut</code> references to the same data in Rust.^{</label>^{ [Sidenote: Wikipedia has}}an excellent list of examples</a> if you'd like to see more.] </li> </ul> Here's the list of guarantees compilers make about the outcomes of undefined behavior: That's the whole list. No, I didn't forget any items. Yes, seriously. It is possible to analyze how UB affects a specific program when compiled by a specific compiler or executed on a specific target platform. For example, there exist exotic compilers, operating systems, and hardware that offer additional guarantees^{</label>^{ [Sidenote: Like}}CHERI</a>, with awesome powers around pointer safety.] relative to most common platforms, which only guarantee OS-level process isolation</a>. We aren't talking about those in this post. The mindset for this post is this: "If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?" It's not a compiler bug. All of the following assumptions are wrong</h2> Falsehoods about when UB "happens"</h3> Undefined behavior only "happens" at high optimization levels like -O2</code> or -O3</code>.</li> If I turn off optimizations with a flag like -O0</code>, then there's no UB.</li> If I include debug symbols in the build, there's no UB.</li> If I run the program under a debugger, there's no UB.</li> Okay there's still UB with all of these, but my code will "do the right thing" regardless.</li> It will either "do the right thing" or crash with a Segmentation Fault</code> (SIGSEGV</code> signal).</li> It will either "do the right thing" or crash somehow.</li> It will either "do the right thing" or crash or infinite-loop or deadlock.</li> At least it won't run some unrelated code from elsewhere in the program.</li> At least it won't run any unreachable code</a> the program might contain.</li> </ol> Falsehoods around the behavior of executing UB</h3> If a line with UB previously "did the right thing," then it will continue to "do the right thing" the next time we run the program.</li> The UB line will at least continue to "do the right thing" while the program is still running.</li> It's possible to determine if a previous line was UB and prevent it from causing problems.</li> At least the impact of the UB is limited to code which uses values produced from the UB.</li> At least the impact of the UB is limited to code which is in the same compilation unit as the line with UB.</li> Okay, but at least the impact of the UB is limited to code which runs after the line with UB.^{</label>^{ [Sidenote: UB is explicitly allowed to alter the behavior of other code, even including operations preceding it! "Alter" here encompasses corrupting, undoing, or altogether preventing (as if it never happened) the outcomes of that other code. To learn more and see examples of UB causing "time travel," check out}}this blog post</a>. Thanks to these two</a> Reddit posts</a> for suggesting better wording for these items. For the original text, see the Errata section at the end of this post.] </li> </ol> Falsehoods about the possible outcomes of UB</h3> At least it won't corrupt the memory of the program.</li> At least it won't corrupt the memory of the program other than where the UB-affected data was located.</li> At least it won't corrupt the heap.</li> At least it won't corrupt the stack.</li> At least it won't corrupt the current stack frame. (My name for this is the "local variables are safely in registers" fallacy.)</li> At least it won't corrupt the stack pointer.</li> At least it won't corrupt the CPU flags register / any other CPU state.</li> At least it won't corrupt the executable memory of the program.^{</label>^{ [Sidenote: OS and hardware security features like}}W^X</a> can make this unlikely, but self-modifying programs can be built so it's in principle possible through UB as well. Certainly there's no guarantee that UB won't do this!] </li> At least it won't corrupt streams like stdout or stderr.</li> At least it won't overwrite any files the program already had open.</li> At least it won't open new files and overwrite them.</li> At least it won't completely wipe the drive.</a></li> At least it won't damage or destroy any hardware components.^{</label>^{ [Sidenote: Not all devices have the same level of self-protection against bad inputs written to their control registers. This is the kind of lesson one tends to learn the hard way.] </li>}} At least it won't start playing Doom if the program didn't already have the Doom source code in it.^{</label>^{ [Sidenote: I'd be quite impressed if you made a compiler that makes programs run Doom when they encounter UB. Consider it a challenge!] </li> </ol>}}Falsehoods like "but it worked fine before"</h3> If a UB-containing program "worked fine" previously, recompiling the program without any code changes will still produce a binary that "works fine."</li> Recompiling without code changes and with the same compiler and flags will produce a binary that still "works fine."</li> Recompiling as above + on the same machine will produce a binary that still "works fine."</li> Recompiling as above + if you haven't rebooted the machine since the last compilation will produce a binary that still "works fine."</li> Recompiling as above + with the same environment variables will produce a binary that still "works fine."</li> Recompiling as above + at the same time of day and day of week as before, during a Lunar eclipse, having first sacrificed a fresh stick of RAM to the binary gods, will produce a binary that still "works fine."</li> </ol> Falsehoods about self-consistent behavior of UB</h3> Multiple runs of the program compiled as above and with the same inputs will produce the same behavior in each run.</li> Those multiple runs will produce the same behavior if the program, ignoring the UB, is deterministic.</li> But they will if the program is also single-threaded.</li> But they will if the program also doesn't read any external data (files, network, environment variables, etc.).</li> </ol> Community-contributed falsehoods around UB</h3> Using a debugger on a UB-containing program will show program state that corresponds to the source code.^{</label>^{ [Sidenote: This is a corrolary of falsehood #16</a>, further explained in this post</a>. UB can corrupt the behavior of the program both before and after the UB, so the source code you see in your editor no longer matches the actual executing program. Of course, you can still use the debugger to step through assembly instructions and view register state. But highly optimized assembly isn't easy to understand to begin with, and UB-induced weirdness will only make it harder. Overall, a situation that is best avoided. Contributed here</a>.] </li>}} Undefined behavior is purely a runtime phenomenon.^{</label>^{ [Sidenote: In Rust, a counter-example is misusing #[no_mangle]</code>}}to overwrite a symbol with an incorrect type</a>. A C++ counter-example</a> is violations of the One Definition Rule (ODR)</a>, some of which the compiler is not required to report before causing havoc.] </li> </ol> False expectations around UB, in general</h3> Any kind of reasonable or unreasonable behavior happening with any consistency or any guarantee of any sort.</li> </ol> The moment your program contains UB, all bets are off. Even if it's just one little UB. Even if it's never executed. Even if you don't know it's there at all. Probably even if you wrote the language spec and compiler yourself.^{</label>^{ [Sidenote: Speaking from experience. Hopefully not one you have to relive to believe.] }} This is not to say that all outcomes in the list above are equally likely, or even plausible.^{</label>^{ [Sidenote: Especially the one about running Doom.] But they are all allowed, valid, spec-compliant behavior.}} It's perfectly possible that your program has UB, and it's been running fine for years without issues. That's great! I'm happy to hear it! I'm not even saying you need to go back and rewrite it to remove the UB. But as you make your decisions, it's good to know the full picture of what the compiler will or won't guarantee for your program. Honorable mention for one special assumption</h2> "If the program compiles without errors then it doesn't have UB." This is 100% false in C and C++. It's also false as stated in Rust, but with one tweak it's almost true. If your Rust program never uses unsafe</code>, then it should be free of UB. In other words: causing UB without unsafe</code> is considered a bug in the Rust compiler</a>. These are rare and you are quite unlikely to run into them. When Rust unsafe</code> is used, then all bets are off just as in C or C++. But the assumption that "Safe Rust programs that compile are free of UB" is mostly true. This is not an easy feat. We owe a debt of gratitude to the folks who cumulatively put engineer-centuries into making it so. It's Thanksgiving, and I thank you! Errata and edit history</h2> 2022-11-29: Items 13-16 corrected and updated</h3> The original version of this post contained the following items at positions 13-16 in the list: But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there.</li> Okay, but if the line with UB is unreachable (dead) code</a>, then it's as if the UB wasn't there.^{</label>^{ [Sidenote: Surprising, right? It isn't obvious why code that should be perfectly safe to delete would have any effect on the behavior of the program. But it turns out that sometimes}}optimizations can make some dead code live again</a>. EDIT: This was originally footnote #6 before being moved down here.] </li> If the line with UB is unreachable code, then the program won't crash because of the UB.</li> If the line with UB is unreachable code, then the program will at least stop running somehow and at some point.</li> </ol> This wording was not precise enough, and as a result the claims were arguably incorrect as stated. I have updated the post near those claims to better capture the subtleties involved. 2022-11-29: Added community-contributed items</h3> The "False expectations around UB, in general" section now contains a selection of community-suggested items. Previously it only contained a single item (the last one in the current list) at position number 41. Thanks to arriven</a>, Conrad Ludgate</a>, sharnoff</a>, Brian Graham, and a few folks who preferred to remain unnamed, for feedback on drafts of this post. Any mistakes are mine alone. My HYTRADBOI'22 Jam 2022-10-03T00:00:00+00:00 I had a lot of fun spending nights-and-weekends time participating in the HYTRADBOI Jam</a>, a global hack week aimed at building "exciting and weird" data-centric solutions to familiar problems. The name HYTRADBOI</a> might sound familiar: the jam is associated with the same conference where I gave my "How to Query (Almost) Everything" talk</a> talk in April this year. I jammed on two projects: one solo and one with a friend</a>. The projects ultimately were very successful and mostly-successful, respectively. Debugging Safari: If at first you succeed, don't try again 2022-09-19T00:00:00+00:00 The saying usually goes: "If at first you don't succeed, try, try again." But in the Safari web browser under the right conditions, trying again after succeeding once can get you in trouble. This is my recent debugging adventure.… Toward fearless cargo update 2022-08-25T00:00:00+00:00 I recently built cargo-semver-checks</code>, a linter that ensures crates adhere to semantic versioning. This is why and how I built it. Fearless development is a key theme throughout Rust. "If it compiles, it works"</a>, fearless concurrency</a>, etc. But there's one aspect of Rust (and nearly all other languages) that isn't entirely fearless yet: cargo update</code>, upgrading the versions of the project's dependencies. Compiler Adventures, part 3: Value Numbering 2022-05-17T00:00:00+00:00 A beginner-friendly introduction to compilers: follow along as we build a compiler from scratch, or fork the code on GitHub</a> and add your own optimizations too! In this episode: value numbering helps track how values are used in the program. Last time on Compiler Adventures</a>, we implemented constant propagation: if x = 2</code> and y = 3</code> then add x y</code> produces 5</code>. While it did help detect a few no-ops, we saw the optimization quickly become ineffective as it got overwhelmed by too many Unknown</code> values. In this episode, we'll equip our compiler with the key tool for reasoning about those Unknown</code> values. The starting code for this episode is on GitHub</a>, on branch part3</code>. ⊕</label> A cloudy twilight over the giant radio telescopes of the Very Large Array, which has been helping humanity peer into the depths of the unknown for more than 40 years. In this episode, we'll also do some peering into Unknown</code>. Source: NRAO/AUI/NSF</a>, CC BY 3.0 </figure> Let's begin by solving the challenge from the last episode</a>. When examining the following program, our compiler claimed that the program ends with an Unknown</code> value in the w</code> register:^{</label>^{ [Sidenote: I'm introducing a small change in notation to avoid confusion: instead of Input(i)</code>, from now on I'll write Input_i</code>. This will help us avoid confusing "i-th program input" with "input to the program with value i</code>." When we know a program value represents the number i</code>, we'll continue to use the notation Exact(i)</code>.] }}

Predrag Gruevski's blog and personal site.

The Self-Cancelling Subscription

Exponential growth continued — cargo-semver-checks 2025 Year in Review

Ghosts in the Compilation

Unsoundness and accidental features in the #[target_feature]</code></nobr> attribute

XORry Not Sorry: The Most Amusing Security Flaws I've Discovered

When is "this trait can be implemented" part of the trait's public API?

"We never update unless forced to" — cargo-semver-checks 2024 Year in Review

Breakage! in the Cargo.toml — How Rust Package Features Work (And Break)

Is this trait sealed, or not sealed — that is the question

How to Query (Almost) Everything

The Wi-Fi only works when it's raining

SemVer in Rust: Tooling, Breakage, and Edge Cases — FOSDEM 2024

Four challenges cargo-semver-checks has yet to tackle

Highlights of 2023 for cargo-semver-checks

Checking semver in the presence of doc(hidden) items

Semver violations are common, better tooling is the answer

Breaking semver in Rust by adding a private type, or by adding an import

A definitive guide to sealed traits in Rust

Mediocrity can be a sign of excellence, and other stories

Re-exporting an enum with a type alias is breaking, but not major

Speeding up Rust semver-checking by over 2000x

Moving and re-exporting a Rust type can be a major breaking change

Some Rust breaking changes don't require a major version

Turning a Rust struct into an enum is not always a major breaking change

Public fields</h2> Rust structs may have publicly-visibile fields:</p>

Conclusion</h2> Semver violations are much like memory safety violations:</p> They can happen to anyone, even if you're extremely careful.</li> There's an overwhelming amount of real-world evidence of the above.</li>

cargo-semver-checks today and in 2023

Falsehoods programmers believe about undefined behavior

Errata and edit history</h2> 2022-11-29: Items 13-16 corrected and updated</h3> The original version of this post contained the following items at positions 13-16 in the list:</p>

2022-11-29: Items 13-16 corrected and updated</h3> The original version of this post contained the following items at positions 13-16 in the list:</p>

2022-11-29: Added community-contributed items</h3> The "False expectations around UB, in general" section now contains a selection of community-suggested items. Previously it only contained a single item (the last one in the current list) at position number 41.</p>

My HYTRADBOI'22 Jam

Debugging Safari: If at first you succeed, don't try again

Toward fearless cargo update

Compiler Adventures, part 3: Value Numbering

Unsoundness and accidental features in the `#[target_feature]</code></nobr> attribute`