<div dir="ltr"><div class="gmail_extra"><div> > 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.<br><br></div>Your
 layering is already broken. It's broken because Clang implements the 
functionality I need, it can never not implement this functionality, but I can't 
access or re-use it.<br><br>The
 reality is that when you discuss Clang as a C++ -> LLVM IR compiler,
 then being able to emit LLVM IR for C++ constructs is not an 
implementation detail. It's the entire point of the whole thing. It's 
not like Clang is suddenly going to stop being able to emit IR for field
 accesses or something. It's a core requirement. Unless you want to drop
 LLVM as a backend, which I feel safe to say is not going to happen, 
there is no way CodeGen could possibly, ever, drop the functionality I'd
 like to use.<br><br></div><div class="gmail_extra">It'd be one thing to not expose the implementation details if there was a public API ready to go that offered the needed functionality; but there isn't. Exposing your implementation for re-use with well-known consequences is better than other people not being able to re-use it at all. Fundamentally, I feel very dissatisfied saying that there even is such a thing as an implementation detail when there is only one implementation. There is only re-usable code and non-reusable code. This patch converts non-reusable code into reusable code (at least in principle, if I did indeed fail to get all the includes). All code should be in a re-usable state unless that's conceptually impossible; and it's certainly not for lib/CodeGen.<br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On 25 August 2014 23:52, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 25 August 2014 18:04, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>

> I think we should do this. At this point we have two known out-of-tree<br>
> clients trying to talk to lib/CodeGen, and I expect there will be more.<br>
> Julia has an experimental C++ API interop, and I don't know what your<br>
> project is, but I know of it. :) LLDB wanted to in the past, they may try<br>
> again. Basically anyone who wants interop with rich C++ interfaces can use<br>
> some of lib/CodeGen, even if it isn't currently structured for their needs.<br>
><br>
> I'm not sure how this patch is applicable in it's current state, because I<br>
> don't think it captures the actual renames and doesn't actually fix<br>
> CodeGenFunction.h & co to not reference lib/CodeGen internal headers.<br>
<br>
</div>Fair enough. We can move first and refactor afterwards.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 August 2014 23:52, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.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 25 August 2014 18:04, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>

> I think we should do this. At this point we have two known out-of-tree<br>
> clients trying to talk to lib/CodeGen, and I expect there will be more.<br>
> Julia has an experimental C++ API interop, and I don't know what your<br>
> project is, but I know of it. :) LLDB wanted to in the past, they may try<br>
> again. Basically anyone who wants interop with rich C++ interfaces can use<br>
> some of lib/CodeGen, even if it isn't currently structured for their needs.<br>
><br>
> I'm not sure how this patch is applicable in it's current state, because I<br>
> don't think it captures the actual renames and doesn't actually fix<br>
> CodeGenFunction.h & co to not reference lib/CodeGen internal headers.<br>
<br>
</div>Fair enough. We can move first and refactor afterwards.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>