Predrag Gruevski
LightNews LightNews
predr.ag
Predrag Gruevski
@predr.ag
1.8K followers 260 following 520 posts
Author of cargo-semver-checks & Trustfall // https://github.com/sponsors/obi1kenobi // https://predr.ag/blog // ex Principal Eng @Kensho // MIT alum // https://hachyderm.io/@predrag // not from around here 🇲🇰 // he-him
Posts Replies Media Videos
predr.ag
Shout-outs to the kind folks who make this work possible by funding cargo-semver-checks 🙏
All this was made possible through the funding provided by the Rust Foundation Fellowship Program, Amazon, Rerun, Accelerant, Astral, Zoo, the generous individuals who support my work via GitHub Sponsors, as well as the Google Summer of Code program where I was a mentor. To everyone who makes what I do possible, thank you 🙏
January 11, 2026 at 8:21 PM
predr.ag
I also propose a change in how we measure success going forward.

I hate gameable metrics. Let's build what's most valuable for the community, not what's easiest to quantify and brag about.
"Total number of lints" is a fun number to look at, but increasingly just a vanity metric. I believe the community will be best served by us tackling some of our long-standing (and most difficult) challenges, instead of trying to chase exponential lint growth by itself. The challenges include: - making ecosystem-level SemVer studies 50x cheaper by the end of 2027, and completing such a run - completing type-checking lints and cross-crate linting capabilities - officially starting the process of merging `cargo-semver-checks` into cargo Full info here: https://predr.ag/blog/cargo-semver-checks-2025-year-in-review/#the-path-forward-for-2026-and-beyond
January 11, 2026 at 8:16 PM
predr.ag
Here's everything you'll find in the post above!

