[cfe-commits] [PATCH] Adds a FixedCompilationDatabase

[Douglas Gregor]

On Apr 10, 2012, at 1:05 PM, Manuel Klimek <klimek at google.com> wrote:

> On Tue, Apr 10, 2012 at 7:54 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> On Apr 10, 2012, at 5:17 AM, Manuel Klimek <klimek at google.com> wrote:
>> 
>>> Added parsing code and integrated it into clang-check (which I'm now
>>> heavily testing in my vim session :)
>>> 
>>> As a nice side effect this gives us a beautiful way to write FileCheck
>>> integration tests for clang tools.
>>> I'd still like to be able to pull something out that encapsulates most
>>> of the command line parsing for tools, so it's less code, but I want
>>> to leave that for later.
>> 
>> Patch generally looks good, although this…
>> 
>> +std::vector<CompileCommand>
>> +FixedCompilationDatabase::getCompileCommands(StringRef FilePath) const {
>> +  std::vector<CompileCommand> Result(CompileCommands);
>> +  Result[0].CommandLine.push_back(FilePath);
>> +  return Result;
>> +}
>> 
>> doesn't actually seem right. What if the CompileCommands contains multiple source files, e.g.,
>> 
>>        clang-check -- a.cpp b.cpp
>> 
>> shouldn't we filter out the other non-source files, or return an empty compile command if the command line didn't specify the given file name (say, if the CompilationDatabase is asked to return a compile command for c.cpp)?
> 
> I tried to document that in the chandler-length comments of the
> FixedCompilationDatabase, but apparently I failed :)

I just missed it, sorry.

> The idea is that you'll specify the TUs to work on, the same way you
> do for other clang tools, before the "--".
> Your example would be
> clang-check . a.cpp b.cpp -- -c ...


I can live with that, although I'll note that it's still a little unfortunate that I can't drop in "clang-check" as if it were a compiler and have it do the right thing.

	- Doug