Clang Static Analyzer Inter-File Analysis

Hello all,

Just a quick question. Is it true that the latest version of clang runs inter-file analysis (using the cross translation unit) by default? We were working with an older version of clang, and after updating it seems that the output plist files contain multiple file paths. Apologies if this question is too simple or not appropriate for this mailing list. Is there another place where I might be able to find this sort of information in the future? Thank you.

Best,
Gianluca Gross

Hi!

CTU is off by default – isn’t it possible that those filenames are headers and other included files?

Is there another place where I might be able to find this sort of information in the future? Thank you.
Enable the checker debug.ConfigDumper, that might tell a couple things, coupled with the frontend flag -analyzer-config-help. Mind you, we are currently working on a lot nicer user interface :wink:

Cheers,
Kristóf Umann

Gianluca Gross via cfe-dev <cfe-dev@lists.llvm.org> ezt írta (időpont: 2019. márc. 13., Sze, 20:35):

Yup, Kristof is right: there’s a difference between “files” and “translation units”. Your #includes may be different files on disk, but every .c/.cpp file is compiled together with all of its includes in a single Clang process, therefore there never were any technical barriers to produce reports that jump from .c to .h and back in this scenario. The minor difficulties to present the bug report to the user (either as .plist or as .html) were indeed resolved recently (like, a few years ago).

The actual cross-translation-unit analysis challenge is to exchange information between multiple instances of Clang that compile different translation units, either by serializing intermediate analysis results on disk, or by passing them around through an IPC interface. We have a solution that attempts to do the former, but it’s not enabled by default yet.

I don’t think our .plist format is documented anywhere. It’s probably a very good idea to get it documented so that people who rely on it didn’t have to continuously monitor the upstream commits. I don’t think we had any breaking changes since multi-file plists were introduced, but we did add a few extra fields since then (issue hashes, opt-in performance statistics, executed lines, macro expansions(?)).