If you're a regular reader, some of these sections may be familiar. There are links so you can skip ahead!
Table of contents for the blog post - Goal: Fearless `cargo update` - What we shipped in 2025 - 122 new lints is *a lot* - Discovering a soundness bug in Rust - Doubling the lints without doubling the runtime - Why compiling the same Rust program might succeed or fail depending on the current directory - Resolving the edge cases of `#[do - Conference talks and podcast appearances - What it'll take to eradicate unintended breakage from Rust — RustWeek - The Past, Present, and Future of SemVer in Rust — RustForge - Cursed Rust — A Surprise Talk at RustForge - A Universal Query Engine in Rust — Developer Voices - `cargo-semver-checks` — Open Source Security - The path forward for 2026 and beyond - We've already started down this path - What success will require, and how you can help
January 11, 2026 at 8:16 PM
predr.ag
SemVer is tricky in all languages. But in #rustlang it's easier than ever before!

By the end of 2024, cargo-semver-checks' capabilities were growing exponentially: 30 -> 57 -> 120 lints. We now end 2025 with 242 lints — 122 new lints were merged this calendar year 🎉

The exponential continues!
Screenshot from the cargo-semver-checks 2024 year in review post featuring a diagram of the number of lints at the end of each calendar year. 2022 ended with 30 lints, 2023 ended with 57, 2024 ended with 120 lints. Link to the post: https://predr.ag/blog/cargo-semver-checks-2024-year-in-review/
December 30, 2025 at 5:14 PM
predr.ag
On behalf of the cargo-semver-checks project, it's my pleasure to recognize @jyn.dev's irreplaceable and tireless work in the #rustlang community 🦀

I'll share just one anecdote; you can click on the GitHub Sponsors link at the end of the thread to see more 🧵
GitHub Sponsors email stating: "You sponsored @jyn514! Sponsorship amount: $1000 one time"
November 30, 2025 at 3:51 PM
predr.ag
Here's the code in question. Strange, right?
fn breaks() -> impl Debug + ?Sized { 123 } // error[E0277]: the size for values of type `impl Debug + ?Sized` cannot be known at compilation time // --> src/lib.rs:3:16 // | // 3 | fn breaks() -> impl Debug + ?Sized { // | ^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time // | // = help: the trait `Sized` is not implemented for `impl Debug + ?Sized` // = note: the return type of a function must have a statically known size async fn works() -> impl Debug + ?Sized { 123 } // no error!
November 29, 2025 at 1:00 AM
predr.ag
I have a paper for you to read:
people.csail.mit.edu/nickolai/pap...
Four plots showing a sudden performance collapse as more cores are added. Different workloads collapse at different points: some around 2 cores, others at 10 or 36. But in all cases, running the workload at the full 48 cores is much slower than taking some cores away.
September 24, 2025 at 3:16 PM
predr.ag
Here's the animation (but do check out the release notes too!)
September 21, 2025 at 4:10 PM
predr.ag
cargo-semver-checks v0.44.0 is live — we've hit 200 lints ✨

Don't miss this *adorable* animation in the release notes, courtesy of the amazingly talented @dekirisu.com

Check it out here:
github.com/obi1kenobi/c...

#rust #rustlang #semver
Screenshot of the cargo-semver-check v0.44.0 release page. It touts 22 new lints, for a total of 200 lints! In celebration, it includes an adorable animation of Ferris standing alongside a conveyor belt which transports crates off an assembly line. Each crate passes through a cargo-semver-checks scanning station, which applies a "PASS" or "FAIL" sticker to it. It seems like a crate has just failed SemVer checking! Ferris picks it off the conveyor belt, and throws it into a hopper labeled "Revise". This is how all crates being shipped uphold SemVer! All is well.
September 21, 2025 at 4:07 PM
predr.ag
Sometimes when I work on #rustlang cargo-semver-checks, I feel I need "Look What You Made Me Do" playing in the background.

Here's a legal type and function signature I wrote today to test some upcoming lints 👇
impl<S: Clone> Example<'static, S> { pub fn hello<'a, T, const N: usize>() -> impl for<'n> Fn(&'n i64) -> &'n i64 + use<'a, T, S, N> { |x| x } }
September 5, 2025 at 3:09 AM
predr.ag
70% of security vulnerabilities are memory safety related, across a variety of studies in mature, well-maintained codebases.

Looking specifically at critical security vulnerabilities, the number goes up to 94%.

From @david-sankel.bsky.social's talk at @rustforgeconf.com
70% of memory safety vulnerabilities have a root cause related to memory safety, across studies done by Microsoft, Google Android, Google Chromium, Mozilla, and a general survey of zero-day vulnerabilities. Mozilla's survey of critical security vulnerabilities shows 94% of them were memory safety related.
August 28, 2025 at 9:47 PM
predr.ag
Who else is going to be at Rust Forge btw?

Look at this stacked list of speakers and topics. I'm really looking forward to meeting all these folks in person!
rustforgeconf.com
Speakers James Blackwood-Sewell PGRX - How Rust reshaped the Postgres ecosystem Adam Chalmers Why Rust for startups Meghan Clark Mixed Reality Network Introspection Stephan Dilly Build a Game with Bevy EncodePanda Rust for the Rest of Us: Your Survival Guide Predrag Gruevski The Past, Present, and Future of SemVer in Rust Adam Harvey Crate security in 2025 Azriel Hoh The Development Experience Is Different With Rust Paul Hummer Other People's Code : Domain Specific wasm Elias Junior Tackling complexity a test at a time Steve Klabnik Rust is (much) more than safety Andrey Konstantinov Reflect Your Rust API into the World Jonas Kruckenberg Panic! At The Disk Oh! David Lattimore Wild build times Laura Bell Main AppSec for developers with deadlines Orhun Parmaksız Becoming a terminal chef with Ratatui, Rust rocks (literally) Jack Purvis From Ruby to Rust: building a live visual performance tool with Rust Anders Rasmussen Make your own own smart watch David Sankel Engineering the Future at Adobe: Why Rust is Key to Our Next Chapter Tom Simpson Designing superconducting magnets for fusion power Jeremy Wells Take your web app offline with Rust and Tauri Mikey Williams Rust in color: embedded LED art Ben Wishovich 🦀 cargo new blog: Shipping a Site with Leptos Ross Younger Land of the long fat pipe: the quest for faster file transfers Mix Irving Peer-2-Peer Data Visualisation
August 10, 2025 at 3:29 PM
predr.ag
✨ cargo-semver-checks v0.43.0 is out ✨

This release cycle focused on making it a joy to use and build. We improved performance on large crates, cut down our CI time, tackled a large rustdoc JSON format migration, and paid down technical debt.

Enjoy!
v0.43.0 - In this release - Spotlight: I'm giving a talk at Rust Forge! - Performance improvements - 1 new lint, for a total of 178 This release requires Rust 1.87+ both to install (MSRV) and at runtime. Future releases will require Rust 1.88+. Spotlight: I'm giving a talk at Rust Forge! Rust Forge is a creative new conference organized by Rust in Action author Tim McNamara. It's scheduled for 27-30 August 2025 in Wellington, New Zealand. My talk is titled "The Past, Present, and Future of SemVer in Rust" and I'm extremely excited about it! Here's a short description: At least 1-2 times per week, accidental breaking changes sneak into the new release of some popular Rust package, despite the maintainers' best efforts. Why is this still a problem 10 years after Rust 1.0? What will it take to finally stop such breakage, so we can have fearless cargo update? It's not too late to grab a ticket! I hope to see you there! Performance improvements Supporting an exponentially-growing number of lints requires periodic maintenance in the form of mandatory performance engineering, Without it, things would quickly get out of hand, and large crates and large workspaces would be affected first. To prevent that, this release cycle focused on both internal and external improvements. Externally-visible improvements include lint execution time improvements, courtesy of a new query profiling tool prototype developed by @CLIDragon. This allowed us to add targeted new indexes that speed up the execution of some lints by as much as 10x! After these optimizations, running the full suite of lints on Rust's largest crates needs only ~2s, down from around ~8s previously. Internal improvements include a variety of optimizations aimed at reducing the time taken by our CI suite, from an original of ~7min for cargo test down to around ~1min. If you're wondering why cargo test used to take 7min in the first place: our test suite runs ~250000 lint queries to ensure correctness and keep false-positives out! Even extremely cheap operations done 250k times add up very quickly! After the optimizations, we still run those 250k queries — we didn't sacrifice correctness at all, but merely cut out avoidable overhead. New lints We added only one new lint in this release, tracking an additive-only API change: enum_must_use_removed. This lint group remains opt-in-only.
August 10, 2025 at 3:16 PM
predr.ag
Experienced #rustlang engineers never break SemVer. Nobody needs cargo-semver-checks — just be more careful

I even *had left myself a note* that the next release needs to be a major bump. Too bad I only saw the note after cargo-semver-checks stopped the publish job!
GitHub publishing pipeline in a failed state. The commit title is "Release v0.23.2 with support for rustdoc JSON v46." The pipeline has stopped immediately prior to the "Publish to crates.io" stage, having failed the job titled "Check for semver compliance." Logs of the failed semver-checking job. Four breaking changes are listed, showing the effects of removing support for rustdoc JSON format v36: three enum variants have been deleted, and the `v36` feature has been removed from the crate's Cargo.toml features list.
June 7, 2025 at 2:59 PM
predr.ag
Update on the Rust Vision Doc, by @nikomatsakis.com, @timclicks.dev, and Jack Huey

Day 2 of #RustWeek closing strong!
Niko, Jack, and Tim giving their talk. The slide reads: Conclusions: - Rust Vision Doc aims to give us insight into the state of Rust - We are happy to have help: come be an interviewer, or talk to Niko or Jack
May 14, 2025 at 3:40 PM
predr.ag
Excited for day 1 of #RustWeek! So many good talks coming up 🤩

If you like cargo-semver-checks (and especially if you fund it on GitHub Sponsors!), find me in the hallway — I have something for you 👀
May 13, 2025 at 5:41 AM
predr.ag
New cargo-semver-checks just dropped, enjoy!

And if you're enjoying, please support the project on GitHub Sponsors 😍
github.com/obi1kenobi/c...
v0.41.0 release of cargo-semver-checks # In this release - 16 new lints, for a total of 164 - Spotlight: Google Summer of Code - Bugfix: false-positive sealed trait lints This release requires Rust 1.84+ both to install (MSRV) and at runtime. Future releases will require Rust 1.85+. # Spotlight: Google Summer of Code `cargo-semver-checks` is participating in Google Summer of Code, a program aimed at bringing new contributors into open source software development. This is our second year participating in the program under the Rust umbrella. Last summer, @suaviloquence joined us to design and build the ability for users to configure which lints run on their projects, on which SemVer changes, and with what effect such as raising an error vs warning. This is a foundational capability for our project! For example, it allows users to temporarily disable a lint that exhibits buggy behavior in their project, such as a false-positive. The application process for this year's Google Summer of Code concluded two weeks ago, and we're currently in the evaluation process. The selected projects will be announced in early May. We thank everyone who applied for their hard work on their proposals, and wish everyone the best of luck! # New lints We added new 16 lints across several categories. Some of the new lints are error-by-default, while others are warnings meant to flag changes deserving closer review, or even opt-in only and disabled by default while we do more work to improve their user experience. API breakage: - `enum_struct_variant_changed_kind` - `enum_non_exhaustive_tuple_variant_changed_kind` Item deprecations, which cause lints in downstream use: - `enum_struct_variant_field_marked_deprecated` - `enum_tuple_variant_field_marked_deprecated` - `enum_variant_marked_deprecated` Compatibility risks, such as changes that may require a SemVer major bump to revert, or may otherwise represent unintended API changes without being SemVer-major themselves: - `enum_no_longer_non_exhaustive` - `enum_variant_no_longer_non_exhaustive` - `enum_repr_int_added` - `function_no_longer_unsafe` - `function_now_const` Additive-only API changes (opt-in only; more work required): - `enum_non_exhaustive_struct_variant_field_added` - `enum_non_exhaustive_tuple_variant_field_added` - `non_exhaustive_enum_added` - `pub_const_added` - `pub_static_added` - `union_added` Thanks to @shreyans413, @GlitchlessCode, @Frank-III, @qstommyshu, and @sandptel for contributing to this release! Bugfix: false-positive sealed trait lints In rare circumstances, `cargo-semver-checks` had the tendency to mis-classify traits as sealed even though that wasn't actually the case. This manifested as false-positive lints stating that traits have newly become sealed (a breaking change) or that a previously-sealed trait is no longer sealed (a future-compatibility warning). After quite a bit of work, we were able to diagnose the issue as a logic error in the cycle-tracking code of our sealed trait analysis. #1200 has more information. This portion of `cargo-semver-checks` has 2000+ lines of test code _specifically_ dedicated to covering its edge cases. This bug made it through all of that without getting caught — that's how complex this space is. We're grateful to the folks who contributed high-quality bug reproductions to help us diagnose the problem in #1200. We're also grateful to the generosity of our GitHub Sponsors who make it possible for `cargo-semver-checks` to continue powering through this very complex space.
April 22, 2025 at 6:12 PM
predr.ag
I think I found something weird & scary with `#[target_feature]` in #rustlang. Is this expected?

