A patch to move codegen includes into public include

DeadMG wolfeinstein at gmail.com
Mon Aug 25 16:24:23 PDT 2014


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

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.

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.

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.

On 25 August 2014 23:52, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
wrote:

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



On 25 August 2014 23:52, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
wrote:

> On 25 August 2014 18:04, Reid Kleckner <rnk at google.com> wrote:
> > I think we should do this. At this point we have two known out-of-tree
> > clients trying to talk to lib/CodeGen, and I expect there will be more.
> > Julia has an experimental C++ API interop, and I don't know what your
> > project is, but I know of it. :) LLDB wanted to in the past, they may try
> > again. Basically anyone who wants interop with rich C++ interfaces can
> use
> > some of lib/CodeGen, even if it isn't currently structured for their
> needs.
> >
> > I'm not sure how this patch is applicable in it's current state, because
> I
> > don't think it captures the actual renames and doesn't actually fix
> > CodeGenFunction.h & co to not reference lib/CodeGen internal headers.
>
> Fair enough. We can move first and refactor afterwards.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140826/b6d43854/attachment.html>


More information about the cfe-commits mailing list