<div dir="ltr"><div><div>Yes, I apologize for not being very specific. Since the patch directly follows on from the cfe-dev discussion I kinda assumed that all involved would have seen it. Let me take a step back here.<br>
<br></div>The project that I'm working on right now is an external language which offers direct interfacing to C++. Here we mean things like, instantiating templates, implementing methods, calling methods, inheriting from classes, stuff like that. This really means needing the support of Clang at every step in the process of handling the C++ code being interfaced with- lexing/preprocessing, parsing, analysis, and codegen. For example, if my user requests a field of a CXXRecordDecl, then I need to create IR that corresponds to that field access. This is also a job that Clang absolutely must do, so it seems clear to me that simply re-using Clang's existing code is the smarter play.<br>
<br></div><div>I think that we can all agree that a hypothetical future API would be more abstract than the existing lib/codegen. Effectively, I already have built a fair chunk of this. I want to continue working on it and I want to produce something that's useful not just for me, but for anyone with similar needs. I know that I'm not the only one.<br>
</div><div><br></div><div>The real issue here is primarily the limitations of my own development environment. Or to wit, how am I going to construct a new public API without access to private details to produce an implementation? Some of you may have seen on IRC how "hilariously" long it takes for me to rebuild LLVM/Clang, and the need to build from source is a big problem when I want to use the CI server I have access to, or if another developer wants to contribute to my work. It's not that I necessarily think that the CodeGen internals should be public for all time. It's just that if I want to work in this space with my available environment, to build the API that it seems like we all agree would be the superior option, then not having them available is a fairly big problem for me. My CI server was wiped and I'm looking at not bringing it back online because getting Clang into a point where it could be used for development in this area was pretty difficult the first time and the guy I'm bumming CI from changed his OS from the much more friendly Ubuntu to Gentoo (I'm a Windows dev primarily).<br>
<br></div><div>We all seem to agree that we want a lib/ABI rather than a public lib/CodeGen. It's just that the practicalities of actually *building it* are seriously impeded for me by developing in-tree rather than out of it.<br>
<br>> Yes, but that's exactly what we're lacking here: a compelling use case 
that outlines what API it actually needs in the public headers.<br><br><div class="gmail_extra">> I'm really not sure why the first step isn't to
 *design* a reasonable public API. Throwing header files at the wall and
 seeing what sticks will not result in an API we can maintain and 
support going forward.<br><br>It's a bit of a chicken-and-egg problem. I already have quite a bit of 
work in this area- certainly not complete but a starting point. But the primary issue of contributing incrementally 
is that that implies developing each increment with still-private APIs- 
the exact thing I'm trying to <i>avoid </i>here because it's a serious problem for me to keep working that way. Conceptually, there's certainly no reason why I couldn't simply provide the work I've done already as a start. The problem is what's gonna happen when I want to fix bugs, add new features, or change the implementation. I'd be, relatively speaking, right back to square one, because if I find a better implementation based on a slightly different CodeGen API, then I'm back to developing against private internals.<br>
</div><br>> Digging a bit, it seems like quite a bit got 
laid out by the OP in the thread "[cfe-dev] Clang ABI library". However,
 there hasn't been a clear connection drawn between the code changes in 
this patch and the use cases in that thread.<br><br></div><div>The APIs in the headers changed in the patch are the ones I've used to implement those features so far. For a simple example, it's CodeGenModule that contains the API you need to convert a CXXMethodDecl* into an llvm::Value* you can call/invoke, or to generate code into your own LLVM module. It's CodeGenFunction that contains the API you need to define or call C++ functions. And so on. <br>
<br>There are a few that I know will need changing. For example, Itanium ABI states that RTTI descriptors should be emitted with the body of a given method. Understandably, it makes no provision for what should occur if no C++ compiler will ever see the body of that method because it was implemented in an external language. I'd need to alter the mechanism for RTTI emission to handle this case (assuming that an unrelated change didn't allow a handle for it in 3.5). Another example is that CodeGenTypes doesn't handle having multiple CodeGenTypes generating into the same module, so you end up with more than one LLVM type for the same Clang type and the IR no longer typechecks. But the only reason I even know that an internal change will be needed is because I already tried with the existing API. But since developing in-tree is pretty painful for me (as above) I'd rather keep developing as much as humanly possible externally.<br>
<br></div><div>All I'm saying is, moving a few headers seems like a low price to pay for enabling a much superior development process for the thing we all actually seem to want in the end (I haven't seen anyone suggest that having a lib/ABI or similar would be undesirable). It would be less of a problem if I had a better environment or better hardware, but there's nothing I can do about that at the current time.<br>
<br></div><div>Or alternatively I could just contribute what I've got and then let you guys finish the job instead of doing it myself.<br></div><div><br></div><div>For the record, if you want to see what I've done so far against 3.4, you can breeze through the existing tutorials on <a href="http://www.codepuppy.co.uk/">my website</a>. Obviously you can decide for yourself whether or not compiling the demonstrated code counts as a compelling use case.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 August 2014 03:46, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Aug 25, 2014 at 7:27 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>

</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div><br>
<div class="gmail_quote">On Mon, Aug 25, 2014 at 7:26 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">as we get compelling use cases, we bring up the necessary headers into include/ to satisfy them, making any necessary incremental changes to better serve the use case.</blockquote>


</div><br></div>Yes, but that's exactly what we're lacking here: a compelling use case that outlines what API it actually needs in the public headers.</div></div>
</blockquote></div></div></div><br></div><div class="gmail_extra">Totally agreed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Digging a bit, it seems like quite a bit got laid out by the OP in the thread "[cfe-dev] Clang ABI library". However, there hasn't been a clear connection drawn between the code changes in this patch and the use cases in that thread.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">DeadMG, maybe you could start a new thread with a more incremental, more clearly motivated step attacking a limited subset of your use case, rather than your current approach of "<span style="font-family:arial,sans-serif;font-size:13px">These are just the headers I found myself to have used so far when grepping my codebase</span><span style="font-family:arial,sans-serif;font-size:13px">"?</span></div>
<span class="HOEnZb"><font color="#888888">
<div class="gmail_extra"><br></div><div class="gmail_extra">-- Sean Silva</div></font></span></div>
</blockquote></div><br></div>