[cfe-dev] Proposal: libclang code generation

[Douglas Gregor]

On Dec 13, 2011, at 8:34 PM, Gregory Szorc wrote:

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

The small number of consumers that only care about going directly from source to generated code would get to skip the translation unit, but this API doesn't allow any flexibility for people who want to inspect the translation unit and later generate code from it.

Consumers should be inspecting diagnostic output after parsing and before generating code *anyway*, since codegen will unceremoniously fail if there are any errors in the AST. This is naturally a two-step process, and you aren't saving much at all by making it into one step.

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

You can't actually avoid any of the details of the translation unit implementation because, as you've noted below, we need to have a function that takes a CXTranslationUnit and generates code from it.

Writing to stderr (when not under some kind of debugging setting) would be a bug in libclang regardless. What are you referring to, specifically?

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

I don't know what you mean by 'monolithic', but having this functionality is critical. 

> But, I
> would still like a higher-level API that could bypass translation units,
> for reasons given above. clang_compileFromSourceFile() perhaps?

I'd rather not have this source -> generated code function at all. It's not sufficient for a significant number of use cases (which will need TU -> generated code), will be redundant with the more general TU -> generated code version, and saves a total of 1 line of code for those use cases that don't care about the TU.

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


I fully agree with David.

	- Doug