[cfe-dev] RFC: Integrating clang-cc functionality into clang (the driver)

[Török Edwin]

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! :)
>>>
>>>       
>> Hi,
>>
>> So can I now invoke the driver directly (after forking, in case it
>> crashes),
>> 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?
>>     
>
> Yes.
>   

Ok.

>   
>> Also will cl::ParseCommandLineOptions still work for LLVM commandline
>> options?
>>     
>
> 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
>> -fmessage-length=80
>> -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
clang API.
What license is acceptable for the examples, GPL2 good enough?

Best regards,
--Edwin