During CTU analysis of complex projects, the loaded AST-contents of
imported TUs can grow bigger than available system memory. This option
introduces a threshold on the number of TUs to be imported for a single
TU in order to prevent such cases.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 31826 Build 31825: arc lint + arc unit
Event Timeline
Mostly looks good, I have two slightly related nits.
include/clang/CrossTU/CrossTranslationUnit.h | ||
---|---|---|
129 | I would prefer to keep the default argument for DisplayCTUProgress. You could do this either by swapping the arguments or adding a default argument to CTULoadThreshold as well. I think I might prefer the latter. | |
187 | Does it make sense to call getCrossTUDefinition with different thresholds for the same CTUContext? I suspect it is not, so it might make more sense to set the threshold in the context's constructor. |
I could greatly simplify the API of getCrossTUDefinition by injecting the threshold value in the constructor. A minor drawback with this approach is that testing code is a bit more complicated, as I had to patch the CompilerInstance to override the AnalyzerOption value for CTUImportThreshold. Thanks for the suggestion!
include/clang/StaticAnalyzer/Core/AnalyzerOptions.def | ||
---|---|---|
293 | burder -> burden ? |
test/Analysis/ctu-import-threshold.c | ||
---|---|---|
2–6 | There's no need for such validation, AnalyzerOptions' interface is very well guarded against misuse. If you insist, prefer modifying clang/test/Analysis/invalid-analyzer-config-value.c. |
I would prefer to keep the default argument for DisplayCTUProgress. You could do this either by swapping the arguments or adding a default argument to CTULoadThreshold as well. I think I might prefer the latter.