================
@@ -136,9 +138,15 @@ struct ModuleDeps {
/// determined that the differences are benign for this compilation.
std::vector<ModuleID> ClangModuleDeps;
- /// Compiler invocation that can be used to build this module. Does not
- /// include argv[0].
- std::vector<std::string> BuildArguments;
+ /// Get (or compute) the compiler invocation that can be used to build this
+ /// module. Does not include argv[0].
+ const std::vector<std::string> &getBuildArguments();
+
+private:
+ friend class ModuleDepCollectorPP;
+
+ std::variant<std::shared_ptr<CowCompilerInvocation>,
std::vector<std::string>>
+ BuildInvocationOrArguments;
----------------
jansvoboda11 wrote:
My concern is that if I use `std::shared_ptr<CowCompilerInvocation>`,
`ModuleDeps` stops having value semantics. I guess that would be solved by
making it a `std::shared_ptr<const CowCompilerInvocation>` to prevent mutation
of the invocation.
Yes, both inlined and indirect storage use the same amount of storage (+- 8B),
but I was thinking about this from memory locality perspective (storing the
rarely used invocation away from frequently used data). But I guess this data
structure is full of pointers to heap anyways, so that doesn't really matter.
I guess I'll just go with the inline approach to save on boilerplate.
https://github.com/llvm/llvm-project/pull/65691
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
