code review 149260043: runtime: fix scanning of gc work buffer

runtime: fix scanning of gc work buffer

GC types were not being generated for the garbage collector
work buffer.  The markfor object was being collected as a result.
This broke amd64p32 and maybe plan9 builds.  Why it didn't break
every build I'm not sure...

Fixes issue 8812

[khr, 2014-09-29 22:11:40]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://khr%40golang.org@code.google.com/p/go/

[dave_cheney.net, 2014-09-29 22:36:14]

On 2014/09/29 22:11:40, khr wrote:
> Hello mailto:golang-codereviews@googlegroups.com,
> 
> I'd like you to review this change to
> https://khr%40golang.org@code.google.com/p/go/

Is there a way to get the compiler to bark about this sort of error in the
future ?

[khr1, 2014-09-29 22:37:39]

Hopefully, I'm looking into it.

On Mon, Sep 29, 2014 at 3:36 PM, <dave@cheney.net> wrote:

> On 2014/09/29 22:11:40, khr wrote:
>
>> Hello mailto:golang-codereviews@googlegroups.com,
>>
>
>  I'd like you to review this change to
>> https://khr%40golang.org@code.google.com/p/go/
>>
>
> Is there a way to get the compiler to bark about this sort of error in
> the future ?
>
> https://codereview.appspot.com/149260043/
>

[0intro, 2014-09-30 05:35:56]

Thanks. It fixes the issue on Plan 9.

[0intro, 2014-09-30 09:14:27]

LGTM

[khr1, 2014-09-30 14:47:05]

Russ, can you take a look?

On Mon, Sep 29, 2014 at 10:35 PM, <0intro@gmail.com> wrote:

> Thanks. It fixes the issue on Plan 9.
>
> https://codereview.appspot.com/149260043/
>

[rsc, 2014-09-30 15:32:49]

LGTM

The way to avoid this error in the future is to stop using C.

I don't actually know what the error is. My suspicion is that because there
was no struct name, the type converter used something like _4_, and nacl
and plan9 happened to already have an unnamed struct that was also _4_ (in
a different file), and then cmd/dist only used the first instance of _4_.
We should and will just stop using C, and then it's a non-issue.

[khr, 2014-09-30 15:51:06]

*** Submitted as https://code.google.com/p/go/source/detail?r=cd18299d0795 ***

runtime: fix scanning of gc work buffer

GC types were not being generated for the garbage collector
work buffer.  The markfor object was being collected as a result.
This broke amd64p32 and maybe plan9 builds.  Why it didn't break
every build I'm not sure...

Fixes issue 8812

LGTM=0intro, rsc
R=golang-codereviews, dave, khr, 0intro, rsc
CC=golang-codereviews
https://codereview.appspot.com/149260043

[dave_cheney.net, 2014-10-01 00:03:19]

Thanks for your reply Russ. Is it feasible to change cc to reject unnamed
struts, or is that an overreaction?
On 1 Oct 2014 01:32, "Russ Cox" <rsc@golang.org> wrote:

> LGTM
>
> The way to avoid this error in the future is to stop using C.
>
> I don't actually know what the error is. My suspicion is that because
> there was no struct name, the type converter used something like _4_, and
> nacl and plan9 happened to already have an unnamed struct that was also _4_
> (in a different file), and then cmd/dist only used the first instance of
> _4_. We should and will just stop using C, and then it's a non-issue.
>
>

[rsc, 2014-10-01 00:51:06]

>
> Thanks for your reply Russ. Is it feasible to change cc to reject unnamed
> struts, or is that an overreaction?
>
Turns out, yes, it is feasible. CL 150360043