kadircet added a comment. This is ready for another round. To summarize the current state:
- `PreamblePatch` can be create from a `ParseInput` and a `PreambleData`, - It will preprocessor preamble section of current file contents using a dummy FS to reduce cost of stat/realpaths - It won't populate `Resolved` path for inclusions, as we don't need them at this stage, and even later on. As we'll run the real preprocessor when building the ParsedAST, and we can collect resolved paths at that stage instead. - Afterwards it will diff the includes found in current contents with includes found in the PreambleData, and create a patch containing all the new includes - `PreamblePatch` can be applied to a `CompilerInvocation`: - It is a no-op if contents are empty, i.e it was default constructed or there were no new includes. - Otherwise it will create an implicit include which contains patch created with new includes. Things that I don't like about current state: - We'll run processor to collect includes even when the preamble section of current file hasn't changed. - `PrecompiledPreamble` contains the contents of the preamble but it is not exposed, I suppose we can either expose that to get rid of extra preprocessor creation overhead. - We create an extra `CompilerInvocation` and `CompilerInstance` just to run preprocessor and throw them away later on. I am not sure what to do about this :/ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77392/new/ https://reviews.llvm.org/D77392 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
