On Mon, Aug 25, 2014 at 4:24 PM, DeadMG <[email protected]> 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 <[email protected]> > wrote: > >> On 25 August 2014 18:04, Reid Kleckner <[email protected]> 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 <[email protected]> > wrote: > >> On 25 August 2014 18:04, Reid Kleckner <[email protected]> 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 >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
