Building a Rust-style static analyzer for C++ with AI

Very cool project! Always happy to see more work around static analysis.

However, looking at the recent commits it doesn't quite look like the most solid foundation: https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efec...

    fn is_interior_mutability_type(type_name: &str) -> bool {
        type_name.starts_with("rusty::Cell<") ||
        type_name.starts_with("Cell<") ||
        type_name.starts_with("rusty::RefCell<") ||
        type_name.starts_with("RefCell<") ||
        // Also check for std::atomic which has interior mutability
        type_name.starts_with("std::atomic<") ||
        type_name.starts_with("atomic<")
    }

There's also quite a lot of dead code. All of these warnings are around unused variable, functions, structs, fields:

    warning: `rusty-cpp` (bin "rusty-cpp-checker") generated 90 warnings (44 duplicates)

> When I upgraded to Sonnet 4.5, it became less often that it gave phantom answers. But it still sometimes wasn’t able to handle some complex problems. We’d go back and forth and I’d try to give it hints. But with Opus 4.5, that happens much less often now.

The real annoying thing about Opus 4.5 is that it's impossible to tell most people "Opus 4.5 is an order of magnitude better than coding LLMs released just months before it" without sounding like a AI hype booster clickbaiting, but it's the counterintuitive truth. To my continual personal frustration.

> One thing I used to hope for is better interop between C++ and Rust … But after closely following discussions in the Rust committee, I do not think this is likely to happen soon.

Interesting. I thought C++ interop was one of the top priorities right now.

It’s one of the top items mentioned in recent language progress reports, the Rust foundation received a million dollar grant to work on it, and there was a talk at the most recent RustConf about how Google is doing Rust/C++ interop.

Curious to know what discussions led to that conclusion.

> Then I thought: how hard is it to write this C++ static analyzer? Conceptually, I think it’s not hard. It requires going through the AST. And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis.

How do you handle function lifetimes then? Those are generally non-local to infer, and Rust requires annotating functions with informations for that. I tried taking a look at the mako db's refactor but I didn't see any lifetime annotation being added there.

1. There are tons of static analyzers for C++. Does none of them support type system augmentation? 2. Is the proposed solution really more practicable than "typescript for c++" [0]?

[0] https://github.com/hsutter/cppfront

Wrapping every pointer in a smart pointer is very bad style; that suggests you simply have the bad level of abstraction in your code.

That problem seems even more prevalent in Rust, where I see Arc used everywhere, presumably as a cop-out not to have to figure out how to satisfy the borrow checker in smarter ways.

Honestly, I found this piece depressing. Life is too short and precious to waste on crappy software.

So often the question ai related pieces ask is "can ai do X?" when by far the more important question is "should ai do X?" As written, the piece reads as though the author has learned helplessness around c++ and their answer is to adopt a technology that leaves them even more helpless, which they indeed lament. I'd challenge the author to actually reflect on why the are so attached to this legacy software and why they cannot abandon it if it is causing this level of angst.

> C++ has a perfect match for Rust’s mutability: const and non-const.

Rust has inherited mutability, while I believe const in C++ is shallow. I don't think it's a perfect match.

curious what the token costs look like on a real codebase. opus ain't cheap and C++ headers get big fast

That must be some bait post, as we all know, C++ and Rust developers hate AI.

unique_ptr/shared_ptr (and box/arc) still need to handle null states due to how moving works in C++.

How readable is the code produced by opus, when you try to interact with it manually?

Can we see an example of this on a moderately sized codebase?

Is it just me or this seems like a quick-win for many C++ codebases?

Simple and elegant solution.

The pragmatic design choice of using comment-based annotations (// @safe) is brilliant. It successfully bypasses the 'intrusive syntax' trap that killed many previous safety proposals. This tool doesn't just promise safety; it provides a realistic path for legacy C++ codebases to adopt Rust-style borrow checking without a full rewrite. It’s a great example of using modern LLMs to solve deep engineering bottlenecks that previously required a team of compiler experts.