This feels like it should *at minimum* trigger a lint. How am I supposed to know whether trait impls added extra safety preconditions — especially when using `dyn/impl Trait` and/or an unsealed trait?
pub trait Example { unsafe fn demo(&self) {} } pub struct S; impl Example for S { // This isn't applied to the trait's fn! #[target_feature(enable = "avx2,aes")] unsafe fn demo(&self) {} } pub fn accept_dyn(value: &dyn Example) { // SAFETY: umm ??? // Who knows what #[target_feature] // attributes the trait impl has imposed?! unsafe { value.demo() } }
April 4, 2025 at 1:16 AM
predr.ag
✨ cargo-semver-checks v0.40 is out ✨

github.com/obi1kenobi/c...
## In this release - 21 new lints, for a total of 148! - Spotlight: `#[doc(hidden)]` and sealed lints This release requires Rust 1.83+ both to install (MSRV) and at runtime. Future releases will require Rust 1.84+. ## Spotlight: `#[doc(hidden)]` and sealed lints When is "this trait can be implemented" part of the trait's public API? At a high level, the answer is: when writing an `impl` of that trait for our own type doesn't require using any `#[doc(hidden)]` items. But you've been following `cargo-semver-checks` long enough to know the *full answer* is much more complex. And getting the right answer here affects the correctness of a ton of lints! Good news! This `cargo-semver-checks` release ships with a much more sophisticated system for analyzing whether traits can be implemented or are instead "sealed." The new system is more thorough, more nuanced, and faster to boot! Read more about it here: https://predr.ag/blog/when-is-trait-can-be-implemented-public-api/
March 8, 2025 at 4:58 PM
predr.ag
Hey, look at that! Number go up, and it's a round number again!
Screenshot of a Bluesky's "followers" list showing I have exactly 1500 followers now.
February 26, 2025 at 5:07 AM
predr.ag
"When can a trait be implemented without touching `#[doc(hidden)]` items?"

Simple question, extremely complex answer! Most intense 2000 lines I've written in a long time!

Still needs cleanup & refactoring, but it's passing tests!
github.com/obi1kenobi/t...
An example of a "public API sealed" trait is: pub trait Example { #[doc(hidden)] type X; } Any impl of Example outside of its crate must name the Example::X item, and in doing so refer to non-public-API. Therefore, such an impl is outside the public API of Example, and may suffer breakage outside of major version bumps of Example's crate. Crates can be public-API-sealed in many ways, including: - #[doc(hidden)] (without #[deprecated]) on associated types without a default - #[doc(hidden)] (without #[deprecated]) on associated constants without a default value - #[doc(hidden)] (without #[deprecated]) on associated functions / methods without a default implementation - associated functions / methods taking an "importable but not public API" parameter - associated functions / methods returning an "importable but not public API" type "Importable but not public API" means: - The item has at least one path by which it can be imported from an external crate. That path passes through at least one item that is simultaneously #[doc(hidden)] and not #[deprecated], such as the imported item itself, a module, or a re-export). - The item has no paths by which it can be imported such that no item along that path is #[doc(hidden)] and not #[deprecated].
January 31, 2025 at 12:36 AM
predr.ag
Happy "new cargo-semver-checks release" day!

✨ 20 new lints ✨
## In this release - 20 new lints, for a total of 127! - Spotlight: Merging into `cargo` This release requires Rust 1.81+ both to install (MSRV) and at runtime. Future releases will require Rust 1.83+. ## Spotlight: Merging into `cargo` While `cargo-semver-checks` is currently a standalone tool, Rust's `cargo` team plans to eventually make it a built-in part of `cargo` itself. Here's how that would work. When users run `cargo publish` today, `cargo` first runs a series of checks to make sure everything is in order. For example, it ensures that the code repository doesn't include any uncommitted changes, so as not to accidentally publish uncommitted code to crates.io: ``` $ cargo publish Updating crates.io index error: 1 files in the working directory contain changes that were not yet committed into git: src/lib.rs to proceed despite this and include the uncommitted changes, pass the `--allow-dirty` flag ``` `cargo-semver-checks` is planned to become another such pre-publish check, equivalent to running `cargo semver-checks && cargo publish` today. Of course, there are situations where maintainers may prefer to *intentionally* publish breaking changes in a non-major version, such as for a sufficiently critical security fix. The automatic semver-check will be overridable by passing a flag analogous to the `--allow-dirty` flag for uncommitted changes. While we're excited to merge `cargo-semver-checks` into `cargo`, we are proceeding with caution before enabling it by default. We want to ensure "merge day" is a day of celebration for the entire Rust community, instead of causing frustration and further breakage! Good news: you can help us do that! Consider: - Reporting any issues you find, including any suspected false-positives with our lints. - Contributing lints to make `cargo-semver-checks` smarter - Funding the project via GitHub Sponsors
January 28, 2025 at 4:15 PM
predr.ag
I like to play "Where's Waldo" as much as the next person, but not during code review.

Let's have more tools that point out things humans might miss!
A "Where's Waldo" book cover featuring a large crowd of cartoonish people, with Waldo among them in his red and white striped shirt. He's really hard to notice in the crowd, so he's circled to make him easier to find, solving the puzzle.
January 9, 2025 at 3:20 PM
predr.ag
cargo-semver-checks found the problem in this change, saving the project from breaking SemVer. Manifest linting for the win! 🔥

Do you see the breaking change?

#rust #rustlang #semver
A change being applied to a Rust Cargo.toml file. An optional dependency called `mock_instant` ("mock underscore instant") is being removed, and a feature called `mock-instant` ("mock dash instant") is changed to no longer enable the `mock_instant` ("mock underscore instant") feature. The problem is a lot more obvious when I make the spelling explicit, isn't it? :)
January 9, 2025 at 3:09 PM
predr.ag
cargo-semver-checks v0.38 is live, enjoy 🦀🔥

@orhun.dev and I live-streamed writing one of these new lints last weekend, if you want to see how the proverbial #rustlang sausage gets made!
Release notes screenshot: In this release: - 12 new lints, for a total of 106! - Bugfix for packages using the "SemVer trick" - Spotlight: Performance via parallelism Spotlight: Performance via parallelism cargo-semver-checks is on a trajectory of doubling its number of lints every year. But more lints mean more code scanning work to be done! And nobody likes slow tools, so we had to parallelize! We began taking a serious look at performance in early 2023. Compared to that point ~almost two years ago: - Lint checking time has reduced by 20%, in wall-clock terms & measured on the exact same hardware. - Yet, we run over 2.5x as many lints in that time! We've aimed to parallelize as much of the execution of the tool as possible, with help from the rayon library. Today, both the lint execution and the rustdoc indexing steps use rayon to distribute the work across all available cores on your system. [It continues...]
December 11, 2024 at 6:06 PM