A patch to move codegen includes into public include

Chandler Carruth chandlerc at google.com
Mon Aug 25 17:54:02 PDT 2014


On Mon, Aug 25, 2014 at 5:38 PM, Reid Kleckner <rnk at google.com> wrote:

> On Mon, Aug 25, 2014 at 3:49 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> I think this hurts Clang layering and maintainability. At the moment,
>> *within Clang*, it's very useful to have most of the CodeGen headers in
>> lib/CodeGen rather than within include/clang/CodeGen, since that makes
>> obvious and enforces the layering between CodeGen's private headers and the
>> rest of Clang.
>>
>> => I'm opposed to this change. The CodeGen API is even more
>> implementation details than the AST and Sema API. If you want to include
>> clang's internal implementation details, go ahead, but I don't think we
>> should break our own layering to support this.
>>
>
> Do we (or did we) have actual layering problems where parts of clang think
> they can call into CodeGen? Today the only include into clang/Codegen comes
> from FrontendTool.
>

Yes, before the ABI-relevant bits were hoisted into the AST layer, there
were some terrible hacks between the AST and CodeGen. They got fixed, but I
think it is reasonable to want to avoid them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140825/cb1fd298/attachment.html>


More information about the cfe-commits mailing list