On Apr 10, 2012, at 1:05 PM, Manuel Klimek <[email protected]> wrote:
> On Tue, Apr 10, 2012 at 7:54 PM, Douglas Gregor <[email protected]> wrote: >> >> On Apr 10, 2012, at 5:17 AM, Manuel Klimek <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
