The command-line arguments for module builds are cc1 commands, so they do not implicitly set -disable-free like a driver invocation, and Tooling will disable it for the scanning instance itself. Set -disable-free explicitly so that separate invocations for building modules will not pay for freeing memory unnecessarily.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp | ||
---|---|---|
338 | I see the driver is adding -disable-free conditionally: if (!C.isForDiagnostics()) CmdArgs.push_back("-disable-free"); Does that change anything for this patch? | |
338 | If this is always true for our purposes, is there a reason for passing this argument into DependencyScanningAction instead of just hard-coding it there? |
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp | ||
---|---|---|
338 | C.isForDiagnostics() is only true in Driver::generateCompilationDiagnostics, which didn't seem relevant to this tool.
My thinking here was that making this an explicit option forces us to think about it if we add another way to trigger dependency scanning that doesn't use a driver invocation directly - for example, in our downstream branch experimental/cas/main, we have another path through this code that starts from a cc1 command-line, in which case I would think we should not add -disable-free unless the original command-line set it, since it's explicit in cc1. Obviously we don't need to bend over backwards to accommodate out-of-tree code here, but it seemed like a good indication this should be explicit, since it's easy to do that. WDYT? |
LGTM!
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp | ||
---|---|---|
338 | That makes sense, thanks! |
I see the driver is adding -disable-free conditionally:
Does that change anything for this patch?