Predrag Gruevski
LightNews LightNews
predr.ag
Predrag Gruevski
@predr.ag
1.7K followers 250 following 490 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
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
predr.ag
Huge thanks to @rerun.io and @ernerfeldt.bsky.social for sponsoring my work on cargo-semver-checks 🙏

To celebrate, I'll write 5 new lints today ✨
Rerun.io logo: a 3D-stylized letter "R" in white on a black background.
December 10, 2024 at 3:27 PM
predr.ag
In #rustlang, Cargo.toml changes that seem innocuous can break your users!

As of today, cargo-semver-checks has you covered 😇 Here's how 👇
predr.ag/blog/breakag...
Breakage in the Cargo.toml — how Rust package features work (and break) cargo-semver-checks v0.37 can now scan `Cargo.toml` files for breakage! In this post: a primer on Rust package features, and how innocuous-looking changes can break your users.
December 5, 2024 at 2:28 PM
predr.ag
Gotta love it when you're writing two different programs at the same time, and they have to rhyme.

do_stuff() is 10 lines long in the actual code, and this structure repeats half a dozen times in the same function.
Rust code that relies on conditional compilation to enable or disable "rayon" parallelization. The structure is: - conditionally include a rayon line - otherwise, include a non-rayon line - then do some stuff they have in common - then again conditionally include a rayon line - or include the non-rayon line otherwise - then more stuff in common.
November 27, 2024 at 4:55 PM
predr.ag
Only if there are no accidental breaking changes in any of the upgraded versions!

As the talk shows, accidental breakage is quite common and happens ~all the time even to expert maintainers.
Slide headline: Across the top 1000 crates, 1 to 2 broken new releases happen per week. Below: This is data from running cargo-semver-checks, and is joint work with Tomasz Nowak, Mieszko Grodzicki, Bartosz Smolarczyk, Michał Staniewski More info: https://predr.ag/blog/semver-violations-are-common-better-tooling-is-the-answer/
November 20, 2024 at 6:02 PM
predr.ag
That's certainly a new way to spell my name. Innovation strikes again!
A magazine addressed to "Mr. and Mrs. Drag Gruevski". My name is Predrag, not Drag!
November 19, 2024 at 9:16 PM
predr.ag
Congrats to all #rustlang Google Summer of Code students on completing their projects!

Max knocked his cargo-semver-checks project out of the park 🚀
blog.rust-lang.org/2024/11/07/g...
Predrag, who is the author of cargo-semver-checks and who mentored Max on this project, was very happy with his contributions that even went beyond his original project scope: He designed and built one of our most-requested features, and produced design prototypes of several more features our users would love. He also observed that writing quality CLI and functional tests was hard, so he overhauled our test system to make better tests easier to make. Future work on cargo-semver-checks will be much easier thanks to the work Max put in this summer. Great work, Max!
November 7, 2024 at 4:42 PM