You'd want to augment the code analysis with the dependency graph of object/class files (or use it instead of what the OP is using). I'm not sure if it's bullet-proof, but except for runtime dynamic linking, you should get a superset of all affected changes if you just use... whatever your IDE uses to determine which files need to be rebuild when you make a change. Following that graph should give you a superset of all unit tests that need to be run.

Like, e.g. if I change a macro in a header file and press "rebuild" on the project, MSVC (or MSBuild driven by CMake) will figure out that the header was changed, chase down which translation units include it directly or transitively, and rebuild those, then link the output and... chase down everyone else who links to the output and relink them, etc.

I bet you could produce a counterexample that breaks this mechanism (C++ being what it is), but I don't expect to see it in an actual codebase.