[PATCH] Begin implementing Plan 9 C extensions.

[Peter Collingbourne]

On Tue, May 27, 2014 at 03:25:16PM -0700, Richard Smith wrote:
> On Tue, May 20, 2014 at 4:11 PM, Peter Collingbourne <peter at pcc.me.uk>wrote:
> 
> > On Tue, May 20, 2014 at 03:12:08PM -0700, Nico Weber wrote:
> > > On Tue, May 20, 2014 at 2:53 PM, Peter Collingbourne <peter at pcc.me.uk
> > >wrote:
> > >
> > > > On Tue, May 20, 2014 at 09:21:38PM +0000, Nico Weber wrote:
> > > > > Is there a list of extensions you want to support?
> > > >
> > > > I want to implement the unnamed substructure extension (section 3.3
> > here:
> > > > http://plan9.bell-labs.com/sys/doc/compiler.html). As far as I know,
> > that
> > > > is the only other extension required for the Go standard library.
> > > >
> > >
> > > Hm, that doesn't sound so bad.
> > >
> > > Do you happen to have a complete diff for all the changes you want to
> > make
> > > that you could put somewhere? It sounds like it would be relatively
> > small.
> >
> > I have unnamed substructures implemented (attached). No docs or tests yet,
> > though it does allow me to compile the Go standard library. (It is in fact
> > a relatively large diff, but most of it is boilerplate changes.)
> 
> 
> How much else is there, beyond this? From the documentation above, it seems
> this covers the majority of the features.

That is the only other feature that is required.

> I'm not overjoyed by the churn of adding a (very rare) flag to FieldDecl to
> support this, but there's no point digging into the details here if you're
> not yet sure that you want to pursue this.

I am not pursuing these specific patches for trunk at present.

I discussed the matter with the Go folks, and they are willing to accept
patches to drop uses of these extensions. That I believe is the correct
long-term solution for this problem, but these patches will take some time
to reach the version of the Go standard library that I am using.

I do not wish to impose on other Clang developers with this feature, which
I will only need temporarily, so I currently intend to pursue a different
short-term solution that does not involve changing Clang trunk.

Thanks,
-- 
Peter