Since recently, WebKit uses a peculiar build system that compiles multiple translation units at once by automatically joining them into a bigger file via #include. Because none of the functions end up in the main file, we disable all our path-sensitive checks on such unified sources. Try to work around that.
Is this if really necessary? This logic has too much overfitting, and it seems that if someone decides to include .cc files, we should analyze them in any case, right? We also would prefer to not stop working if webkit decides on using a different naming for those.
You would shave off a bit of redundancy and verbosity by saving AnalysisManager in a local variable.
Assert error message is not quite technically correct now
Wow, expected-* directives work across multiple files?? This is really cool!
Address most comments.
This is indeed an act of overfitting. But also there are very few reasons to include a non-header file, and all of them are pretty exotic. I'm not sure we want to analyze these files in all cases. So i want to play safe until we gather more data.
-verify works over preprocessed files, so yeah, these directives respect #ifs (which we regularly abuse) and #includes (which we rarely abuse). This test also acts as a normal test, but the UnifiedSource-1.cpp test is the one that'll fail if we break the newly added functionality.
C++ source code is also found in files which end in .C, this code will match against strange file endings like .cXx and .mM
I think the above logic should be changed to match https://github.com/llvm-mirror/clang/blob/master/lib/Frontend/FrontendOptions.cpp#L27
The question is, are all such projects in fact interested in having the analyzer analyze the respective code?
For instance, if the included code is autogenerated by an external tool, users are probably not interested in finding bugs in such code because they will be unable to fix them.
Are you interested in providing a list of examples of projects that do this kind of thing, explain why are they doing it, and whether they will be interested in having warnings in included files?
Note that we're not talking about warnings that are *emitted* in the included file. We're talking about warnings that *originate* within the included file (and as such most likely stay within the included file and its includes). This makes a difference because we are doing inter-procedural analysis. I.e., if we find that passing a null pointer in the main file into a header function causes a null dereference in the header function, the report that originates within the main file will be emitted in the header with auxiliary path notes in the main file.
So if a small chunk of code is included but the main file still contains reasonable stuff, we'll be able to find most bugs in the included code as it is being used from the rest of the file. The problem only arises when all code is included.
Hi Artem. Cool patch!
Maybe we should create an analyzer option for this? So, all users who want webkit-like behaviour will just enable (or disable, don't know what's better) the option and get the feature. I know that introducing a new option is undesirable but it seems to be a good compromise here.
Game teams are known to use "unity" builds, developing their code in separate files then having a master .cpp that will #include everything in a given library/component. This separates source into reasonable sized and logically coherent units, but the unity build improves build time for these large projects. If a team is using static analysis, they will want it on the entire compilation.
Aha, ok, yeah, that sounds like a lot, thank you. I think i'll follow up with a separate commit that will enable first-level-code-file-include analysis in all files under an on-by-default -analyzer-config flag, would that make sense?