Reset CodeGenOptions fields for clean module/PCH builds

[ayushpareek2003]

This change resets certain CodeGenOptions fields using = {} instead of .clear(), to clean up build-specific data when generating modules or PCH files. It helps make the output more consistent and easier to maintain

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang-modules
@llvm/pr-subscribers-clang-codegen

@llvm/pr-subscribers-clang

Author: Ayush Pareek (ayushpareek2003)

Changes

This change resets certain CodeGenOptions fields using = {} instead of .clear(), to clean up build-specific data when generating modules or PCH files. It helps make the output more consistent and easier to maintain

---

Full diff: https://github.com/llvm/llvm-project/pull/138256.diff

1 Files Affected:

• (modified) clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp (+11-10)

diff --git a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
index b3016f90122df..5fbc502b15c3a 100644
--- a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -209,20 +209,21 @@ void ModuleDepCollector::addOutputPaths(CowCompilerInvocation &CI,
 void dependencies::resetBenignCodeGenOptions(frontend::ActionKind ProgramAction,
                                              const LangOptions &LangOpts,
                                              CodeGenOptions &CGOpts) {
-  // TODO: Figure out better way to set options to their default value.
+  // For actions that produce modules or PCHs, reset options that could leak build-specific data.
   if (ProgramAction == frontend::GenerateModule) {
-    CGOpts.MainFileName.clear();
-    CGOpts.DwarfDebugFlags.clear();
+    CGOpts.MainFileName = {};
+    CGOpts.DwarfDebugFlags = {};
   }
+
   if (ProgramAction == frontend::GeneratePCH ||
       (ProgramAction == frontend::GenerateModule && !LangOpts.ModulesCodegen)) {
-    CGOpts.DebugCompilationDir.clear();
-    CGOpts.CoverageCompilationDir.clear();
-    CGOpts.CoverageDataFile.clear();
-    CGOpts.CoverageNotesFile.clear();
-    CGOpts.ProfileInstrumentUsePath.clear();
-    CGOpts.SampleProfileFile.clear();
-    CGOpts.ProfileRemappingFile.clear();
+    CGOpts.DebugCompilationDir = {};
+    CGOpts.CoverageCompilationDir = {};
+    CGOpts.CoverageDataFile = {};
+    CGOpts.CoverageNotesFile = {};
+    CGOpts.ProfileInstrumentUsePath = {};
+    CGOpts.SampleProfileFile = {};
+    CGOpts.ProfileRemappingFile = {};
   }
 }
 

[ChuanqiXu9]

Could you elaborate? Why = {} is better than .clear() ?

[ayushpareek2003]

Could you elaborate? Why = {} is better than .clear() ?

according to my understanding, Clang stores some build-specific data in CodeGenOptions like file paths and debug info. When generating modules or precompiled headers, this data can make the output different from build to build. To avoid that, we reset those fields.

I changed .clear() to = {} because, as I understand, = {} resets the entire field to its default value, not just empties it. This is helpful because it works safely across different types—not just std::string, but also for types like std::optional, smallString, or other structs that might be used in the future. Using = {} makes it easier to refactor or extend the structure later without having to update every .clear() call. It also communicates intent more clearly: we’re not just clearing content, we’re fully resetting the field. This reduces the risk of leaking build-specific paths or flags into the output, and helps make Clang’s module and PCH output more consistent and reproducible across different systems. I did this to make the code more future-proof, maintainable, and reliable.

[ChuanqiXu9]

I feel .clear() should have a similar semantic with = {};. It will be confusing for people to understand this. It will be helpful if you can provide a test to show the difference.

[ayushpareek2003]

I feel .clear() should have a similar semantic with = {};. It will be confusing for people to understand this. It will be helpful if you can provide a test to show the difference.

I’ve tried to demonstrate the difference between .clear() and = {}, not a formal test case, but just a minimal example to illustrate the behavior clearly. It’s meant to show how these two approaches behave differently, especially when dealing with types like std::optional.

`

std::optional<std::string> A = "clang";

auto B = A;
auto C = A;
B->clear(); // empties the string but keeps the optional engaged
C = {};     // fully resets the optional to disengaged (nullopt)

std::cout << "B has value? " << B.has_value() << "\n"; // it will print 1
std::cout << "C has value? " << C.has_value() << "\n"; // it will print 0`

I hope it helps clarify why = {} can be a safer and more expressive choice in some situations

[ChuanqiXu9]

hmmm for test case, I mean a test case in clang, either a unit test or a lit test, so we can understand the effect on users more clearly.

And if you're talking about the general code policy, I'll suggest you to https://discourse.llvm.org/ to make it more verbose.

[ayushpareek2003]

hmmm for test case, I mean a test case in clang, either a unit test or a lit test, so we can understand the effect on users more clearly.

And if you're talking about the general code policy, I'll suggest you to https://discourse.llvm.org/ to make it more verbose.

I've added a test under clang/test/Modules/reset-codegen-options.c to demonstrate that the affected fields (like MainFileName and DebugCompilationDir) are correctly reset and no longer leak into the module or PCH output.
This test helps confirm that switching from .clear() to = {} results in cleaner and more consistent output, particularly by fully resetting the fields to their default-constructed state

[Bigcheese]

This comment is talking about setting it to the default value it would have if no argument is passed, which for these cases is empty, but not all options default to empty.

[ayushpareek2003]

Thanks, that makes sense. I was referring to the default-constructed values here, which happen to be empty strings. I used = {} for clearer intent and future-proofing. You're right, not all fields default to empty, I’ll update the comment accordingly.