[cfe-commits] [PATCH] Adds a FixedCompilationDatabase

Manuel Klimek klimek at google.com
Tue Apr 10 13:05:32 PDT 2012


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 :)

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 ...

Currently specifying positional parameters after the -- is not
supported. I think we'll want to allow that in the future, but I also
think that we'll still want to provide the simple interface we have
now. Tools will always be somewhat special in that we only allow one
compile action per tool running over a source.

Thoughts?
/Manuel




More information about the cfe-commits mailing list