[LLVMdev] Proposal: add Go frontend subproject based on llgo

[Peter Collingbourne]

On Wed, Nov 19, 2014 at 02:57:37PM -0800, Sean Silva wrote:
> A quick browse through the contributors on
> https://github.com/go-llvm/llgo/graphs/contributors and some searches in my
> mail suggests that none of the primary contributors are part of the LLVM
> community. How are they going to continue developing llgo once it is the
> LLVM repo?

The two main contributors are Andrew Wilkins and myself; I know that Andrew
is supportive of this move and presumably would continue to contribute in
the project's new location.

I don't know why most of my contributions are not showing on that page,
but I have contributed over 200 commits to llgo.

> Sorry if this is a dumb question, but what is the advantage of having this
> in-tree as an LLVM project? I typically associate the following advantages
> to having something in-tree:
> 
> 1. You can get the awesome code review of the LLVM community.
> 2. If people are changing the API, they have to fix in-tree stuff, so you
> are shielded from ongoing maintenance burden.
> 
> Since the code is in go, you don't really get 1; the community speaks C++.

There is a subset of the community that is bilingual and willing to do code
review. As I mentioned, I am willing to be the code owner for this subproject,
so things will get reviewed.

> IIRC the bindings are based on the C API, so they are stable and so 2
> doesn't apply.

The bindings do use certain unstable APIs, such as debug info, and we may
decide to expand them to expose other unstable APIs. See also some of the
discussion in http://reviews.llvm.org/D5684

There are other advantages to having the project be part of LLVM. For example,
the standard library is built using llgo and a compatible version of Clang,
and this will be more important if we LTO the libgo library. At the moment,
llgo is built using a hackish set of shell scripts that make the correct
pieces of LLVM and Clang available; things are much simpler if everything
is built together.

The same goes for the sanitizer libraries in compiler-rt, which are fiddly
to use with llgo at the moment.

Thanks,
-- 
Peter