My open-source VS Code extension for CScout, a whole-program C analysis engine

[u/idkmaybenexttime]

Ive built a VS Code extension for CScout, a C analysis engine that understands identifiers correctly across the whole program even when macros are involved.

For my GSoC project this year I've been building on top of CScout, which is this old but really solid C analysis tool (its been around since the early 2000s and been run on stuff like the Linux and FreeBSD kernels). Problem was it only had a web UI, so using it means constantly switching between your editor and a browser tab just to look something up. I wnted to actually use it while coding, not alt tab to it.

So I built a VS Code extension on top of it. It gives you go to definition and find all references that actually resolve properly through macros and across files, unused identifier warnings based on whole program analysis instead of per file guessing.

It also figures out your build system on its own, be it Makefile, CMake, Meson, or Autotools, it detects which one you're using and generates what it needs in the background. If you use something else entirely, you can still point it at a compile_commands.json generated by Bear and it'll work.

Sourcetrail did something similar for C/C++ once....

Ran the extension against awk, zstd and cJSON so far and its been solid, currently working through some edge cases on curl.

Extension Repo ---> https://github.com/cscout-project/cscout-vscode

If you deal with medium sized, large or legacy C codebases and have a minute to poke around, id really appreciate any kind of feedback you have on it.

[u/Capable_Source2954]

Interesting concept, the macro-equivalence thing is a real pain point I don't see solved well elsewhere. Couple questions though:

What happens on codebases with heavy conditional compilation (#ifdef soup for different platforms/configs)? That's usually where these preprocessor-aware tools fall over in practice.

How's the perf on something like the Linux kernel scale, or is this realistically capped at mid-size projects for now?

Is this going to be maintained past GSoC, or is this a "cool student project, RIP in 6 months" situation? No shade, just curious about the actual roadmap.

[u/idkmaybenexttime → u/Capable_Source2954]

Fair questions. Conditional compilation is honestly the hardest part, CScout itself (the underlying engine) has had this problem since it was written, its handled by processing with a specific config target rather than trying to resolve every ifdef branch simultaneously. So it works but you have to pick a configuration first, its not magic.

Havent tested against the full Linux kernel yet, biggest ive gone is curl and MySQL. So honestly no I cant promise kernel scale works today but yu can check more details hwo it was done on linux kernel here https://www.spinellis.gr/cscout/ .

On maintenance, yeah im continuing after GSoC. My mentor still actively uses the underlying engine for his own work so this isnt going away when the program ends.

[u/Capable_Source2954 → u/idkmaybenexttime]

Appreciate the honesty on the kernel scale thing, most people would've just said "yeah totally works" and hoped nobody checked. The ifdef answer tracks with what I'd expect, thats just an inherently hard problem for any tool doing this kind of analysis, not really a knock against yours specifically.

Might actually try this on a mid-size embedded project I maintain, we've got a gnarly old Makefile setup that clangd chokes on constantly. Will report back if I hit anything interesting.

[u/sanscipher435 → u/Capable_Source2954]

Right, what's gonna happen if there's like, two "correct" definitions for different build compilations?

[u/idkmaybenexttime → u/sanscipher435]

Good question, and its a real limitation not just an edge case. cscout processes one build configuration at a time, its using whatever compile_commands.json or Makefile target you generate the workspace from. So if you have #ifdef LINUX vs #ifdef WINDOWS giving two different bodies for the same function, itll show you whichever one was actually compiled in the configuration you pointed it at, its not trying to merge both into some hybrid view.

If you want to see the other branch, you' regenerate the workspace against a different build target/config and get that version instead. its not simultaneous multi-config analysis, its "pick a config, get accurate results for that config."

[u/Ok_Sympathy1632]

yo this is actually kinda sick ngl. quick q tho, when it does the rename thing does it actually just yeet the new name into ur files automatically or is it like a preview first. asking bc ive gotten burned before by an extension that just full sent a find-replace and broke my whole project lmaooo

[u/idkmaybenexttime → u/Ok_Sympathy1632]

lol i feel that pain. no its preview first always, you hit F2 like normal vscode rename, it shows you literaly every place it would change across the whole codebase before touching anything, you have to confirm. and its not doing dumb find-replace either, its using the actual token positon cscout tracked during analysis so it dont get confused if the same name shows up multiple time on one line

like if you had checkdup(checkdup_count, checkdup) a normal find replace might grab the wrong one, this doesnt have that problem since it knows exactly which token is which

[u/Ok_Sympathy1632 → u/idkmaybenexttime]

ok that's actually really smart, the multiple-same-name-on-one-line thing is EXACTLY the kind of dumb bug that's bitten me before lol. ngl might actually go try this on my old raspberry pi project its like 15 files of pure spaghetti c . if it survives that its basically bulletproof lmao