<div dir="ltr">Hi,<div><br></div><div>as we've seen more use of the compilation database (for example through the YCM vim plugin), we noticed that for networked build systems and server applications the information we currently expose in the interfaces (path, file-name, command line arguments) is not enough - we also need to be able to get all source code, which we then can put into clang's VFS to get a fully build-system independent clang run over a translation unit.</div>
<div><br></div><div>We think that getting the source information (perhaps optionally) as part of a getCompileCommands run is a good fit - a build system always must know how to provide the required sources, and as such it seems to be a natural fit.</div>
<div><br></div><div>I'd propose to change the CompilationDatabase interface (tools/clang/include/clang/Tooling/CompilationDatabase.h) to that end, and see two possible solutions, which both have different pros and cons:</div>
<div>1. Add a map from std::string (file-name) -> std::string (source content) to the CompileCommand class (in tools/clang/include/clang/Tooling/CompilationDatabase.h); let specific CompilationDatabases optionally fill in that information</div>
<div>2. Do not modify CompileCommand - instead, add a getCompileCommandsAndSources(StringRef FilePath) method that returns a vector<pair<CompileCommand, map<string, string>>> which also includes the sources; I'm reluctant to split the call into two, as the compile command and the sources are tightly coupled (if a user syncs in the background, both tend to change at the same time)</div>
<div><br></div><div>I lean towards solution (1), mainly because it seems less invasive. On the other hand, it might make it less obvious to users of libclang what's going on (for both solutions I'd propose extending the libclang interface basically in a very similar way to how the C++ code changes).</div>
<div><br></div><div>Opinions?</div><div><br></div><div>Thanks,</div><div>/Manuel</div></div>