[cfe-commits] r159484 - in /cfe/trunk: include/clang-c/CXCompilationDatabase.h test/Index/compile_commands.json tools/c-index-test/c-index-test.c tools/libclang/CIndexCompilationDB.cpp tools/libclang/CMakeLists.txt tools/libclang/libclang.exports

[Arnaud de Grandmaison]

On Friday 06 July 2012 09:17:56 Douglas Gregor wrote:
> I'm actually curious about why you need to extract this information at all
> for your use case. Typically with code completion in libclang, one simply
> needs to construct the original command line (which the compilation
> database can do for us), parse that translation unit, and then
> code-complete within that translation unit. There's no need to look at or
> interpret the command-line options.

clang_complete can be configured to use either clang or libclang. Of course, 
CompilationDatabase is supported only when using libclang.

Before adding the CompilationDatabase, there were already several ways to 
provide the compilation options (thru a .clang_complete file, or thru vim 
variables, ...) ; the command line is then built depending on the use of clang 
or libclang and the current buffer file name --- meaning the options are  
specific to a group of files or global. I did want the CompilationDatabase to 
integrate smoothly with what already exists in clang_complete : just provide 
options (no input / ouput file or compiler invocation).

> I was actually referring to something a bit different. If one has a
> compilation database, then one can presumably use that compilation database
> as the source of command lines. For example, one could simply have
> 
> 	clang_codeComplete(CXCompilationDatabase db, const char *filename, 
unsigned
> line, unsigned column, unsigned options)

I am a bit worried with the above prototype. The CompilationDatabase is a 
good, but I believe it has a weakness : it is indexed by input file name, and 
not by output file name. The input filename is not enough to select the right 
CompileCommand. When CompilationDatabase.getCompileCommands(filename) returns 
several compile commands, how to choose the right one ? In clang_complete, I 
use the first command, hoping for the best... On the other hand, we all work 
with input filenames and dont really care about (or even know) the actual 
output filename : this is the buildsystem's cooking.

> and this routine would query the compilation database to find the
> appropriate command line for the given filename, automating most of the
> process. Thinking about it further, this approach would actually be a
> significant effort, because if we went this way, we'd want to automate a
> lot more of the process of managing multiple translation units and querying
> them appropriately. I suspect we'll actually want to tackle this particular
> issue as part of the Clang service architecture discussed a few weeks back.

This management of the multiple TU is done today within the clang_complete 
plugin. Others (Emacs, ...) will have to do the same work : this common code 
should probably end up somewhere in libclang or the clang service 
architecture.

> 
> 	- Doug