<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 5:38 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Aug 25, 2014 at 3:49 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">=> 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.</div>

</div></blockquote><div><br></div></div><div>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.</div>
</blockquote></div><br>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.</div>
</div>