A patch to move codegen includes into public include

Richard Smith richard at metafoo.co.uk
Mon Aug 25 16:36:23 PDT 2014


On Mon, Aug 25, 2014 at 4:24 PM, DeadMG <wolfeinstein at gmail.com> wrote:

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

It's not broken for our own uses. We can't call any part of the CodeGen API
except the part that's in include/clang, which is exactly the design
intent. No other part is *intended* to be used outside of lib/CodeGen.

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

Feel free to include headers directly from lib/CodeGen. I think we'd also
be receptive to an extension to the Clang C API providing a stable way to
generate IR from AST, in a way that's interface-compatible with the LLVM C
API.


> 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/20140825/9fb24ecd/attachment.html>


More information about the cfe-commits mailing list