[cfe-dev] RFC: Integrating clang-cc functionality into clang (the driver)
edwintorok at gmail.com
Mon Dec 7 11:51:24 PST 2009
On 2009-12-04 19:35, Daniel Dunbar wrote:
> 2009/12/4 Török Edwin <edwintorok at gmail.com>:
>> On 2009-12-04 18:20, Daniel Dunbar wrote:
>>> Hello again,
>>> All the major pieces of the clang / clang-cc integration project are
>>> now in place, which means its time to put them to work! :)
>> So can I now invoke the driver directly (after forking, in case it
>> without the need for execve(), and have the ability to turn all the
>> clang-cc commandline flags on/off?
> Yes. Look at ASTUnit::LoadFromSource for example.
>> Is there a way now to get diagnostics directly, without the need to
>> redirect/parse the output?
>> Also will cl::ParseCommandLineOptions still work for LLVM commandline
> It works, but it isn't called by default. We could add an -mllvm for
> clang-cc for this, although I'd rather not.
Thats fine, I can call that in my code before calling the driver class.
>> I am currently using some rather low-level switches for clang-cc, so I
>> might as well ask now whether these are going away in the future or not:
>> -ffreestanding -nostdinc -disable-free -fdiagnostics-show-option
>> -fcolor-diagnostics -triple clambc-generic-generic -include bytecode.h
>> -Wall -warn-dead-stores -warn-security-syntactic -analyzer-eagerly-assume
>> -v -g -E -S
> No, although it would be better for you to use the driver to construct
> a CompilerInvocation, and then tweak the resulting object. That way
> you are insulated from changes to the clang/clang
> -cc1/CompilerInvocation API.
Yes, that makes sense.
>> Also I've been experimenting at some point with writing a simple editor
>> that uses clang for syntax highlighting/completion.
>> There were 2 issues:
>> - creating the Preprocessor object involved setting lot of language
>> related stuff, like implicitint, accesscontrol, bool support, and so on.
>> Is there a way to just tell it to create with the language defaults that
>> the clang driver would use? (and eventually tell it about
>> -std=c99, and it automatically sets up whatever clang sets up for c99).
> You can do this easily now via CompilerInvocation and
> CompilerInstance. You can look at how the FrontendAction wrapper
> implements this, for example.
>> - This isn't necesarely related to your driver work, but I didn't see
>> any support for reusing previous parse results, like reparsing only the
>> portion of the
>> file/membuffer that changed. Can that somehow be accomplished with the
>> new driver infrastructure? (i.e. tell it that you've previously compiled
>> this file
>> with same driver, and now you only want to reparse/rebuild the AST for
>> the changed part).
> This doesn't really have anything to do with the driver, and we don't
> have the underlying feature support for this.
> It's great to hear someone is working on this kind of stuff, please
> consider packing your work up as an example we can include with clang!
Ok, I'll do that when I have some free time to update it to the new
What license is acceptable for the examples, GPL2 good enough?
More information about the cfe-dev