code review 91520043: cmd/cgo: document the cgo types also follow Go name spa...

cmd/cgo: document the cgo types also follow Go name space rules.
Fixes issue 7958.

[minux1, 2014-05-17 21:10:04]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[minux1, 2014-05-17 21:14:20]

we probably can also document issue 7786 as known bug of cgo here.

[r, 2014-05-19 16:47:05]

https://codereview.appspot.com/91520043/diff/80001/doc/go1.3.html
File doc/go1.3.html (right):

https://codereview.appspot.com/91520043/diff/80001/doc/go1.3.html#newcode246
doc/go1.3.html:246: corresponding C types are different.
Before Go 1.3, cgo incorrectly treated all opaque C types (such as
<code>void*</code> or other plain pointer types)
as the same Go type <code>*[0]byte</code>.
In Go 1.3, these types will be distinct if the C types are distinct.

https://codereview.appspot.com/91520043/diff/80001/src/cmd/cgo/doc.go
File src/cmd/cgo/doc.go (right):

https://codereview.appspot.com/91520043/diff/80001/src/cmd/cgo/doc.go#newcode95
src/cmd/cgo/doc.go:95: package.
there is nothing called "Go rules of namespacing" so let's avoid that term

Cgo translates C types into their equivalent Go types, which will be defined in
the package that uses cgo.
Thus a C type used in one Go package will be a distinct type from the same C
type used by another package.
It is recommended, therefore, to confine all cgo components in the same Go
package.

https://codereview.appspot.com/91520043/diff/80001/src/cmd/cgo/doc.go#newcode100
src/cmd/cgo/doc.go:100: different C types are incompatible with each other.
This belongs in the release notes - does it need to be here?

[minux1, 2014-05-20 18:49:43]

PTAL.

Russ have already made changes to the release docs, so this CL
will focus on the cgo docs instead.

[r, 2014-05-20 18:59:55]

leaving for rsc

https://codereview.appspot.com/91520043/diff/120001/src/cmd/cgo/doc.go
File src/cmd/cgo/doc.go (right):

https://codereview.appspot.com/91520043/diff/120001/src/cmd/cgo/doc.go#newcod...
src/cmd/cgo/doc.go:108: Opaque types in C (such as void* or pointer to types
without a definition)
that's not what opaque type means.

[minux1, 2014-05-20 19:08:58]

PTAL.

https://codereview.appspot.com/91520043/diff/120001/src/cmd/cgo/doc.go
File src/cmd/cgo/doc.go (right):

https://codereview.appspot.com/91520043/diff/120001/src/cmd/cgo/doc.go#newcod...
src/cmd/cgo/doc.go:108: Opaque types in C (such as void* or pointer to types
without a definition)
On 2014/05/20 18:59:54, r wrote:
> that's not what opaque type means.
right, i should have written opaque pointers (such as void* or pointer to opaque
types).

[minux1, 2014-05-22 00:19:17]

Gentle ping. Russ?

[gobot, 2014-05-29 21:29:36]

R=rsc@golang.org (assigned by r@golang.org)

[rsc, 2014-05-30 21:08:15]

LGTM

https://codereview.appspot.com/91520043/diff/160001/src/cmd/cgo/doc.go
File src/cmd/cgo/doc.go (right):

https://codereview.appspot.com/91520043/diff/160001/src/cmd/cgo/doc.go#newcod...
src/cmd/cgo/doc.go:110: Cgo translates C types into their equivalent Go types,
which will be
replace paragraph with:

Cgo translates C types into equivalent unexported Go types.
Because the translations are unexported, a Go package should not 
expose C types in its exported API: a C type used in one Go package
is different from the same C type used in another.

https://codereview.appspot.com/91520043/diff/160001/src/cmd/cgo/doc.go#newcod...
src/cmd/cgo/doc.go:116: Opaque pointers in C (such as void* or pointer to opaque
types) will
Delete this paragraph. I don't want to fully specify what happens for these. The
previous paragraph should be enough.

[minux1, 2014-05-31 07:51:51]

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

cmd/cgo: document the cgo types also follow Go name space rules.
Fixes issue 7958.

LGTM=rsc
R=golang-codereviews, rsc, r, gobot
CC=golang-codereviews
https://codereview.appspot.com/91520043

[gobot, 2014-05-31 08:01:56]

This CL appears to have broken the plan9-386-cnielsen builder.
See http://build.golang.org/log/327e716d60c0f250b9a103832a961348cf2e27c2

[minux, 2014-05-31 08:13:04]

On Sat, May 31, 2014 at 1:01 AM, <gobot@golang.org> wrote:

> This CL appears to have broken the plan9-386-cnielsen builder.
> See http://build.golang.org/log/327e716d60c0f250b9a103832a961348cf2e27c2

--- FAIL: TestResponseWriterWriteStringAllocs (0.00 seconds)
 serve_test.go:2292: WriteString allocs of 21 >= Write allocs of 21
FAIL
FAIL net/http 19.196s

it seems testing.AllocPerRun tests are still flaky.