[cfe-dev] Proposal: libclang code generation

[Gregory Szorc]

Chalk one up for my ignorance: I now see that the translation unit API
could be the front part of compilation.

That being said, I feel that having a higher-level compiler API that
bypasses (or at least abstracts) the translation unit bit would be more
user friendly (not to mention loosely coupled). For example, consumers
would only need to inspect the result of 1 "process input" function as
opposed to 2 (the diagnostics examination is the heavy bit). There are
also some nasty bits of the translation unit implementation that could
just be ignored (like various functions writing to stderr - something a
library should never do).

I realize that incrementally going from a translation unit to generated
code would be a requirement. In a separate compiler API, that could be
facilitated by clang_codegen_compileTranslationUnit() or
clang_codegen_createInputFromTranslationUnit(), which is then fed into
clang_codegen_generateOutput(). clang_compileTranslationUnit() would
also work if we're sticking to the monolithic module approach. But, I
would still like a higher-level API that could bypass translation units,
for reasons given above. clang_compileFromSourceFile() perhaps?

I'm lacking experience with the Clang project to really do much beyond
throw ideas around and see what sticks.

If nobody else weighs in, I'll rewrite the proposal to reflect David's
suggestions.

Greg

On 12/13/2011 3:50 AM, David Chisnall wrote:
> I don't think I understand why this needs so much new API.  With libclang, you create a translation unit by providing a file (on disk or unsaved) and a set of compiler flags.  At this point, the API already has everything that it needs to be able to compile the input file.  I would expect this to be accomplished with just a clang_compileTranslationUnit() function (which, if the translation unit has not changed, just needs to do the codegen - it can skip reparsing), possibly with the option of changing the output from the location specified with the original compile options.
> 
> David
> 
> On 13 Dec 2011, at 06:41, Gregory Szorc wrote:
> 
>> I started a conversation in #llvm a few days ago regarding adding code
>> generation support to libclang (I'm indygreg on IRC). People seemed
>> receptive to the idea, so, I performed some preliminary work around a
>> proposal for the API. I've produced a couple of new header files [1][2]
>> with the proposed API. Higher-level comments and questions are in a
>> README [3].
>>
>> I'm requesting review of the proposal from the larger community. I'd
>> like to get "sign off" of the C API/.h files before I start working on
>> the implementation so I'm confident I'm producing the right thing.
>>
>> There likely also needs to be a larger discussion around the structure
>> of libclang. The gory details are in the README [3]. The tl;dr is that
>> the existing API pigeonholes generic functionality as specific to the
>> Index module and feature expansion of libclang will likely require a)
>> API breakage due to required refactoring, and/or b) an ill-conceived
>> code layout and naming convention.
>>
>> This is my first time hacking on LLVM or Clang. I fully expect that
>> there are many deficiencies in my proposal due to ignorance. I have
>> thick skin, so let me hear it!
>>
>> [1]
>> https://github.com/indygreg/clang/blob/libclang_compiler/include/clang-c/CodeGen.h
>> [2]
>> https://github.com/indygreg/clang/blob/libclang_compiler/include/clang-c/Compiler.h
>> [3]
>> https://github.com/indygreg/clang/blob/libclang_compiler/README.libclang_changes
>>
>> Gregory Szorc
>> gregory.szorc at gmail.com
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev